Eltűnt az IPv6 alapértelmezett útvonal a továbbítás bekapcsolása után Linuxon

Beállítottam net.ipv6.conf.all.forwarding=1 egy Debian-átjárón, hogy továbbíthassa a VPN-kliensek forgalmát, és körülbelül fél órával később a gépnek már nem volt IPv6-os alapértelmezett útvonala. A felső útválasztó működött, a link-local szomszéd még válaszolt, és az uplink továbbra is tartotta a globális címét. Ami megszűnt, az a kernel hajlandósága volt, hogy továbbra is fogadja a router advertisements üzeneteket azon a interfészen. Az útvonal nem akkor tűnt el, amikor beírtam a sysctl-t; akkor tűnt el, amikor az RA-ból tanult alapértelmezett útvonal élettartama lejárt, és semmi nem újította meg.

Első pillantásra semmi nem tűnt töröttnek. A továbbítás működött, a kliensek addig átjutottak, amíg a régi útvonal a gyorsítótárban volt, és a hiba később érkezett, mint az azt okozó változás. Pont ez a késés az oka, hogy a felső oldalt vagy egy olyan tűzfalszabályt okolnak, amely soha nem vett részt a dologban.

Olvassa el az útvonaltáblát, mielőtt bármelyik sysctl-hez nyúl

Kezdje a ip -6 route show default paranccsal, és olvassa az attribútumokat, ne csak az átjárót. Az RA-ból tanult alapértelmezett útvonal proto ra jelöléssel szerepel, preferenciát hordoz, és expires visszaszámlálót mutat. A kézzel hozzáadott útvonalon egyik sincs, és ez a különbség megmondja, melyik mechanizmus birtokolja az útvonalat.

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

Utána nézze meg a címet: ip -6 addr show dev eth0. Egy globális cím, amelynek előnyben részesített és érvényes élettartama órákban mérhető, túlél egy olyan alapértelmezett útvonalat, amelynek útválasztó-élettartama percekben mérhető. Cím van, alapértelmezett útvonal nincs, ez a hirdetési probléma aláírása. Ha a cím is hiányzik, először a kapcsolattal, a prefix-információval vagy az ismétlődő címek felderítésével kell foglalkozni.

Miért kapcsolja ki a továbbítás az RA feldolgozását

Az RA egy 134-es típusú ICMPv6-csomag, amelyet link-local forrásból, 255-ös ugrási korláttal küldenek. Mielőtt a kernel használná, ellenőrzi az interfész accept_ra értékét. Az alapértelmezett érték 1, és az 1 nem jelent igent. Azt jelenti: csak addig fogadd el, amíg ez a gazdagép nem továbbít. Állítsa be a forwarding=1 értéket, és ez a feltétel nem teljesül, ezért a hirdetés eldobásra kerül, mielőtt bármilyen benne lévő prefixet vagy alapértelmezett útválasztót figyelembe vennének.

Három érték létezik, és a továbbítást csak a harmadik éli túl:

Két további jelző dönti el, mi települ valójában. A accept_ra_defrtr azt vezérli, hogy a hirdetésben szereplő alapértelmezett útválasztóból lesz-e útvonal, a accept_ra_pinfo pedig azt, hogy a prefix-információt használják-e a címkonfigurációhoz. A accept_ra_defrtr kikapcsolása a szokásos módja annak, hogy SLAAC-címeket tartson egy továbbító gazdagépen anélkül, hogy alapértelmezett útvonalat tanulna. Ez más kar, mint a accept_ra, és akkor nyúl hozzá, ha címeket akar, de útvonalat nem. A kernel IP sysctl referenciája mindhármat felsorolja.

Erősítse meg három paranccsal

Először az élő értékeket olvassa ki a feltételezett fájl helyett:

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

Másodszor bizonyítsa, hogy a hirdetések még megérkeznek. Az ICMPv6 típusbájt szerinti szűrés elegendő, és megkíméli a szomszédok felderítési forgalmának falától:

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

Ha több percen át semmi nem jelenik meg, akkor a accept_ra nem az Ön problémája. A felső oldal abbahagyta a hirdetést, valami az útvonalon szűri az ICMPv6-ot, vagy az az interfész valójában nem abban a szegmensben van, amelyre gondol. Harmadszor kérjen hirdetést saját maga, és olvassa el a mezőit:

