Að kljúfa /64-ið þitt beinir ekki IPv6 að VPN-viðskiptavinum

Viðskiptavinurinn sýnir alheims IPv6-tölu, handabandið er lokið og ekkert kemur til baka frá internetinu. Stilling hópsins lítur rétt út því hún er rétt; talan er gild og rásin ber hana. Það sem bregst er afhendingin, og afhendingin fer eftir ákvörðun sem tekin er ofan við VPN-þjóninn og engin stilling á viðskiptavinahlið getur haft áhrif á.

Goðsögnin: hluti af /64-inu þínu er þegar aðgengilegur

Sagan er aðlaðandi: þjónninn hefur opinbert /64, kljúfðu það í tvennt, gefðu hinn helminginn að VPN-hópnum og þessir viðskiptavinir eru núna á internetinu. Að kljúfa forskeytið úthlutar vissulega tölum án árekstra. En það breytir ekki hvernig upstream-netið ákveður hvert pakki fyrir eina af þessum tölum á að fara.

IPv6 hefur enga sjálfgefna þýðingarlag sem hægt er að styðjast við, svo afturleiðin verður að vera til sem beining eða sem afhending á tengslastigi. Pakki sem er stílaður á rásartölu viðskiptavinar kemst að upstream-beininum og sá beinir tekur framsendingarákvörðun úr eigin töflu. Ef taflan bendir á líkamlega tengingu fer pakkinn þangað óháð því hvað VPN-þjónninn þinn telur.

Þetta er öll bilunin: áframleiðin virkar því þjónninn þinn sendir hana, og afturleiðin deyr eina hopp í burtu því upstream fékk aldrei að vita að viðskiptavinurinn væri til.

Hvað afhending á tengingu krefst í raun

Þegar upstream telur allt /64-ið vera á líkamlegu tengingunni, leysir það hvert áfangatölu fyrir sig með uppgötvun nágranna. Það sendir beiðni á þá tengingu og væntir þess að eigandi tölunnar svari. VPN-viðskiptavinur bak við rás er ekki á þeirri tengingu og getur ekki svarað, svo beiðnin er ósvarað og pakkanum er hent.

Að skera út /65 breytir þeirri væntingu ekki. Upstream meðhöndlar sviðið enn sem á tengingunni, því eina sem myndi snúa því eru beining eða proxy sem svarar fyrir hönd viðskiptavinarins. Hvorki kemur fram því þú breyttir VPN-stillingu. Einmitt þetta bil útskýrir hvers vegna hópur getur virkað fullkomlega milli eigin viðskiptavina og verið samt óaðgengilegur hvaðan sem er annars staðar frá.

Uppgötvun nágranna í gegnum proxy er aðferðin sem getur brúað bilið milli heimsins tveggja. Gáttin svarar beiðnum fyrir tilteknar viðskiptavinatölur sem hún á og sendir umferðina inn í rásina. Það virkar, og það verður að takmarka nákvæmlega við þessar tölur með lífsferli sem fylgir hópnum, því að svara fyrir tölu sem þú þjónar ekki lengur gerir umferð annars að svartholi. Sumir upstream samþykkja ekki proxy-svör sem þeir væntu ekki, svo þessi hönnun þarf líka samþykki þjónustuaðilans.

Hvað beind afhending krefst

Hreinna hönnunin er úthlutun sem upstream beinir í raun að gáttinni þinni. Það getur verið framselt forskeyti eða stök beining fyrir minni blokk, og krafan er sú sama í báðum tilvikum: tafla upstream verður að benda á þjóninn þinn fyrir viðskiptavinasviðið. Þá kemst afturumferð að gáttinni og gáttin sendir hana inn í rásina.

Beind afhending fjarlægir spurninguna um uppgötvun nágranna algjörlega, og þess vegna er þess virði að biðja þjónustuaðilann um hana áður en eitthvað snjallt er byggt. Biddu um beininguna skriflega og staðfestu að næsta hopp sé talan sem upstream getur raunverulega náð.

Báðar hönnunin þurfa enn virka framsendingu IPv6 á gáttinni og eldveggjarreglur sem leyfa framsendu flæði í báðar áttir. Afhending er forsenda, ekki staðgengill, fyrir restina af leiðinni. Virk beining með framsendingu óvirka gefur nákvæmlega sama þögn og beining sem vantar, svo athugaðu bæði áður en þú hannar eitthvað upp á nýtt.

Tvær óháðar beiningar sem þarf að ná rétt

Forskeyti hópsins og sjálfgefna beining viðskiptavinarins eru aðskildar stillingar, og að rugla þeim skapar að hluta tengingu sem lítur út eins og brotin rás. Hópurinn segir þjóninum hvaða tölum á að úthluta. Beiningar viðskiptavinarins ákveða hvaða áfangastaði hann sendir umferð inn í rásina yfirhöfuð.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Forskeytið hér að ofan er skjölunarrými og tilvísunin á aðeins við IPv6, sem er einmitt það sem tvíþætt uppsetning vill oft meðan afhending IPv6 er enn verið að laga. IPv4-tilvísun skapar ekki IPv6-þekju og hvorug stillingin gefur til kynna hina.

Haltu stjórnumferðinni sem IPv6 ræðst á gangandi undir hvaða stefnu sem þú beitir. Packet Too Big-skilaboð eru klassískt fórnarlamb eldveggs sem leyfir aðeins TCP og UDP, og að henda þeim skapar tengingar sem koma upp og stöðvast svo á stærri flutningum.

Tilkynningar beinisins eru þriðji hreyfanlegi hlutinn. Ef gáttin byrjar að tilkynna á upptengingunni getur það breytt því sem viðskiptavinir og nágrannar halda um forskeyti á tengingunni, sem getur hljóðlega gert hönnunina sem þú varst að skjalfesta að engu.

Skráðu hönnunina svo endurbygging endurtaki hana

Skrifaðu þrjá hluti sér: úthlutun viðskiptavinarins, áfangastaðabeiningu viðskiptavinarins og afhendingaraðferð upstream fyrir úthlutunina. Lesandi sem hefur alla þrjá getur endurbyggt uppsetninguna; lesandi sem hefur aðeins stillingu hópsins endurtekur upprunalegu villuna.

Prófaðu svo afturleiðina með skýrum hætti, með pakka sem verður að koma til baka utan frá. openvpn(8)-handbókin nær yfir valkostina server-ipv6 og redirect, og beiningarstaðfesting þjónustuaðilans þíns nær yfir helminginn sem handbókin getur ekki.