Ugawaji wa Kiambishi awali cha IPv6 kupitia VPN ya Tovuti-hadi-Tovuti: Orodha ya Ukaguzi

Kuinua handaki ni nusu rahisi. Nimeona kiungo cha tovuti-hadi-tovuti kikibaki kimeanzishwa kwa siku nyingi huku kila mwenyeji kwenye LAN ya mbali akipokea kimya tu, kwa sababu kiambishi awali kilichogawiwa nyuma ya lango hilo kilikuwa kimesanidiwa kwenye kiolesura lakini hakikuwa kimeelekezwa kwenye handaki kamwe. Anwani za handaki zilijibu ping wakati wote, na ndiyo sababu hakuna aliyetazama kiambishi awali. Hapa ni mpangilio ninaoukagua wakati kiambishi awali cha IPv6 kilichogawiwa kinapaswa kuvuka VPN ya tovuti: ramani ya viambishi, vichagua trafiki, upelekaji na ngome, kisha njia ya kurudi.

Andika ramani ya viambishi kabla ya kugusa handaki

Ugawaji wa kiambishi awali humpa kizuizi kipanga njia kilichokiomba. Hauweki njia kwa mwenzake, haupanui kizuizi hicho kama on-link, na hauambi lango la mbali kilicho nyuma ya kipanga njia kinachoomba. Vitu hivi vitatu unapaswa kuvisanidi mwenyewe, na ni sehemu ya mpango wa anwani kabla ya faili yoyote ya usanidi kubadilika.

Kwa kila tovuti, rekodi kiambishi awali kilichogawiwa, /64 inayotumika kwa kweli kwenye LAN, anwani za handaki na mmiliki wa kila njia. Mtoa huduma anagawa 2001:db8:a1::/56 kwa tovuti A, ambayo huhudumia 2001:db8:a1:10::/64 kwenye LAN yake; tovuti B huhifadhi 2001:db8:b2::/64. Iwapo tovuti A inahudumia /64 hiyo moja tu, ncha zote mbili zinapaswa kutaja 2001:db8:a1:10::/64 badala ya /56 yote.

Karibu kila wakati makosa mawili hubuka. Moja ni kuchukulia kiambishi awali cha mbali kama on-link, kukiunganisha au kukiweka kwenye kiolesura cha handaki ili lango lijibu ombi la jirani kwa wenyeji ambalo haliwezi kuwafikia. Lingine ni kutangaza /56 yote wakati /64 moja tu imesanidiwa: jedwali la njia linadai kizuizi kinafikiwa na anwani nyingi huanguka kwenye shimo jeusi.

Oanisha vichagua trafiki vya ncha zote mbili na njia

IKEv2 na WireGuard zote mbili hukataa trafiki isiyolingana, kwa utulivu wa kutosha hivi kwamba handaki bado linaonekana lenye afya.

Katika strongSwan vichagua ni wazi. Kwenye tovuti 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 ya tovuti B huakisi subneti mbili. Zisipopatana, mjibuji hukataa CHILD_SA kwa TS_UNACCEPTABLE, kwa hiyo child SA haipandi kamwe ingawa IKE_SA ilipanda. Kwa pande zote mbili subneti iliyosanidiwa lazima ilingane na kile kernel ya ndani inaelekeza kwenye handaki.

WireGuard hubeba taarifa hiyo hiyo katika AllowedIPs, na hila moja: AllowedIPs ni kichujio cha chanzo unapopokea na njia unapotuma. Iwapo ingizo la peer la tovuti B kwa tovuti A linaacha 2001:db8:a1:10::/64, pakiti kutoka tovuti A hufika kwa handshake halali na hutupwa kama zisizoruhusiwa. Hiyo huzalisha muundo unaojulikana wa handshake inayojirudia kila mara huku hakuna jibu linalotoka kamwe. Linganisha ncha zote mbili kwa wg show wg0 allowed-ips. Kagua orodha hiyo kila mara ugawaji unapobadilika; /64 ya zamani huweka kikao hai na kiambishi awali kipya kisifikike.

Kwanza ondoa upelekaji, ngome na MTU

