Á IPv6-umferð að fara í gegnum VPN eða beint?

Tveir einstaklingar báðu mig í síðasta mánuði um andstæðar niðurstöður: annar vildi að IPv6 væri þakið af VPN-inu, hinn vildi að skrifstofuprentarinn héldi áfram að virka. Ein leið ::/0 getur ekki veitt bæði eitt sér. Hvort sú leið tilheyrir inni í göngunni fer eftir þremur skilyrðum, og það fyrsta útilokar hana fyrir flestar auglýsingarútgöngur. Ef útgangan ber ekki IPv6, felur beining sjálfgefnu leiðarinnar þangað umferðina þína í göngu sem hefur hvergi til að senda hana.

Þrjú skilyrði ráða svarinu

Sjálfgefna leiðin er ein lína, ::/0, og hún passar við hvert IPv6-áfangastað án sérhæfðari leiðar (RFC 4291). Auðvelt er að setja hana upp. Ákvörðunin um hvort þú ættir að gera það kemur niður á þrjú skilyrði.

Skilyrði eitt: útgangan sem þú tengist hefur virkt IPv6 og er reiðubúin að senda það áfram. Skilyrði tvö: biðlarinn þinn getur haldið leið að endapunkti göngunnar, sem liggur venjulega innan sviðsins sem þú ert að fara að beina. Skilyrði þrjú: þú getur nefnt staðbundnu IPv6-áfangastaðina sem verða að vera utan göngunnar.

Hvert skilyrði bregst á sinn hátt, og þess vegna kostar gisk heila kvöldstund. Brugðið skilyrði eitt gefur þér þögn og leiðatöflu sem lítur rétt út. Brugðið skilyrði tvö drepur handabandið nokkrum sekúndum eftir að það byrjar. Brugðið skilyrði þrjú skilur eftir virka göngu og óánægðan kollega við prentarann.

Ber útgangan í raun IPv6?

Gönguviðmót með IPv6-vistfangi sannar ekkert um hina hliðina. Mörg auglýsingasnið eru að innan aðeins IPv4: þjónninn gefur þér v4-vistfang og sleppir öllu öðru. Setjið sjálfgefna leið úr AllowedIPs ofan á það og kjarninn sendir fúslega IPv6 inn í viðmót sem mótaðilinn sér aldrei.

Prófaðu frá biðlinum meðan gangan er uppi. ping -6 -c 3 2001:4860:4860::8888 og ip -6 route get 2001:4860:4860::8888 svara mismunandi spurningum: hvort svar kemur til baka, og hvaða tæki kjarninn valdi. Þegar hið síðara nefnir gönguna þína og hið fyrra skilar engu, er vandamálið í útgöngunni, ekki leiðinni.

Ef þú rekur útgönguna sjálfur getur próf biðlarans staðist og leiðin samt endað í blindgötu. Staðfestu net.ipv6.conf.all.forwarding=1 á gáttinni og að eldveggur hennar samþykki pakka sem eru sendir út úr göngunni. Rétt beind pakki inn í útgöngu sem neitar að endursenda lítur nákvæmlega út eins og beiningarvilla frá hlið biðlarans.

Getur biðlarinn haldið leið sinni að endapunktinum?

Þetta er tilfellið sem greip mig á fartölvu með WireGuard-endapunkt sem var aðeins IPv6. Vistfang endapunktsins er venjulegt alþjóðlegt vistfang, svo það fellur innan ::/0. Beindu öllu forskeytinu inn í viðmótið og handabandspakkarnir elta sjálfa sig inn í gönguna sem þeir eru enn að reyna að byggja. Gangan kemur aldrei upp, og ekkert í úttaki biðlarans segir hvers vegna.

wg-quick sér um þetta á Linux. Það leiðir leiðir úr AllowedIPs, setur þær í eigin töflu og bætir við stefnureglu svo umferð að endapunktinum sé fyrst leyst gegnum aðaltöfluna: reglan suppress_prefixlength 0 sem þú finnur í ip -6 rule. Þess vegna tekst wg-quick up þar sem handskrifuð ip -6 route add default dev wg0 sker þig af.

