Neyðarrofi lokar aðeins IPv4: hvers vegna IPv6 sleppur samt út

Göngin falla, neyðarrofinn tilkynnir að hann hafi gripið inn í, og niðurhal heldur áfram. Ekkert er brotið í IPv4-reglunum. Forritið færði sig einfaldlega á leið sem þessar reglur voru aldrei skrifaðar fyrir.

Tvíhleðslutæki hafa tvær óháðar útleiðir. Lokun á annarri þeirra er hálf lokun.

Tvö regnasöfn, tvö sjálfgefin

Á Linux eru iptables og ip6tables aðskildar töflur með aðskildum stefnum. Að setja INPUT- og OUTPUT-keðjur IPv4-töflunnar á DROP breytir engu í IPv6-töflunni, þar sem sjálfgefið er venjulega ACCEPT. Sama skiptingin er til í nftables, þar sem hægt er að skoða eina fjölskyldu og komast að því að aðeins ein þeirra ber reglurnar þínar. Þessi ósamhverfa er eðlileg, og það er allt vandamálið.

Þess vegna getur neyðarrofi virst ítarlegur og hegðað sér að hluta. Skriftan sem skrifaði IPv4-reglurnar rann, teljararnir hækka, logglinan birtist, og IPv6-pakki fer út um eðlisfræðilega viðmótið algjörlega ósnortinn.

Lestu hvað biðlarinn þinn setur í raun upp, ekki hvað markaðssíðan lofar. Sumir biðlarar beina IPv6 í göngin, sumir loka á það viljandi, og sumir láta það afskiptalaust á meðan læsing á vettvangsstigi framfylgir annarri reglu. Skjöl seljandans eru eina upplýsingaveitan sem er þess virði að treysta hér.

Hvað viðmótsstillingin segir þér

Handbókarsíða wg-quick inniheldur IPv6-reglur í dæmastillingu sinni, og ástæðan er einmitt þetta bil. Dæmið er ekki skraut. Það er til vegna þess að IPv4-reglurnar einar myndu skilja aðra fjölskylduna eftir opna.

Að afrita helming dæmisins gefur helming stefnunnar. Þetta er algengasti uppruni þessa leka. Bloggfærsla stytti dæmið vegna lengdar. Stytta útgáfan varð síðan sniðmátið sem allir endurnýttu.

# 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

Ef önnur skipunin prentar leyfandi stefnu á meðan fyrsta prentar DROP, hefur þú fundið svarið án þess að snerta biðlarann. Þessi ósamhverfa er villan.

Hvers vegna ein uppfletting er ekki öll sagan

Eitt nafn getur skilað bæði A-færslu og AAAA-færslu, og forrit velja ekki öll á sama hátt. Vafri kann að kjósa IPv6 þegar netið býður það og falla til baka við bilun, á meðan bakgrunnssamstilling eða uppfærsluforrit notar sinn eigin leysi og sína eigin forgang. Þess vegna sannar ein vel heppnuð prófun yfir IPv4 eina leið, ekki stefnuna.

Netbreytingar breyta svarinu líka. Að tengjast öðru Wi-Fi-neti, vakna úr svefni eða skipta yfir í farsímanet getur gefið tækinu nýtt IPv6-forskeyti, og stefnan sem leit út fyrir að duga á skrifstofu-LANinu nær kannski ekki yfir það.

Prófaðu ástandið þegar göngin eru niðri

Að prófa á meðan þú ert tengdur segir þér að göngin virki. Áhugaverða prófið er óaðgengilega ástandið, því þá á neyðarrofinn að halda. Stöðvaðu göngin viljandi, reyndu svo áfangastaðina sem skipta máli úr forritinu sem þú verndar.

# 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/

Báðar fjölskyldur ættu að bregðast lokuðum. Ef IPv4-beiðnin rennur út á tíma og IPv6-beiðnin skilar stöðukóða, er stefnan ófullkomin, og engin endurprófun ganganna mun breyta því.

Haltu einnig skjalfestu undantekningunum í þeirri prófun. Uppgötvun staðarnets, DHCP-endurnýjun eða ræsingarleiðin að VPN-endapunkti getur þurft að vera áfram aðgengileg, og þær undantekningar ættu að vera nefndar í stefnunni frekar en að uppgötvast meðan á truflun stendur. Lekaprófun sem bregst vegna þess að göngin komast ekki upp aftur er ekki öryggisfundur, heldur tengingarfundur.