Linux-те қайта бағыттауды қосқан соң IPv6 әдепкі маршруты жоғалды

VPN клиенттерінің трафигін өткізуі үшін Debian шлюзіне net.ipv6.conf.all.forwarding=1 қойдым, ал жарты сағат шамасында машинада IPv6 әдепкі маршруты мүлдем қалмады. Жоғарғы маршрутизатор жұмыс істеп тұрды, link-local көршісі әлі жауап берді, ал uplink өзінің ғаламдық мекенжайын сақтап қалды. Тоқтағаны ядроның сол интерфейсте router advertisements қабылдауды жалғастыруға деген ынтасы еді. Мен sysctl енгізген сәтте маршрут жоғалған жоқ; ол RA-дан үйренген әдепкі маршруттың өмірі біткенде жоғалды және оны ештеңе жаңартпады.

Бір қарағанда ештеңе бұзылған сияқты көрінбеді. Қайта бағыттау жұмыс істеді, ескі маршрут кэште тұрғанша клиенттер өте берді, ал ақау оны тудырған өзгерістен кейін келді. Дәл осы кідіріс бұны жоғарғы жаққа немесе ешқашан қатыспаған firewall ережесіне жабуға себеп болады.

Кез келген sysctl-ге тимес бұрын маршрут кестесін оқыңыз

ip -6 route show default-ден бастап атрибуттарды оқыңыз, тек шлюзді емес. RA-дан үйренген әдепкі маршрут proto ra деп белгіленген, басымдық тасымалдайды және expires кері санағын көрсетеді. Қолмен қосылған маршрутта олардың екеуі де жоқ, және бұл айырмашылық маршрутқа қай механизм ие екенін айтады.

$ ip -6 route show default
default via fe80::1 dev eth0 proto ra metric 1024 expires 1432sec hoplimit 64 pref medium

Содан кейін мекенжайға қараңыз: ip -6 addr show dev eth0. Сағатпен өлшенген қалаулы және жарамды өмір сүру мерзімі бар ғаламдық мекенжай, маршрутизатор мерзімі минутпен өлшенетін әдепкі маршруттан ұзағырақ өмір сүреді. Мекенжай бар, ал әдепкі маршрут жоқ, бұл хабарландыру мәселесінің белгісі. Мекенжай да жоқ болса, ең алдымен байланыс, префикс туралы ақпарат немесе қайталанған мекенжайларды анықтау жағын қарау керек.

Неліктен қайта бағыттау RA өңдеуді өшіреді

RA дегеніміз 134 типті ICMPv6 пакеті, ол 255 секіру шегімен link-local көзден жіберіледі. Ядро оны пайдаланбас бұрын интерфейстің accept_ra мәнін тексереді. Әдепкі мән 1, ал 1 «иә» дегенді білдірмейді. Ол: осы хост қайта бағыттамағанша қабылда дегенді білдіреді. forwarding=1 мәнін қойсаңыз, бұл шарт орындалмайды, сондықтан хабарландыру ішіндегі кез келген префикс немесе әдепкі маршрутизатор қарастырылмай тұрып тасталады.

Үш мән бар, ал қайта бағыттаудан тек үшіншісі аман қалады:

Тағы екі жалауша не шын мәнінде орнатылатынын шешеді. accept_ra_defrtr хабарландырудағы әдепкі маршрутизатордың маршрутқа айналатынын басқарады, ал accept_ra_pinfo префикс туралы ақпараттың мекенжай конфигурациясына пайдаланылатынын басқарады. accept_ra_defrtr өшіру, қайта бағыттайтын хостта әдепкі маршрутты үйренбей-ақ SLAAC мекенжайларын сақтаудың әдеттегі жолы. Бұл accept_ra-ден өзге тұтқа, және мекенжай керек, ал маршрут керек болмағанда соған жүгінесіз. Ядроның IP sysctl анықтамасы үшеуін де тізіп береді.

Оны үш командамен растаңыз

Алдымен жүктелді деп ойлайтын файлдың орнына тірі мәндерді оқыңыз:

sysctl net.ipv6.conf.eth0.forwarding net.ipv6.conf.all.forwarding \
       net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_defrtr

Екіншіден, хабарландырулардың әлі келетінін дәлелдеңіз. ICMPv6 тип байты бойынша сүзу жеткілікті және көршілерді анықтау трафигінің қабырғасын оқудан құтқарады:

tcpdump -ni eth0 'icmp6 and ip6[40] == 134'

Егер бірнеше минут бойы ештеңе көрінбесе, accept_ra сіздің мәселеңіз емес. Жоғарғы жақ хабарландыруды тоқтатты, жолдағы бірдеңе ICMPv6 сүзеді немесе бұл интерфейс шынымен сіз ойлаған сегментте емес. Үшіншіден, хабарландыруды өзіңіз сұрап, оның өрістерін оқыңыз:

