Kapcsoljuk ki az IPv6-ot a VPN-szivárgás javításához? Inkább döntsük el a szabályt
A link-local cím nem szivárgás, és a globális IPv6-útvonal sem az. Először válasszon a blokkolás, a továbbítás és a békén hagyás között.
Egy cím az IPv6-tartományból megjelenik egy tesztoldalon, az alagút nyilvánvalóan nem viszi, és az internet legnépszerűbb tanácsa az, hogy kapcsoljuk ki az IPv6-ot mindenhol. Ez a parancs valóban elhallgattatja a panelt. Viszont eltávolít egy protokollt, amelytől a hozzáférési hálózat függhet, és magára hagyja anélkül, hogy tudná, a cím valódi szivárgás, link-local interfészcím vagy egy resolver volt-e, amely a dolgát végzi. Három feltétel dönti el a helyes szabályozást, és csak az egyik vezet blokkoláshoz.
Állapítsa meg, mit mért valójában az eszköz
A leggyakoribb téves riasztás a link-local cím, amely fe80:-tal kezdődik, és minden IPv6-képes interfészen létezik, függetlenül attól, hogy a gép eléri-e az internetet IPv6-on. Megjelenik az interfészlistákban és néhány alkalmazásdiagnosztikában, és semmit nem mond a forgalmi útvonaláról.
A második téves riasztás egy egyedi helyi cím a fc00::/7 tartományban, amely hálózaton belül használt privát tartomány. Egy eszköz, amely a gazdagép minden címét kiírja, szívesen felsorolja a nyilvános mellett. Aki gyorsan olvas, szivárgásnak nevezi, majd egy órát tölt egy nem létező problémával.
A harmadik egyáltalán nem téves riasztás. Az a globális cím, amely az alagúton kívül éri el az internetet, az igazi szivárgás, és érdemes megmérni, mielőtt bármit eldöntene:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coHa az első parancs globális címet ír ki, a harmadik pedig olyan nyilvános IPv6-címet ad vissza, amely nem az alagúté, akkor valódi útvonala van az alagúton kívül. Ha az első csak link-local bejegyzéseket ír ki, soha nem is volt javítandó szivárgás.
Három feltétel dönti el a szabályozást
A döntés nem az, hogy "az IPv6 jó" vagy "az IPv6 rossz". Hanem az, hogy a három helyzet közül melyikben van, és mindegyiknek más a helyes válasza, más költséggel, ha téved.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
Az első sor az, amire az emberek általában gondolnak, és jogos. Az az ügyfél, amelynek kimenete nem támogatja az IPv6-ot, nem engedheti csendben ki a gazdagép saját IPv6-forgalmát, mert az a dokumentált kettős verem szivárgás. A lényeg, hogy deklarált szabályként blokkolja, ne kapcsolja ki a protokollt a kernelben. A látható eredmény ugyanaz, és csak az egyik ellenőrizhető később.
A harmadik sor az, ahol az általános tanács aktívan károssá válik. A mobilszolgáltatók és néhány otthoni kapcsolat IPv6-only hálózatot üzemeltet, IPv4-célokra fordítással. Ha ott eltávolítja az IPv6-ot, eltávolítja az egyetlen átvitelt, amit a hálózat kínál, ami sokkal rosszabb kimaradást okoz, mint amit éppen vizsgált.
Ha a kimenetnek nincs IPv6-ja, blokkolja szándékosan
Részesítse előnyben az ügyfél saját mechanizmusát, mert az pontosan addig érvényes, amíg az alagút áll, és visszaáll, amikor leesik. OpenVPN rendelkezik erre opcióval, és az iptablesnek van megfelelő szabálya más ügyfelek számára:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableAz utasítás a profilba való; a szabály egy tűzfalba, amelyet átnézhet és eltávolíthat. Mindkettő zárt állapotban hibázik, ami a kívánt viselkedés, és mindkettő látható a konfigurációs diffben, ami egy indítószkriptbe temetett kernel-sysctl nem.
Jegyezze fel, miért van ott. A megjegyzés nélküli blokkolási szabályt a következő ember eltávolítja, akinek IPv6 kell valami máshoz, és akkor a szivárgás csendben visszatér.
Ha a kimenet viszi az IPv6-ot, irányítsa és tesztelje mindkét családot
Az IPv6 továbbítása a jobb válasz, ha a szerver támogatja, és nem sokkal nehezebb. A követelmény, hogy az alagút interfészének legyen címe abban a családban, és az alapértelmezett útvonal afelé az alagútba mutasson, ne a fizikai interfész felé:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coAz útvonal-lekérdezés a döntő teszt: ha az alagút interfészét nevezi meg, az IPv6-forgalom továbbítva van. A két curl-hívás utána megerősíti, mit lát az egyes család, és az összehasonlításuk bizonyítja, hogy mindkét útvonal most ugyanazon a kimeneten távozik.
Ne álljon meg egy sikeres kapcsolatnál. Csatlakoztassa újra az alagutat, és ellenőrizze ismét, mert a betolt IPv6-útvonal elveszhet az újraépítéskor, ha a szerver csak a kezdeti konfigurációban küldi. Utána ellenőrizzen egy kizárt célt, mert a split-tunnel szabályok azok, ahol a két család leggyakrabban eltér.
Ha a hozzáférési hálózat csak IPv6, hagyja békén
Egyes hálózatok csak IPv6-ot adnak, és elvárják, hogy az eszköz az IPv4-szolgáltatásokat a szolgáltató oldali fordítási mechanizmuson keresztül érje el. Az IPv6 kikapcsolása egy ilyen gépen nem biztonsági javulás; eltávolítja az egyetlen utat bármihez. Ez saját magának okozott kimaradás egy olyan teszteredmény kedvéért, amelyre senkinek nem volt szüksége.
A hiba tünete jellegzetes és kellemetlen: az alagút úgy tűnik, felépül, a névfeloldás működik, és semmi nem töltődik be. Ha ezt látja egy IPv6-változtatás után, azonnal állítsa vissza a beállítást, és folytassa a diagnózist máshol.
Bármit választ, tartsa a döntést kifejezetten a profilban vagy a tűzfalban, kösse ahhoz, amit a kimenet valóban támogat, és jegyezze fel a kettős verem viselkedését, amelyet az RFC 7359 kettős veremről szóló vitája leír. A deklarált blokkolás szabály. A kikapcsolt protokoll olyan kerülőút, amelyet senki nem tud auditálni, és a tesztoldalról nézve egyformák.