IPv6 link-local virkar ekki yfir VPN: hvers vegna fe80 stöðvast á hlekknum

Þú ræsir göngin, pingar fe80::1 með göngunum sem upprunaviðmót og fær ekkert til baka. Þetta er ekki eldveggjarregla sem þú gleymdir. Link-local vistfang hefur aðeins merkingu á þeim eina hlekk þar sem það myndaðist, og beint VPN er ekki sá hlekkur. fe80::1 fjarlæga leiðarans býr á fjarlæga LAN segmentinu; þú situr einu hoppi frá á öðru segmenti, og IPv6 hefur enga leið fyrir leiðara til að framsenda link-local pakka yfirhöfuð.

fe80 forskeytið lýsir umfangi, ekki bili

Link-local unicast er fe80::/10, og skilgreinandi eiginleikinn er ekki talan heldur umfangið. Vistfangið gildir aðeins á einum hlekk, og hvert viðmót myndar eitt út frá eigin auðkenni, þess vegna geta tvær ótengdar vélar á tveimur ótengdum netum báðar svarað fe80::1 án minnstu árekstra. Forskeytið segir í raun „á einhverjum hlekk“; hlekkurinn sjálfur kemur úr samhenginu.

Á hýsli er það samhengi svæðið, eða scope ID, sem þú bætir við eftir prósentumerki: fe80::1%eth0 á Linux, fe80::1%3 eða fe80::1%12 á Windows og í verkfærum sem sýna viðmótsnúmer. Kjarninn leysir vistfangið ásamt viðmótsnúmerinu og sendir svo. Slepptu svæðinu og áfangastaðurinn er tvíræður, svo staflinn hefur enga leið til að velja segment.

Hvers vegna beint göng geta ekki skilað því

Beint VPN er punkt-í-punkt viðmót sem ber eigin vistföng, venjulega /64 af unique-local eða einka IPv6 rými inni í göngunum. Fjarlæga LAN er sér hlekkur, sem næst með því að endapunktur gagnanna beinir og framsendir fyrir þína hönd. Þetta eru tvö aðskilin segment, svo vistfang frá öðru er ekki gildur áfangastaður á hinu.

Framsendingarreglan er skýr í staðlinum en ekki skrýtni í biðlarann þinn: leiðarar framsenda ekki pakka með link-local uppruna eða áfangastað. Þess vegna deyr pakkinn jafnvel þótt leiðatöflan líti rétt út. Bættu við leið fyrir fe80::/64 sem bendir á göngin og stafli sem fylgir staðlinum annaðhvort hafnar henni eða tekur hana og sleppir hverjum samsvarandi pakka: umfang áfangastaðarins segir „aðeins þessi hlekkur“, og útgangsviðmótið er ekki sá hlekkur.

Nágrennisleit styrkir sömu mörk. Hýslar leysa link-local næstu hopp með nágrennisbeiðni sem send er á multicast í umfangi hlekksins með hopptakmörk 255, svo leiðarar geta hafnað öllu sem er framsent. Að láta það virka yfir göng myndi þýða að miðla leit fyrir fjarlægt segment, sem er Layer 2 brú í öðrum hatti.

Það er hljóðlátari önnur bilun, og hún grípur fólk sem reynir samt að þvinga leiðina: svæðið. Hvaða svæði sem þú slærð inn staðbundið nefnir viðmót ganganna, en vistfangið sem þú vilt er bundið við viðmót fjarlæga LAN. Þau tvö passa aldrei saman, svo ekki er hægt að stýra pakkanum á rétta viðmótið í hinum endanum.

Hvernig bilunin lítur út í reynd

Verkfæraúttak fyrir umfangsmissi les eins og leiða- eða eldveggjarvilla, og það er einmitt hvers vegna fólk eyðir síðdegi í röngu lagi.

