IPv6 OpenVPN-tunnelin läpi: katsaus kotireitittimeen

Kannettavassa on IPv6-osoite, tunneli on pystyssä IPv4:n yli, ja silti jokainen IPv6-testi epäonnistuu. Tai pahempaa: testi onnistuu ja liikenne lähti operaattorin polulle koskaan tunneliin päätymättä. Molemmat tulokset palautuvat yhteen puuttuvaan päätökseen: kukaan ei antanut reitittimelle etuliitettä, jonka se voisi reitittää asiakkaille. Polun kulkeminen asiakkaasta ulospäin löytää, mikä pala puuttuu.

Aloita siitä, missä asiakas on

Katso asiakasta ennen kuin kosket palvelinta. ip -6 addr näyttää poolista tulevan tunneliosoitteen ja ip -6 route näyttää työnnetyn etuliitteen, joka osoittaa tunnelilaitteeseen. Kun osoite on mutta reitti ei, push puuttuu tai asiakas jätti sen huomiotta. Kun kumpaakaan ei ole, palvelin ei jakanut yhtään mitään.

Tarkista sitten, mitä asiakas uskoo ulkomaailmasta. Tunnelin yli kulkeva oletusreitti vaatii kaiken IPv6-liikenteen, kun taas reitti 2000::/3:lle vaatii vain globaalin unicastin. Molemmat voivat olla oikein, ja ne vastaavat eri vuotokysymyksiin.

Asiakas, jolla ei ole lainkaan IPv6-oletusreittiä, epäonnistuu jokaisessa julkisessa testissä, vaikka tunneli itsessään on täysin terve. Se on politiikan aukko, ei rikkinäinen tunneli.

Tarkista pooli, jonka palvelin todella pystyy reitittämään

Palvelin voi jakaa vain etuliitteestä, jota se todella hallitsee. Jos operaattori delegoi /56:n, varaa yksi /64 tunnelille ja jätä loput LANille. Kun operaattori antaa WANilla vain yhden /64:n eikä reititä enempää, jätä LANin etuliite rauhaan ja anna tunnelille ainutlaatuinen paikallinen alue, hyväksyen että asiakkaille ei ole globaalia ulostuloa.

Pooli ja push kuuluvat yhteen. server-ipv6 2001:db8:80:10::/64 jakaa osoitteita ja push "route-ipv6 2000::/3" kertoo asiakkaille, mitä tunneliin lähetetään. 2000::/3:n työntäminen kattaa globaalin unicastin ja jättää link-local- ja multicast-alueet tunnelin ulkopuolelle.

Kirjoita valittu etuliite käyttöönottopöytäkirjaan. Seuraavan kerran operaattorin luovutusta muuttavan on tiedettävä, minkä /64:n tunneli jo varaa.

Kytke edelleenlähetys päälle toiselle perheelle

IPv4:n edelleenlähetys ei tarkoita IPv6:n edelleenlähetystä. Aseta net.ipv6.conf.all.forwarding=1 ja peilaa kaikki, mihin IPv4:n FORWARD-käytäntö jo antaa luvan. Reitittimellä, jonka FORWARD-ketju pudottaa oletuksena, puuttuva sääntöjoukko näyttää täsmälleen kuolleelta tunnelilta.

Kättely onnistuu, asiakas saa osoitteen, eikä mitään tule takaisin. Lisää säännöt molemmille suunnille ja WAN-haaralle, koska tunneli, joka saavuttaa LANin mutta ei internetiä, epäonnistuu kolmannessa testissä. Katso ketjun laskureita epäonnistuneen yrityksen jälkeen, koska sääntö, joka ei koskaan osunut, on eri ongelma kuin se, joka osui ja pudotti.

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

Yksi sivuvaikutus nappaa ne, jotka lopulta syyttävät tunnelia. Edelleenlähetyksen kytkeminen saa ytimen ohittamaan osoitekonfiguraation Router Advertisementilla, ellet sano toisin, ja niin opittu oletusreitti katoaa sen mukana. Joko kiinnitä eksplisiittinen oletusreitti WAN-rajapinnalle tai aseta accept_ra siellä tarkoituksella arvoon 2. Kummankin muutoksen jälkeen varmista, että reitittimellä on yhä käyttökelpoinen IPv6-polku ulos, ennen kuin testaat asiakkaita uudelleen.

Vastaa naapurin löytämiseen, kun ylävirta ei reititä

Ylävirran laitteet kohtelevat delegoitua /64:ää joskus omana linkkinään ja kieltäytyvät reitittämästä alietuliitettä VPN-laatikkoon. Kun näin käy, jonkin on vastattava naapurikyselyihin jokaiselle asiakasosoitteelle erikseen.

OpenVPN altistaa jaetun osoitteen client-connect-koukulle, joten merkinnät voivat seurata todellista poolia käsin ylläpidetyn listan sijaan. Koukku lisää ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, ja vastaava client-disconnect-koukku poistaa sen. Ilman poistoa proxy-taulu vanhenee ja myöhempi asiakas voi periä merkinnän osoitteelle, jota se ei koskaan saanut. Vahvista tila komennolla ip -6 neigh show proxy.

Pidä proxya kiertotienä. Staattinen reitti tunnelin /64:lle reititintä kohti kestää asiakkaiden vaihtumisen eikä vaadi lainkaan etuoikeutettua shell-koukkua.

Seuraa polkua ulospäin, hyppy hypyltä

Testaa ulospäin kolmessa vaiheessa: ensin reitittimen tunneliosoite, sitten LAN-isäntä ja kolmanneksi julkinen kohde traceroute6:lla. Poolin todistaa ensimmäinen, edelleenlähetyksen ja LAN-palomuurin toinen ja paluupolun ylävirran kautta kolmas. Jokainen epäonnistuminen rajaa haun yhteen laitteeseen sen sijaan, että koko suunnittelu avattaisiin uudelleen.

Varo tunnelin MTU:ta, koska polun IPv6-reitittimet eivät pilko puolestasi. Liian suuri MTU näkyy packet-too-big-virheenä ja jumittuneena TLS:nä eikä puhtaana epäonnistumisena. Aseta se eksplisiittisesti ja testaa rajaa lähellä olevalla hyötykuormalla.