Pitäisikö IPv6-liikenteen kulkea VPN:n kautta vai suoraan?
Päättäkää, kuuluuko ::/0 tunnelin sisään, kolmen ehdon perusteella: ulostulon tuki, päätepisteen tavoitettavuus ja vain paikalliset verkot.
Kaksi ihmistä pyysi minulta viime kuussa vastakkaisia tuloksia: toinen halusi IPv6:n VPN:n piiriin, toinen halusi toimiston tulostimen jatkavan toimintaa. Yksi reitti ::/0 ei voi tarjota molempia yksin. Se, kuuluuko reitti tunnelin sisään, riippuu kolmesta ehdosta, ja ensimmäinen sulkee sen pois useimmilta kaupallisilta ulostuloilta. Jos ulostulo ei kanna IPv6:ta, oletusreitin ohjaaminen sinne piilottaa liikenteesi tunneliin, jolla ei ole paikkaa, jonne sen lähettää.
Kolme ehtoa ratkaisevat vastauksen
Oletusreitti on yksi rivi, ::/0, ja se sopii mihin tahansa IPv6-kohteeseen, jolla ei ole tarkempaa reittiä (RFC 4291). Sen asentaminen on helppoa. Päätös siitä, pitäisikö sinun, palautuu kolmeen ehtoon.
Ehto yksi: ulostulossa, johon yhdistät, on toimiva IPv6 ja se on valmis välittämään sitä. Ehto kaksi: asiakkaasi voi pitää polun tunnelin päätepisteeseen, joka sijaitsee yleensä alueella, jota olet reitittämässä. Ehto kolme: voit nimetä paikalliset IPv6-kohteet, joiden on pysyttävä tunnelin ulkopuolella.
Jokainen ehto epäonnistuu omalla tavallaan, ja siksi arvaaminen maksaa kokonaisen illan. Epäonnistunut ehto yksi antaa sinulle hiljaisuuden ja reititystaulun, joka näyttää oikealta. Epäonnistunut ehto kaksi tappaa kättelyn muutama sekunti sen alkamisesta. Epäonnistunut ehto kolme jättää toimivan tunnelin ja tyytymättömän kollegan tulostimen luo.
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
Kantaako ulostulo todella IPv6:ta?
Tunneliliittymä, jolla on IPv6-osoite, ei todista mitään toisesta puolesta. Monet kaupalliset profiilit ovat sisältä vain IPv4: palvelin antaa sinulle v4-osoitteen ja pudottaa kaiken muun. Asenna sen päälle oletusreitti AllowedIPs:sta, ja ydin lähettää mielellään IPv6:ta liitäntään, jonka vastapuoli ei koskaan näe sitä.
Testaa asiakkaasta, kun tunneli on ylhäällä. ping -6 -c 3 2001:4860:4860::8888 ja ip -6 route get 2001:4860:4860::8888 vastaavat eri kysymyksiin: tuleeko vastaus takaisin ja minkä laitteen ydin valitsi. Kun jälkimmäinen nimeää tunnelisi ja ensimmäinen ei palauta mitään, ongelma on ulostulossa, ei reitissä.
Jos hallitset ulostuloa itse, asiakastesti voi mennä läpi ja polku voi silti päättyä umpikujaan. Vahvista net.ipv6.conf.all.forwarding=1 yhdyskäytävässä ja että sen palomuuri hyväksyy tunnelista välitetyt paketit. Oikein reititetty paketti ulostuloon, joka kieltäytyy välittämästä, näyttää asiakkaan puolelta täsmälleen reititysvirheeltä.
Voiko asiakas pitää polkunsa päätepisteeseen?
Tämä on se tapaus, joka nappasi minut kannettavalla, jonka WireGuard-päätepiste oli vain IPv6. Päätepisteen osoite on tavallinen globaali osoite, joten se osuu ::/0:n sisään. Reititä koko etuliite liitäntään, ja kättelypaketit ajavat itsensä tunneliin, jota ne vielä yrittävät rakentaa. Tunneli ei koskaan nouse, eikä mikään asiakkaan tulosteessa kerro miksi.
wg-quick hoitaa tämän Linuxissa. Se johtaa reitit AllowedIPs:sta, asentaa ne omaan tauluunsa ja lisää käytäntösäännön, jotta liikenne päätepisteeseen ratkaistaan ensin päätaulun kautta: sääntö suppress_prefixlength 0, jonka löydät ip -6 rule:sta. Siksi wg-quick up onnistuu siellä, missä käsin kirjoitettu ip -6 route add default dev wg0 katkaisee yhteytesi.
Tarkista molemmat tilat ip -6 route get <endpoint-v6>:llä, ennen tunnelin nostamista ja sen jälkeen. Jos vastaus vaihtuu tunnelilaitteeseesi, olet poistanut polun, jota tunneli tarvitsee. Kun kirjoitat reitit itse, lisää isäntäreitti päätepisteeseen alkuperäisen yhdyskäytävän kautta, tai yhdistä päätepisteeseen IPv4:n kautta ja jätä IPv6 hyötykuormalle.
Mikä on pidettävä tunnelin ulkopuolella?
Tarkemmat reitit voittavat oletusreitin, joten linkillä oleva etuliite tai ULA-alue omalla reitillä jatkaa toimintaansa ilman lisävaivaa. Tämä on hiljainen syy siihen, miksi niin monet täyden tunnelin IPv4-asetukset selviävät: LAN-etuliitteet ovat tarkempia kuin oletus eivätkä koskaan päädy tunneliin.
Se rikkoutuu, kun paikallinen laite on tavoitettavissa globaalin osoitteen kautta, mikä on tavallista tulostimelle, jolle sama reititin antoi julkisen etuliitteen, NAS:lle tai televisiolle. Ne osoitteet vastaavat ::/0:tä eivätkä mitään muuta, joten ne siirtyvät tunneliin kaiken muun mukana ja katoavat.
Päätä kohdekohtaisesti, älä protokollakohtaisesti. Jos kaksi tai kolme paikallista isäntää on tärkeitä, anna niiden etuliitteille reitti fyysisen liitännän kautta ulos, tai poista ne neuvotellusta joukosta. Jos lista jatkaa kasvamistaan, rehellinen vastaus on split tunneling IPv6:lle kirjallisella poikkeuslistalla, ei oletusreitti, jota paikkaat jatkuvasti.
Jos vastaus on ei, estä se
IPv6:n jättäminen reitittämättä ei ole sama kuin sen rauhaan jättäminen. Isäntä, jolla on toimiva IPv6-oletusreitti, käyttää sitä edelleen, kun tunneli kuljettaa IPv4:ää, joten liikenne poistuu VPN:n vierestä ja jokainen IPv6:ta suosiva palvelu näkee todellisen osoitteesi. Se on vuoto, ei jaettu tunneli.
Valitse yksi ja kirjoita muistiin, minkä valitsit. Reititä oletus ja hyväksy yllä olevat kompromissit, tai poista IPv6 käytöstä tunnelin keston ajaksi. Etuliitteen jättäminen pois AllowedIPs:sta ei riitä yksinään, koska käyttöjärjestelmä pitää oman oletuksensa. Linuxissa karkea versio on sysctl -w net.ipv6.conf.all.disable_ipv6=1; hienompi versio pudottaa IPv6:n tunnelin ulkopuolelle palomuurisäännöllä. Puhelinasiakkaissa on erillinen IPv6:n estokytkin, joka tekee saman työn.
Vahvista se kuin vuoto
Nosta tunneli ja lue tila sen sijaan, että luottaisit kytkimeen. ip -6 route show default:n pitäisi näyttää yksi oletus, ja ip -6 route get:n pitäisi nimetä tunnelilaite LAN:isi ulkopuoliselle kohteelle. Toista molemmat yhteyden katkaisun jälkeen: oletus, joka elää tunnelia pidempään, on se virhe, jota etsit.
Testaa sitten toinen suunta. Saavuta paikallisverkon isännästä asiakas sen paikallisella IPv6-osoitteella. Jos se lakkaa toimimasta, ehto kolme ei koskaan täyttynyt, mitä reititystaulu silloin väitti.
Kirjoita tulos sinne, mistä seuraava henkilö löytää sen: mitkä etuliitteet pysyvät paikallisina, miksi ja mitä asiakas tekee yhteyden katkaisun jälkeen. Kaksi riviä runbookissa säästää seuraavan insinöörin päätepistesilmukan uudelleenlöytämiseltä keskiyöllä.