rdisc6 eth0

A rdisc6 a ndisc6 csomagban érkezik Debianon és Ubuntun. A kimenetben nézze meg az útválasztó élettartamát és a preferenciát, mielőtt bármi mást módosítana. A 0 útválasztó-élettartamú hirdetés utasítás az alapértelmezett útválasztó eltávolítására, és egyetlen accept_ra érték sem tesz belőle használható útvonalat. Így kapja el a híd módú felső CPE-t is, amely prefixeket oszt, de soha nem kínálja fel magát útválasztóként.

Tegye az uplinket az egyetlen megengedő interfésszé

Ha a felső oldalnak kell lennie az alapértelmezett útválasztónak, fogadja ott a hirdetéseket a továbbítás ellenére, és sehol másutt:

# /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

A korlátozás azért számít, mert az IPv6-továbbítás Linuxon egyetlen globális kapcsoló, nem egyenként minden linkre. Írjon 1-et a net.ipv6.conf.wg0.forwarding helyére, majd olvassa ki a net.ipv6.conf.all.forwarding értékét: a globális érték átbillen, és minden interfész továbbítani kezd. Nem lehet egyszerre útválasztó az alagúton és egyszerű gazdagép a LAN-on. Amit korlátozhat, az az elfogadás. Tartsa az accept_ra=2 értéket az uplinken, az alagút és a LAN interfészeit pedig hagyja 1 vagy 0 értéken, hogy az alagúton érkező elkóborolt hirdetés ne telepíthessen beléje mutató alapértelmezett útvonalat.

Az ideiglenes sysctl -w nem éli túl a következő újraindítást, és a systemd-networkd és a NetworkManager is a saját konfigurációjából írja ezeket az értékeket. A networkdben állítsa be a IPv6Forwarding=yes és a IPv6AcceptRA=yes értékét az uplink .network fájljában; a networkd az IPv6Forwardingot ugyanezen kernelok miatt globálisként dokumentálja. A NetworkManagernél az uplink ipv6.method=auto értéke vezérli az accept_ra értékét, ezért a nmcli connection up után olvassa újra a sysctl-t, ahelyett hogy az első ellenőrzésre hagyatkozna.

A statikus alternatíva, a ip -6 route add default via fe80::1 dev eth0, valóban működik, és ésszerű válasz, ha a felső útválasztónak stabil link-local címe van. Legyen tisztában azzal, miről mond le. A statikus alapértelmezett útvonal soha nem újul meg és soha nem vonódik vissza, ezért a felső oldal cseréje után is egy halott szomszédra mutat. Az RA-útvonal biztonságosan hibázik; a statikus csendben hibázik.

Továbbított csomagot teszteljen, ne az átjáró sajátját

Az átjáró saját pingjei sikerülhetnek olyan útvonalon, amelyet egyetlen kliens sem tud használni, és sikerülhetnek azért is, mert az átjáró a forrás. Teszteljen egy csatlakoztatott kliensről, majd kérdezze meg az átjárót, mit tenne az adott kliens címéért:

# 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

Utána várjon egy útválasztó-élettartamot, és nézzen újra. A kívánt stabil állapot egy proto ra jelölésű alapértelmezett útvonal, amelynek expires értéke folyamatosan visszaáll, valamint a all.forwarding=1. Ha a expires csak visszaszámol, a hirdetéseket még mindig eldobják valahol, és a szokásos bűnös egy hálózatkezelő, amely felülírja a accept_ra értékét, miután a boot idején futó sysctl már lefutott.

Mielőtt lezárja ezt, erősítsen meg négy dolgot: az alapértelmezett útvonal proto ra és megújul, a accept_ra=2 csak az uplinkre vonatkozik, a továbbítás újraindítás után és a kezelő újraindítása után is 1, és az IPv6-pinget egy kliens fejezi be, nem az átjáró. Ha a kliens egészséges útvonal mellett is elbukik, a következő gyanúsított a visszaút vagy egy felső tűzfal, nem a hirdetés.