rdisc6 eth0

rdisc6 Debian және Ubuntu-да ndisc6 пакетінде келеді. Шығыста маршрутизатор мерзімі мен басымдыққа қараңыз, басқа нәрсені өзгертуден бұрын. Маршрутизатор мерзімі 0 болатын хабарландыру әдепкі маршрутизаторды жою туралы нұсқау, және ешбір accept_ra мәні оны пайдалы маршрутқа айналдырмайды. Осылайша көпір режиміндегі жоғарғы CPE-ні де ұстайсыз, ол префикстерді таратады, бірақ өзін маршрутизатор ретінде ұсынбайды.

Uplink-ті жалғыз рұқсат ететін интерфейс етіңіз

Егер жоғарғы жақ әдепкі маршрутизатор болуы керек болса, қайта бағыттауға қарамастан хабарландыруларды сол жерде қабылдаңыз, басқа жерде емес:

# /etc/sysctl.d/60-ipv6-router.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.eth0.accept_ra_defrtr = 1

Шектеу маңызды, өйткені Linux-те IPv6 қайта бағыттау бір ғаламдық ажыратқыш, әр байланысқа бір емес. net.ipv6.conf.wg0.forwarding ішіне 1 жазып, сосын net.ipv6.conf.all.forwarding оқыңыз: ғаламдық мән аударылады және әр интерфейс қайта бағыттай бастайды. Сіз туннельде маршрутизатор, ал LAN-да қарапайым хост бола алмайсыз. Шектеуге болатыны қабылдау. accept_ra=2 мәнін uplink-те ұстап, туннель мен LAN интерфейстерін 1 немесе 0-де қалдырыңыз, сонда туннель арқылы келген адасқан хабарландыру оған бағытталған әдепкі маршрутты орната алмайды.

Уақытша sysctl -w келесі қайта жүктеуден аман қалмайды, ал systemd-networkd та, NetworkManager де бұл мәндерді өз конфигурациясынан жазады. networkd-те uplink-тің .network файлында IPv6Forwarding=yes және IPv6AcceptRA=yes орнатыңыз; networkd IPv6Forwarding-ті ядродағы сол себеппен ғаламдық деп сипаттайды. NetworkManager-де uplink-тегі ipv6.method=auto accept_ra мәнін басқарады, сондықтан nmcli connection up кейін sysctl-ді қайта оқыңыз, бірінші тексеруге сенбей.

Статикалық балама, ip -6 route add default via fe80::1 dev eth0, шынымен жұмыс істейді және жоғарғы маршрутизатордың тұрақты link-local мекенжайы болғанда ақылға қонымды жауап. Неден бас тартатыныңызды анық біліңіз. Статикалық әдепкі маршрут ешқашан жаңартылмайды және ешқашан қайтарылмайды, сондықтан жоғарғы жақ ауыстырылғаннан кейін де өлі көршіге нұсқай береді. RA маршруты қауіпсіз түрде істен шығады; статикалық маршрут үнсіз істен шығады.

Шлюздің өз пакетін емес, қайта бағытталған пакетті тексеріңіз

Шлюздің өз пингтері ешбір клиент пайдалана алмайтын маршрутпен сәтті өтуі мүмкін, әрі шлюз көз болғандықтан да сәтті болуы мүмкін. Қосылған клиенттен тексеріңіз, содан кейін шлюзден сол клиенттің мекенжайы үшін не істейтінін сұраңыз:

# on the VPN client
ping -6 -c 3 2001:4860:4860::8888

# on the gateway, using a client address
ip -6 route get 2001:4860:4860::8888 from fd42:20::2

Содан кейін бір маршрутизатор мерзімін күтіп, қайта қараңыз. Сіз қалайтын тұрақты күй, proto ra деп белгіленген әдепкі маршрут, оның expires мәні үнемі қалпына келеді, қоса all.forwarding=1. Егер expires тек кері санаса, хабарландырулар әлі де бір жерде тасталып жатыр, ал әдеттегі кінәлі — жүктелу кезіндегі sysctl орындалып болған соң accept_ra мәнін қайта жазатын желі менеджері.

Мұны жаппас бұрын төрт нәрсені растаңыз: әдепкі маршрут proto ra және жаңарып тұр, accept_ra=2 тек uplink-ке қатысты, қайта бағыттау қайта жүктеуден кейін де, менеджер қайта іске қосылғаннан кейін де 1, және IPv6 пингті шлюз емес, клиент аяқтайды. Егер клиент сау маршрутпен әлі де сәтсіз болса, келесі күдікті қайтару жолы немесе жоғарғы firewall, хабарландыру емес.