Athugaðu bæði stöðin með ip -6 route get <endpoint-v6>, fyrir og eftir að gangan er reist. Ef svarið breytist yfir í göngutækið þitt hefur þú fjarlægt leiðina sem gangan þarf. Þegar þú skrifar leiðirnar sjálfur, bættu við hýsilleið að endapunktinum í gegnum upprunalegu gáttina, eða tengstu endapunktinum um IPv4 og láttu IPv6 eftir farminum.

Hvað verður að vera utan göngunnar?

Sérhæfðari leiðir vinna á sjálfgefnu leiðinni, svo forskeyti á tenglinum eða ULA-svið með eigin leið heldur áfram að virka án aukalegrar fyrirhafnar. Þetta er hljóðláta ástæðan fyrir því að svo margar IPv4-uppsetningar með fullri göngu lifa af: LAN-forskeytin eru sérhæfðari en sjálfgefna leiðin og fara aldrei inn í gönguna.

Það brotnar þegar staðbundið tæki er aðgengilegt um alþjóðlegt vistfang, sem er eðlilegt fyrir prentara sem sami beinirinn gaf opinbert forskeyti, NAS eða sjónvarp. Þessi vistföng passa við ::/0 og ekkert annað, svo þau flytjast inn í gönguna með öllu öðru og hverfa.

Ákveddu eftir áfangastað, ekki eftir samskiptareglu. Ef tveir eða þrír staðbundnir hýslar skipta máli, gefðu forskeytum þeirra leið út um líkamlega viðmótið, eða fjarlægðu þau úr samninguðu menginu. Ef listinn heldur áfram að stækka er heiðarlegt svar split tunneling fyrir IPv6 með skrifuðum undantekningarlista, ekki sjálfgefin leið sem þú ert sífellt að plástra.

Ef svarið er nei, lokaðu því

Að láta IPv6 vera án leiðar er ekki það sama og að láta það í friði. Hýsill með virka IPv6-sjálfgefna leið heldur áfram að nota hana meðan gangan ber IPv4, svo umferðin fer út hjá VPN-inu og hver þjónusta sem kýs IPv6 sér þitt raunverulega vistfang. Þetta er leki, ekki skipt gangan.

Veldu aðra og skrifaðu niður hverja þú valdir. Beindu sjálfgefnu leiðinni og samþykktu málamiðlanirnar hér að ofan, eða slökktu á IPv6 meðan gangan varir. Að sleppa forskeytinu úr AllowedIPs er ekki nóg eitt sér, því stýrikerfið heldur eigin sjálfgefinni leið. Á Linux er grófa útgáfan sysctl -w net.ipv6.conf.all.disable_ipv6=1; fínna útgáfan sleppir IPv6 utan göngunnar með eldveggsreglu. Símabiðlarar koma með skýran IPv6-blokkunarrofa sem gerir sama gagn.

Sannprófaðu það eins og leka

Reistu gönguna og lestu stöðuna í stað þess að treysta rofanum. ip -6 route show default ætti að sýna eina sjálfgefna leið, og ip -6 route get fyrir áfangastað utan LANsins ætti að nefna göngutækið. Endurtaktu bæði eftir aftenging: sjálfgefin leið sem lifir gönguna er villan sem þú varst að leita að.

Prófaðu svo hina áttina. Frá hýsli á staðbundna netinu, náðu í biðlarann á staðbundnu IPv6-vistfangi hans. Ef það hættir að virka var skilyrði þrjú aldrei uppfyllt, hvað sem leiðataflan fullyrti þá.

Skrifaðu niðurstöðuna þar sem næsta manneskja finnur hana: hvaða forskeyti vera staðbundin, hvers vegna og hvað biðlarinn gerir eftir aftengingu. Tvær línur í runbook spara næsta verkfræðingi að enduruppgötva endapunktslykkjuna um miðnætti.