IPv6 forskeytisframsal yfir síðu-til-síðu VPN: gátlisti

Að koma göngunum upp er auðveldari helmingurinn. Ég hef séð síðu-til-síðu tengingu standa í marga daga á meðan hver hýsill á fjarlæga LAN-inu fékk þögn til baka, vegna þess að framselda forskeytið bak við þá gátt var stillt á tengi en aldrei beint inn í göngin. Göngufangarnir svöruðu pingum allan tímann, og einmitt þess vegna skoðaði enginn forskeytið. Hér er röðin sem ég athuga þegar framselt IPv6 forskeyti þarf að fara yfir síðu VPN: forskeytakortið, umferðarvalana, framsendingu og eldvegg, og svo afturleiðina.

Skrifaðu forskeytakortið áður en þú snertir göngin

Framsending forskeyta gefur blokkina til þeirrar leiðar sem bað um hana. Hún setur ekki upp leið á jafningjann, teygir ekki blokkina on-link, og segir fjarlægu gáttinni ekki hvað er bak við beiðnileiðina. Þessu þrennu þarftu að stilla, og það á heima í vistfangasetli áður en nokkur stillingarskrá breytist.

Fyrir hverja síðu skaltu skrá framselda forskeytið, /64-ið sem raunverulega er í notkun á LAN-inu, göngufangana og eiganda hverrar leiðar. Þjónustuveitan frameslur 2001:db8:a1::/56 til síðu A, sem þjónar 2001:db8:a1:10::/64 á LAN-inu sínu; síða B heldur 2001:db8:b2::/64. Ef síða A þjónar aðeins þessu eina /64 eiga báðir endar að nefna 2001:db8:a1:10::/64 frekar en alla /56-una.

Tvö mistök koma næstum alltaf upp. Annað er að meðhöndla fjarlæga forskeytið sem on-link, brúa það eða setja það á gangatengið þannig að gáttin svarar nágrannafyrirspurnum fyrir hýsla sem hún nær ekki til. Hitt er að auglýsa alla /56-una þegar aðeins eitt /64 er stillt: leiðatöflunni finnst blokkin aðgengileg og mest af fangöngunum falla í svarthol.

Láttu umferðarval báðra enda passa við leiðirnar

Bæði IKEv2 og WireGuard hafna ósamrýmanlegri umferð, nógu hljóðlega til að göngin líta enn heil út.

Í strongSwan eru valarnir skýrt tilgreindir. Á síðu A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

conn-færsla síðu B speglar netin tvö. Þegar þau eru ósammála hafnar svarandinn CHILD_SA með TS_UNACCEPTABLE, svo barn-SA kemst aldrei upp þótt IKE_SA hafi gert það. Á báðum hliðum verður stillta netið að jafngilda því sem staðbundni kjarninn beinir inn í göngin.

WireGuard ber sömu upplýsingar í AllowedIPs, með einum feng: AllowedIPs er upprunasía við móttöku jafnt sem leið við sendingu. Ef jafningjafærsla síðu B fyrir síðu A sleppir 2001:db8:a1:10::/64 koma pakkar frá síðu A inn á gildri handabandi og eru felldir sem óheimilaðir. Það gefur kunnuglegt mynstur handabands sem endurnýjast á meðan ekkert svar fer út. Berðu saman báða enda með wg show wg0 allowed-ips. Athugaðu listann aftur í hvert sinn sem framsalið breytist; úrelt /64 heldur lotunni uppi og nýja forskeytið óaðgengilegt.

Útilokaðu framsendingu, eldvegg og MTU fyrst

Áður en þú lest aðra línu í annálnum skaltu staðfesta að gáttirnar framsenda yfirhöfuð. sysctl net.ipv6.conf.all.forwarding verður að skila 1 á báðum, einnig beitt á göngu- og LAN-tengin. Ein gildra fylgir: þegar framsending er kveikt hættir tengi með accept_ra=1 að taka við beinum frá þjónustuveitunni, svo vélin getur misst sjálfgefna leið uppstreymis þótt hún beini fullkomlega inni í göngunum. Stilltu accept_ra=2 þar sem enn er þörf á beinum frá þjónustuveitunni.

Eldveggsreglurnar verða síðan að leyfa forskeytið í báðar áttir, og ICMPv6 verður að lifa af: nágrannauppgötvun, packet-too-big og destination-unreachable eru ekki valfrjáls. Fella þau og slóðar-MTU-uppgötvun brotnar, sem gefur tengingar sem opnast og stöðvast svo á fyrsta stóra svari. Lágmarksreglupar lítur svona út:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU-ið liggur bak við þetta. Göngin minnka nothæfa MTU-ið niður fyrir 1500, og IPv6 krefst þess að hver tenging beri að minnsta kosti 1280. Lítil ping komast í gegn, SSH-lota frýs á stórum höggum, og /proc/net/snmp6 sýnir packet-too-big skilaboð sem koma aldrei til baka. Stilltu MTU ganganna skýrt, eða þrengdu TCP MSS í mangle-töflunni, og leyfðu ICMPv6 sem tilkynnir minna MTU að koma til baka.

Prófaðu afturleiðina, ekki gangafangið

Bilunin sem kostar mestan tíma er einstefnubeining. Hver gátt beinir fjarlæga forskeytinu inn í göngin, en hýslarnir svara í gegnum sína eigin sjálfgefnu gátt því þar er /64-ið þeirra. Að koma pakka til áfangastaðar er hálf leið.

Tvær skipanir leysa mest af þessu. Á síðu A sýnir ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 hvaða tengi svar frá þeim uppruna myndi nota; keyrðu spegluðu athugunina á síðu B. Búðu svo til umferð frá hýsli frekar en gáttinni og berðu saman teljara á báðum endum.

Ef nágrannafyrirspurn fyrir fjarlæga forskeytið birtist á göngunum er það forskeyti on-link einhvers staðar þar sem það ætti ekki að vera; lagaðu það áður en þú stillir leiðirnar. Proxy NDP nær yfir tilvik þar sem brúun er sannarlega nauðsynleg, ekki staðgengill fyrir leið.

Skipuleggðu að forskeytið breytist undir þér

Framsending forskeyta er leigusamningur milli frameslandi og beiðnileiðarinnar, og endurnýjun getur skilað annarri blokk: öðru /56 eftir flutning þjónustuveitunnar, eða styttri leigu en göngin hafa verið uppi. Hver staður sem nefnir gamla forskeytið verður úreltur í einu: leiðir, valar, AllowedIPs, eldveggsreglur, DNS-færslur og hvers kyns vöktun sem harðkóðar bókstaflega fanga. Skilaboðaflæðið er í RFC 8415.

Þar sem búist er við að forskeytið hreyfist skal halda innra vistfangasetli sem er ekki háð því og þýða á landamærunum. NPTv6 er stöðulaust valið og heldur innri stefnu læsilegri, en það er forskeytaþýðing, ekki töfralag: /64-mörk verða að passa, gátsummur eru aðlagaðar, og forrit sem innbyggja bókstaflega fanga brotna samt. Ef þú heldur fangöngum þjónustuveitunnar frá enda til enda skaltu skrá hegðun leigunnar og breytingarferli í vistfangasetlinu.

Ljúktu með prófi sem stenst tímann: leyfður hýsill á hvoru LAN-i nær þjónustu á hinu LAN-inu, svarið fer til baka í gegnum göngin, og sama parið virkar enn eftir endurræsingu ganganna og endurnýjun framsalsins. Ef síðasti hlutinn bregst er hönnunin háð ástandi sem lifir ekki vikuna.