Turvakytkin estää vain IPv4:n: miksi IPv6 vuotaa silti

Tunneli putoaa, turvakytkin ilmoittaa lauenneensa ja lataus jatkuu. IPv4-säännöissä ei ole mitään rikki. Sovellus vain siirtyi reitille, jolle noita sääntöjä ei koskaan kirjoitettu.

Kaksoispinkin laitteilla on kaksi riippumatonta ulospääsyä. Toisen estäminen on puolikas esto.

Kaksi sääntökokonaisuutta, kaksi oletusta

Linuxissa iptables ja ip6tables ovat erillisiä taulukoita, joilla on erilliset käytännöt. IPv4-taulukon INPUT- ja OUTPUT-ketjujen asettaminen DROP-tilaan ei muuta mitään IPv6-taulukossa, jossa oletus on yleensä ACCEPT. Sama jako on olemassa nftablesissa, jossa voit tarkastella yhtä perhettä ja huomata, että vain toinen niistä kantaa sääntöjäsi. Tämä epäsymmetria on normaalia, ja koko ongelma on siinä.

Siksi turvakytkin voi näyttää perusteelliselta ja toimia osittain. IPv4-säännöt kirjoittanut skripti ajettiin, laskurit kasvavat, lokirivi ilmestyy, ja IPv6-paketti lähtee fyysisestä rajapinnasta täysin koskemattomana.

Lue, mitä asiakasohjelmasi todella asentaa, älä sitä, mitä markkinointisivu lupaa. Jotkin asiakkaat ohjaavat IPv6:n tunneliin, jotkut estävät sen tarkoituksella, ja jotkut jättävät sen rauhaan, kun taas alustatason lukitus toteuttaa eri sääntöä. Valmistajan dokumentaatio on ainoa lähde, johon tässä kannattaa luottaa.

Mitä rajapinnan kokoonpano kertoo sinulle

wg-quickin ohjesivu sisältää IPv6-säännöt esimerkkikokoonpanossaan, ja syy on juuri tämä aukko. Esimerkki ei ole koriste. Se on olemassa, koska pelkät IPv4-säännöt jättäisivät toisen perheen avoimeksi.

Esimerkin puolikkaan kopioiminen tuottaa puolikkaan käytännön. Tämä on tämän vuodon yleisin alkuperä. Blogikirjoitus lyhensi esimerkkiä pituuden vuoksi. Lyhennetystä versiosta tuli sitten malli, jota kaikki käyttivät uudelleen.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Jos toinen komento tulostaa sallivan käytännön ja ensimmäinen tulostaa DROP, olet löytänyt vastauksen koskematta asiakkaaseen. Tämä epäsymmetria on vika.

Miksi yksi haku ei ole koko tarina

Yksi nimi voi palauttaa sekä A-tietueen että AAAA-tietueen, eivätkä sovellukset valitse kaikki samalla tavalla. Selain voi suosia IPv6:ta, kun verkko tarjoaa sitä, ja palata takaisin epäonnistuessa, kun taas taustasynkronointi tai päivittäjä käyttää omaa ratkaisijaansa ja omaa mieltymystään. Siksi yksi onnistunut testi IPv4:n yli todistaa yhden reitin, ei käytäntöä.

Verkkosiirtymät muuttavat vastausta myös. Liittyminen toiseen Wi-Fi-verkkoon, lepotilasta herääminen tai mobiiliverkkoon siirtyminen voi antaa laitteelle uuden IPv6-etuliitteen, eikä toimistoverkon LANissa riittävältä näyttänyt käytäntö ehkä kata sitä.

Testaa tila, jossa tunneli on alhaalla

Yhdistettynä testaaminen kertoo, että tunneli toimii. Kiinnostava testi on tilanne, jossa verkkoon ei pääse, koska silloin turvakytkimen pitäisi pitää. Pysäytä tunneli tahallaan ja kokeile sitten tärkeitä kohteita sovelluksesta, jota suojaat.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Molempien perheiden pitäisi epäonnistua suljetusti. Jos IPv4-pyyntö aikakatkaistaan ja IPv6-pyyntö palauttaa tilakoodin, käytäntö on puutteellinen, eikä tunnelin uudelleentestaaminen muuta sitä.

Säilytä myös dokumentoidut poikkeukset tässä testissä. Lähiverkon löytäminen, DHCP-uudistus tai käynnistyspolku VPN-päätepisteeseen voi vaatia saavutettavissa pysymistä, ja nuo poikkeukset pitäisi nimetä käytännössä sen sijaan, että ne löydetään katkoksen aikana. Vuototesti, joka epäonnistuu siksi, että tunneli ei saa yhteyttä takaisin, ei ole tietoturvalöydös, vaan yhteyksien löydös.