Sammutetaanko IPv6 VPN-vuodon korjaamiseksi? Päättäkää sen sijaan käytännöstä

IPv6-alueen osoite ilmestyy testisivulle, tunneli ei selvästikään kuljeta sitä, ja internetin suosituin neuvo on sammuttaa IPv6 kaikkialla. Se komento todella vaientaa paneelin. Se myös poistaa protokollan, josta käyttöverkko voi olla riippuvainen, ja jättää sinut ilman aavistustakaan siitä, oliko osoite todellinen vuoto, link-local-liittymäosoite vai resolver, joka tekee työtään. Kolme ehtoa ratkaisee oikean hallinnan, ja vain yksi niistä johtaa estämiseen.

Selvitä, mitä työkalu todella mittasi

Yleisin väärä hälytys on link-local-osoite, joka alkaa fe80: ja on jokaisessa IPv6-kykyisessä liittymässä riippumatta siitä, pääseekö kone internetiin IPv6:n kautta. Se näkyy liittymäluetteloissa ja joissakin sovellusdiagnostiikoissa eikä kerro mitään liikenneväylästäsi.

Toinen väärä hälytys on yksilöllinen paikallinen osoite alueella fc00::/7, joka on verkossa sisäisesti käytetty yksityinen alue. Työkalu, joka tulostaa jokaisen isännän osoitteen, luettelee sen mielellään julkisen rinnalle. Nopeasti lukeva kutsuu sitä vuodoksi ja viettää sitten tunnin ongelmassa, jota ei ole.

Kolmas ei ole lainkaan väärä hälytys. Globaali osoite, joka saavuttaa internetin tunnelin ulkopuolelta, on todellinen vuoto, ja se kannattaa mitata ennen kuin päätät mitään:

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

Jos ensimmäinen komento tulostaa globaalin osoitteen ja kolmas palauttaa julkisen IPv6-osoitteen, joka ei ole tunnelin oma, sinulla on todellinen reitti tunnelin ulkopuolelle. Jos ensimmäinen ei tulosta muuta kuin link-local-merkintöjä, korjattavaa vuotoa ei koskaan ollut.

Kolme ehtoa ratkaisee hallinnan

Päätös ei ole "IPv6 hyvä" tai "IPv6 huono". Päätös on siitä, missä kolmesta tilanteesta olet, ja jokaisella on erilainen oikea vastaus ja erilainen hinta, jos erehdyt.

Ensimmäinen rivi on se, mitä ihmiset yleensä tarkoittavat, ja se on perusteltua. Asiakasohjelma, jonka ulostulossa ei ole IPv6-tukea, ei saisi hiljaa päästää isännän omaa IPv6-liikennettä ulos, koska se on dokumentoitu kaksoispinon vuoto. Tarkoitus on estää se ilmoitettuna käytäntönä, ei sammuttaa protokollaa ytimessä. Näkyvä tulos on sama ja vain toinen niistä voidaan tarkastaa myöhemmin.

Kolmas rivi on kohta, jossa yleisneuvosta tulee aktiivisesti haitallinen. Mobiilioperaattorit ja jotkut kotiliittymät ajavat IPv6-only-verkkoja, joissa on käännös IPv4-kohteille. Poista IPv6 siellä ja poistat ainoan kuljetuksen, jota verkko tarjoaa, mikä tuottaa paljon pahemman katkoksen kuin se, jota olit selvittämässä.

Jos ulostulossa ei ole IPv6:ta, estä se tarkoituksella

Suosi asiakasohjelman omaa mekanismia, koska se pätee täsmälleen niin kauan kuin tunneli on ylhäällä ja palautuu, kun se kaatuu. OpenVPN on tähän vaihtoehto, ja iptablesilla on vastaava sääntö muita asiakkaita varten:

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

Direktiivi kuuluu profiiliin; sääntö kuuluu palomuuriin, jonka voit tarkastaa ja poistaa. Molemmat epäonnistuvat suljetusti, mitä haluat, ja molemmat näkyvät asetusten diffissä, mitä käynnistysskriptiin haudattu ytimen sysctl ei tee.

Kirjaa, miksi se on siellä. Estosäännön ilman kommenttia poistaa seuraava henkilö, joka tarvitsee IPv6:ta johonkin muuhun, ja sitten vuoto palaa hiljaa.

Jos ulostulo kuljettaa IPv6:ta, reititä se ja testaa molemmat perheet

IPv6:n kuljettaminen on parempi vastaus, kun palvelin tukee sitä, eikä se ole paljon vaikeampaa. Vaatimus on, että tunneliliittymällä on osoite siinä perheessä ja että sen oletusreitti osoittaa tunneliin eikä fyysisestä liittymästä ulos:

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.co

Reittihaku on ratkaiseva testi: jos se nimeää tunneliliittymän, IPv6-liikennettä kuljetetaan. Kaksi curl-kutsua vahvistavat sitten, mitä kumpikin perhe näkee, ja niiden vertailu on tapa todistaa, että molemmat polut lähtevät nyt samasta ulostulosta.

Älä pysähdy onnistuneeseen yhteyteen. Yhdistä tunneli uudelleen ja tarkista taas, koska työnnetty IPv6-reitti voi kadota uudelleenmuodostuksessa, jos palvelin lähettää sen vain alkuasetuksissa. Tarkista sitten yksi poissuljettu kohde, koska split-tunnel-säännöt ovat paikka, jossa kaksi perhettä useimmin eroavat.

Jos käyttöverkko on vain IPv6, jätä se rauhaan

Jotkut verkot tarjoavat vain IPv6:ta ja odottavat laitteen saavuttavan IPv4-palvelut operaattorin puolen käännösmekanismin kautta. IPv6:n sammuttaminen sellaisella koneella ei ole turvallisuuden parannus; se poistaa ainoan reitin mihinkään. Se on itse aiheutettu katkos testituloksen vuoksi, jota kukaan ei tarvinnut.

Tämän virheen oire on tunnistettava ja epämiellyttävä: tunneli näyttää muodostuvan, nimien selvitys toimii, eikä mikään lataudu. Jos näet sen IPv6-muutoksen jälkeen, palauta asetus heti ja jatka diagnoosia muualla.

Mitä ikinä valitset, pidä päätös selvästi profiilissa tai palomuurissa, sido se siihen, mitä ulostulo todella tukee, ja merkitse kaksoispinon käyttäytyminen, jota kuvaa RFC 7359:n kaksoispino-keskustelu . Ilmoitettu esto on käytäntö. Sammutettu protokolla on kiertotie, jota kukaan ei voi auditoida, ja testisivulta ne näyttävät samoilta.