Þriðja röðin eyðir mestum tíma, því ssh biðlari án úttaks lítur út eins og vandamál í þjónustu sem hlustar. Ef þú hefur einhverja leið inn, athugaðu fjarlægu hliðina og staðfestu hvort sshd er bundið við öll vistföng eða aðeins eitt.

Notaðu vistfang sem var ætlað til leiðingar

Fyrir hvað sem þú þarft að ná í gegnum göngin, notaðu vistfangið sem þjónustunni var gefið í þeim tilgangi: altækt unicast vistfang, eða unique-local vistfang úr fc00::/7, bilið sem er frátekið einmitt fyrir þetta innra tilfelli. Staðfestu að hlustandinn bindist því í raun, og staðfestu afturleiðina og hverja eldveggjarreglu hýslsins.

Horfðu á fjarlæga hýslið í stað þess að giska. ip -6 addr show telur upp vistföngin sem eru til, og ss -6 -ltn telur upp hvað dæmoninn hlustar á. Þjónusta sem er aðeins bundin við fe80:: er aðeins aðgengileg frá eigin segmenti, sem er venjulega sjálfgefið gildi sem enginn valdi viljandi og er hægt að breyta með samþykki stjórnandans.

Þegar ekki er hægt að binda þjónustuna aftur, færðu brúna upp á forritalagið í stað netlagsins. Endurvarp á fjarlæga hýslinu sem hlustar á leiðanlegt vistfang og tengist link-local vistfanginu leysir vandamálið án þess að útvíkka nokkurt segment:

socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80

Hér situr svæðið á réttri hlið, á hýslinu sem raunverulega er með eth0 á þeim hlekk. Biðlarinn þinn talar við fd00:1:2::10, sem er leiðanlegt á venjulegan hátt, og endurvarpið gerir link-local hoppið staðbundið. Sama bragð virkar fyrir vefviðmót tækis eða gamalt BMC sem auglýsir aðeins link-local vistfang.

Þegar brúun er raunverulega svarið, og hvað á að athuga

Sumar uppsetningar þurfa sannarlega eitt sameiginlegt segment: tæki sem talar aðeins link-local leit, búnaður sem er háður multicast, rannsóknarstofa sem endurgerir flatt LAN. Þetta er vandamál á Layer 2 og krefst svars á Layer 2, eins og tap tækis sem er brúað á fjarlæga viðmótið eða biðlaraafurð með skýran brúaðan ham. Það kostar þig broadcast og multicast umferð sem fer yfir göngin auk nágrennisleitar sem verður að virka enda á enda.

Ekki nálgast það með því að bæta fe80::/64 við beint prófíl. Það framleiðir versta ástandið: stillingin lítur út fyrir að vera fullbúin, leiðatöflan sýnir færslu, og hver pakki er samt látinn falla einhvers staðar milli tveggja stafla sem báðir hegða sér rétt.

Staðfestu með viðmótinu frekar en pinginu. ip -6 addr show tun0 segir þér hvort hlekkur ganganna myndaði sitt eigið link-local vistfang, og ip -6 route get fe80::1%tun0 segir þér hvað kjarninn myndi í raun gera við áfangastað með umfangi. Þegar kjarninn segir að áfangastaðurinn sé óaðgengilegur á því viðmóti mun engin stilling ganganna breyta því, og þá er kominn tími til að hætta að breyta prófílnum.

Stutt röð sem svarar spurningunni:

• Lestu vistfangið á fjarlæga hýslinu og taktu eftir hvort það er fe80:: eða leiðanlegt forskeyti.
• Ef það er fe80::, biddu þjónustuna aftur, endurvarpaðu á þeim hýsli eða brúaðu segmentið; ef það er leiðanlegt, lagaðu leiðina, eldvegginn eða bindivistfangið.
• Athugaðu svæðið aftur í hvert sinn sem þú prófar aftur, því afritað skipun heldur venjulega röngu viðmóti.

Heimildir: RFC 4291, IPv6 vistfangaarkitektúr.