
Mr.Weegley
Участники форума-
Постов
26 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент Mr.Weegley
-
ndp proxy на vps работает. Вернее, запущен. Я так и не понял правильно ли я там конфиг написал и, соответственно, работает ли оно вообще Конфиг ndppd на vps: А заодно, он запущен и на кинетике, со следующим конфигом: всё это каким то образом работает в одну сторону. Собственно, для моих нужд маршрутизация ipv6 в сторону клиентов и не нужна, а даже и вредна так как работает сидбокс, но в целом как то неполноценно получается... UPD Поотключал везде ndppd, заодно выяснив, что оно не правильно, по ходу настроено было. Поправил radvd, клиент получил свой ipv6 из подсети назначенной туннелю. Ходит в ipv6 по маршруту роутер->(wg)->vds->tunnelbroker->ipv6 Причем, ходит, даже имея только link-local и провайдерский адреса. И ipv6 адрес ipconfig.io показывает всегда верный. Мистика какая то. Клиент пингуется с роутера, но не пингуется извне. В моём конкретном случае меня это устраивает, поскольку работает раздача торрентом, но в целом - как то неполноценно.
-
Действительно, включил на роутере нативный IPV6 и клиенты получив его и fe80::/10 имеют доступ к ipv6 и через натив и через туннель. ipconfig.io показывает ipv6 клиента из подсети 2001 от HE, НО он не пингуется ни просто извне, ни даже с роутера. В общем, получается такой себе IP6NAT... Но хоть так...
-
Не совсем то, что я спрашивал. У меня на VPS /48 от HE. Клиенты WG настроенные вручную, включая и кинетик отлично работают. У всех /64 Но Кинетик отказывается делигировать свою сетку клиентам. Костыль AdvDefaultLifetime руками даёт эффект, но ровно до изменения статуса любого интерфейса. Дёрнул LAN кабель - всё в radvd.conf обновляется. То есть, либо городить какой-то hook с костылём, либо надеяться что разрабы добавят возможность ходить в ipv6 через Wireguard не только роутеру, но и его клиентам. UPD Думал, может префикс кинетику не нравится. Сделал ему на входе /52 - не помогло. До чего смог докопаться: ip6tables -A FORWARD -j ACCEPT - само собой. /var/run/radvd.conf меняем: В префиксе: AdvAutonomous off; на on - позволит дать клиентам адреса AdvPreferredLifetime 0; на значение в минутах (1440) - не совсем понял на кого влияет - на клиента или на роутер. Но без этой настройки на клиентах ipv6 хоть и назначен, но не работает. В общей части AdvDefaultLifetime 0; на значение в минутах (1440) - позволит назначить роутер маршрутизатором ipv6 по умолчанию для клиентов. /var/run/radvd.conf менять придётся после КАЖДОГО изменения статуса КАЖДОГО интерфейса. Во всяком случае локального - точно. Ну из killall -s HUP radvd Имеем нативный ipv6 на клиентах кинетика по цепочке: Клиент->Роутер->(wg)->VPS->(tun6in4)->HE->IPV6 internet. Ровно до изменения статуса какого-либо интерфейса. Осталось автоматизировать. По идее, если IPV6 получаем только статичные - можно просто сделать копию radvd.conf и подкладывать её перед перезапуском radvd. Но если есть ещё провайдерский ipv6 то нужно менять в файле как то А самое интересное что для 6in4 это всё отлично работает. Только вот мой пров включив нативный ipv6 похоже, перестал пропускать 6in4 трафик
-
Стоял Bird2 на Ultra (1011). Скрипт собирал маршруты с антизапрета, плюс свои. Всё писал в конфиг для птички. В тотале получался файл 2,86мб 80к+ (последний раз было 85535) маршрутов. Без проблем вообще. Когда добавил ему IPV6 (+118670 маршрутов) - закряхтел, но переварил. То есть, 204.2k маршрутов он способен держать и маршрутизировать. Отказался - был косяк в системе OPKG в целом. Сейчас снова настраиваю это дело.
- 3 ответа
-
- 1
-
-
После обновления появилась эта же проблема. Туннель 6in4 не создавал шлюз по умолчанию для ipv6. Поднял приоритет 6in4 выше основного подключения провайдера - отвалился ipv4 интернет... То есть, на данный момент лично у меня только один вариант - оставить приоритет подключения к прову выше туннеля и при старте роутера выполнять ipv6 route default <ipv6 gateway> Сделали бы хоть возможность этот маршрут сохранять при перезагрузке... Ну, или без NDM выполянть команды при запуске.
-
Попробуйте как выше указано: 1. protocol kernel kernel_routes { learn; scan time 60; ipv4 { import none; export all; }; kernel table 1000; # kernel routing table number #device routes yes; ##### } ^^^^^^^^^^^^^ Закоментить или раскомментить device routes (Уже не помню, почему у меня закомментировано) 2. protocol bgp antifilter { import filter { if martians() then reject; ifname = "wg0"; #accept; reject; }; export none; local as 64999; # local default as-number neighbor 45.154.73.71 as 65432; multihop; hold time 240; preference 250; } ^^^^^^^^^^^ добавить ifname = "wg0"; Не знаю, помогает ли чем-то multihop, но у меня работало без ошибок. А вообще, если работает, несмотря на эту запись в логе, то отправить лог в null и концы в воду...
-
Не помогло Наверное, переведу это дело тоже в Entware... Апстрим до VPS уже через Entware создаётся. Штатный клиент переставал работать через некоторое время. Помогала только смена ttl. Убрал штатный клиент и завёл его через Entware - всё работает, "ни единого разрыва" Теперь, видимо, пришла пора и сервер там же строить...
-
Добрый день! А вот эту жесть тоже только отрубив журналирование kernel можно победить? kernel: wireguard: Wireguard0: handshake for peer "PEER ID STOLEN BY UFO" (1) (172.16.1.2:0) did not complete after 5 seconds, retrying (try 2) У меня всего 2 клиента настроено, но среди спама что Wireguard генерит что то прочесть не реально
-
На трейсы бы глянуть с устройств и с самого кинетика. Только сейчас обратил внимание, что при установке подсети /24 при создании интерфейса через веб-морду, а так же командой ip - маска ставится /32. И только ifconfig смог установить её в /24. Но разницы не вижу. Работает и так и так при условии, что устанавливает BGP-сессию через туннель. Как только включил лог - снова спам о "странном" next-hop... Где то читал, что bird вообще плохо дружит с P-t-P интерфейсами. Да и по большому счёту он для другого пердназначен, вроде как. Сколько ни читал документации, форумов и мануалов по нему - складывается впечатление, что мы с его помощью из пушки по воробьям лупим
-
Коллеги, Столкнулся с тем, что иногда Wireguard на Cloudflare перестаёт работать. Просто в логе куча строк о просроченном рукопожатии или что то такое. Не помню, да и не важно. Ни ребуты, ни пересоздание подключения с нуля не помогают. Через время начинает работать сам. При этом интерфейс остаётся up, и скрипты в ifstatechanged.d не выполняются. С вытекающей невозможностью остановить bird от маршрутизацию через него оттуда. А у меня, например он роутит целыми ASN'ами Например, Гугл - весь идёт через Cloudflare. Ибо живу в Крыму, и неработающий Play Market и частые 403 от гугла на всяких сайтах достали. Так вот такой вот костыль я для себя накрутил сегодня. Может, кому пригодится. Создал скриптик CF-Watchdog.sh вот с таким содержанием: Символьную ссылку на него в /opt/etc/cron.1min и имеем проверку работоспособности маршрутизации через Cloudflare каждую минуту, и по необходимости остановку/перезапуск bird Сорян, что комменты на буржуйском - мне так почему то удобнее...
-
А ведь и правда... Спасибо за пинок:) Нашел в чем дело. В /opt/etc/ndm/ifstatechanged.d/010-add_antizapret_route.sh строка, создающая пресловутую 1000-ю таблицу в общем случае не должна быть привязана к интерфейсу. (Ну, или должна, если это реально необходимо) Тогда получим и на роутере: -bash-5.1# traceroute -n rutracker.org traceroute to rutracker.org (195.82.146.214), 30 hops max, 38 byte packets 1 172.16.0.1 49.299 ms 49.451 ms 49.580 ms 2 172.68.9.1 50.409 ms 50.080 ms 50.267 ms И т.д... И на клиенте: Трассировка маршрута к rutracker.org [195.82.146.214] с максимальным числом прыжков 30: 1 <1 мс <1 мс <1 мс 192.168.0.1 2 49 ms 49 ms 49 ms 172.16.0.1 3 51 ms 59 ms 145 ms 172.68.9.1 И т.д...
-
Как понимаю, вопрос на данный момент не актуален? Странно. И всё же, поделюсь своим изысканием. Поднят Wireguard интерфейс. ВПН в сторону Cloudflare. Довольно скоро я узнал, что они дают только 1Гб трафика (на день? месяц? год? - ещё не понял) Но тут не об этом. При настройке Wireguard наш интерфейс имеет адрес 172.16.0.2 и P-t-P:172.16.0.2 Почему то, этот адрес не нравится Bird'у и при следовании инструкциям тут и в этой теме я не получал заполнение таблицы маршрутами. Выяснилось, что ошибку вызывает строка gw = 172.16.0.2; # override route nexthop Гугление дало ещё пару вариантов её замены: #bgp_next_hop = 172.16.0.2; #ifname = "nwg0"; Но и они не работают. В итоге, появилось неочевидное решение: protocol static static_routes { import all; route 163.172.210.8/32 via 172.16.0.2; } И каким то образом это даёт желаемый эффект. НО При таком раскладе в лог спамится строка вида: bird4: KRT: Received route with strange next-hop для КАЖДОГО маршрута. И спамится она туда ПОСТОЯННО. При каждом сканировании ядром таблицы, как я понимаю. Вроде бы, этот спам ни на что не влияет, потому можно просто указать scan time 0: protocol kernel kernel_routes { scan time 0; import none; export all; kernel table 1000; # kernel routing table number } Пока трафик ещё оставался - вроде работало. По прошествии нескольких дней с момента настройки таблица на месте. Может, кому то пригодится. А может, кто то сможет это дело понять и подсказать что нужно. Вроде бы где то проскакивало что next-hop должен быть доступен via direct или как то так, и что бы bird и kernel были счастливы нужно указать что этот интерфейс всегда up или что то в этом духе. Прочитал это мельком, не придал значения в тот момент. И как это сделать тоже не знаю.