Kabla ya kusoma mstari mwingine wa kumbukumbu, hakikisha kwamba malango yanapeleka hata kidogo. sysctl net.ipv6.conf.all.forwarding lazima irudishe 1 kwa yote mawili, ikitumika pia kwa violesura vya handaki na LAN. Mtego mmoja unafuatana nao: upelekaji ukiwashwa, kiolesura chenye accept_ra=1 kinaacha kukubali matangazo ya kipanga njia kutoka kwa mtoa huduma, kwa hiyo mashine inaweza kupoteza njia yake chaguo-msingi ya juu ingawa inaelekeza kikamilifu ndani ya handaki. Weka accept_ra=2 mahali ambapo RA ya mtoa huduma bado inahitajika.

Kisha kanuni za ngome lazima ziruhusu kiambishi awali katika pande zote mbili, na ICMPv6 lazima kiendelee kuishi: ugunduzi wa jirani, packet-too-big na destination-unreachable si za hiari. Ukizitupa, ugunduzi wa MTU wa njia huvunjika, na unapata miunganisho inayofunguka kisha kukwama kwenye jibu kubwa la kwanza. Jozi ndogo ya kanuni inaonekana hivi:

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 iko nyuma ya hii. Handaki hupunguza MTU inayoweza kutumika chini ya 1500, na IPv6 inahitaji kila kiungo kibebe angalau 1280. Ping ndogo hupita, kikao cha SSH huganda kwenye mlipuko mkubwa, na /proc/net/snmp6 huonyesha ujumbe wa packet-too-big ambao haurudi kamwe. Weka MTU ya handaki kwa uwazi, au finya TCP MSS kwenye jedwali la mangle, na uache ICMPv6 inayoripoti MTU ndogo irudi.

Jaribu njia ya kurudi, si anwani ya handaki

Hitilafu inayotumia muda mwingi zaidi ni uelekezaji wa upande mmoja. Kila lango huelekeza kiambishi awali cha mbali kwenye handaki, lakini wenyeji hujibu kupitia lango lao chaguo-msingi kwa sababu ndipo /64 yao inapoishi. Kupeleka pakiti hadi lengwa ni nusu ya njia.

Amri mbili hutatua sehemu kubwa. Kwenye tovuti A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 huonyesha kiolesura kipi jibu kutoka chanzo hicho kingetumia; fanya ukaguzi wa kioo kwenye tovuti B. Kisha zalisha trafiki kutoka kwa mwenyeji badala ya lango, na linganisha vihesabu kwenye ncha zote mbili.

Iwapo ombi la jirani kwa kiambishi awali cha mbali linaonekana kwenye handaki, kiambishi awali hicho kiko on-link mahali ambapo hakipaswi kuwa; rekebisha hilo kabla ya kurekebisha njia. Proxy NDP hugharimia hali ambapo uunganishaji wa daraja unahitajika kwa kweli, si mbadala wa njia.

Panga mabadiliko ya kiambishi awali chini yako

Ugawaji wa kiambishi awali ni ukodishaji kati ya kipanga njia kinachogawa na kinachoomba, na upyaishaji unaweza kurudisha kizuizi tofauti: /56 nyingine baada ya uhamishaji wa mtoa huduma, au ukodishaji mfupi kuliko muda ambao handaki limekuwa juu. Kila mahali panapotaja kiambishi awali cha zamani hupitwa na wakati kwa pamoja: njia, vichagua, AllowedIPs, kanuni za ngome, rekodi za DNS na ufuatiliaji wowote unaoweka anwani halisi kwa chuma. Mtiririko wa ujumbe uko katika RFC 8415.

Mahali kiambishi awali kinapotarajiwa kuhama, weka mpango wa anwani wa ndani ambao hautegemei hicho na utafsiri mpakani. NPTv6 ni chaguo lisilo na hali na huweka sera ya ndani ikisomeka, lakini ni tafsiri ya kiambishi awali, si tabaka la kichawi: mipaka ya /64 lazima ilingane, checksum hurekebishwa, na programu zinazopachika anwani halisi bado huvunjika. Iwapo unaweka anwani za mtoa huduma kutoka mwanzo hadi mwisho, rekodi tabia ya ukodishaji na utaratibu wa mabadiliko kwenye mpango wa anwani.

Maliza kwa jaribio linalostahimili muda: mwenyeji anayeruhusiwa kwenye kila LAN anafikia huduma kwenye LAN nyingine, jibu hurudi kupitia handaki, na jozi hiyo hiyo bado inafanya kazi baada ya kuwasha upya handaki na upyaishaji wa ugawaji. Iwapo sehemu ya mwisho ikishindikana, muundo unategemea hali ambayo haitastahimili wiki.