Kuelekeza IPv6 kati ya maeneo mawili kupitia VPN iliyopo

Unapoongeza kiambishi cha IPv6 kwenye handaki la eneo-kwa-eneo, pakiti haisafiri kama mchoro unavyodokeza. Lango la ndani huchukua pakiti nzima ya IPv6, huifanya siri, na kuweka mbele kichwa cha IP cha nje ambacho familia ya anwani yake huamuliwa na anwani za ncha, si na kilicho ndani. Lango la mbali huondoa kichwa hicho cha nje na kusambaza pakiti asili kwenye LAN yake, ambapo ni pakiti ya kawaida ya IPv6 tena. Handaki la nje na trafiki ya ndani ni mazungumzo mawili tofauti yanayoshiriki ufunguo, jozi ya ncha, na hakuna kingine.

Vichwa viwili, familia mbili za anwani

Katika hali ya handaki ya IPsec, pakiti ya ndani ya IPv6 inakuwa mzigo nyuma ya kichwa cha ESP. Kichwa cha nje kinachobeba pakiti hiyo ya ESP kinaweza kuwa IPv4 au IPv6, na hufuata local_addrs na remote_addrs. WireGuard hufanya vivyo hivyo kwa sherehe chache: pakiti ya ndani ni mzigo wa datagramu ya UDP kwenda ncha ya mwenzake. Zote mbili huacha kichwa cha ndani bila kuguswa, ndiyo sababu upande wa mbali unaweza kuielekeza baada ya kufungua.

Njia kati ya maeneo inaona tu UDP 4500 wakati IPsec inatumia NAT traversal, au UDP 51820 kwa msikilizaji wa kawaida wa WireGuard. Kila kipanga njia njiani kinaweza kuwa IPv4 pekee na trafiki ya IPv6 inavuka hata hivyo, kwa sababu haionekani kamwe kama pakiti ya IPv6 kwenye njia hiyo. Hiyo inatoa mgawanyiko wa kwanza safi: tcpdump -ni eth0 udp port 51820 huonyesha njia iliyofanywa siri, tcpdump -ni wg0 ip6 huonyesha trafiki ya ndani. Nakala ya nje yenye shughuli nyingi na ya ndani isiyo na kitu inamaanisha kerneli haiweki IPv6 kwenye handaki; hiyo ni uelekezaji au sera, si hali ya kiungo.

Lango pia hupunguza Hop Limit ya ndani linaposambaza, kwa hivyo ncha zinahesabiwa kama vipanga njia kwenye njia ya IPv6. Idadi ya hops ya nje na Hop Limit ya ndani husogea kwa kujitegemea, na pakiti inayokufa kwenye lango la mbali ilikufa katika upelekaji, si katika usimbaji fiche.

Vichaguzi na AllowedIPs ni orodha ya ruhusa

IKEv2 hujadili ni viambishi vipi vya ndani ambavyo child SA inaweza kubeba. Kwenye strongSwan 5.9 na zaidi, kuviandika katika swanctl.conf kunaonekana hivi:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

Ondoa local_ts na remote_ts na strongSwan huzipata kutoka kwa subneti za kiolesura inachochagua. Kwenye mwenyeji wa dual-stack, njia hiyo ya mkato mara nyingi hutoa jozi ya IPv4 pekee: SA inapanda na IPv6 inakataliwa kabla ya kufika kwenye msimbo wa ESP. Kuandika viambishi vyote viwili hufanya SA iweze kubeba, na start_action = trap huiinua kwenye pakiti ya kwanza inayolingana.

WireGuard ina orodha moja inayofanya kazi mbili. Katika bloku ya mwenzake, AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 ni njia inayowekwa wakati wa kutuma na pia chujio kinachotumika wakati wa kupokea: pakiti iliyofunguliwa ambayo chanzo chake cha ndani kiko nje ya orodha ya mwenzake huyo hutupwa kimya kimya. wg-quick huongeza njia kwa kila kiingilio, kwa hivyo bloku ya mwenzake hapa chini haihitaji amri ya ip -6 route tofauti.

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

Orodha zote mbili lazima zilingane: eneo B linakubali kiambishi cha eneo A kama kichaguzi cha mbali na kukielekeza kurudi, na handaki hufanya kazi tu pale mielekeo miwili inapokubaliana. Orodha isiyo sawa hutoa dalili inayopoteza muda mwingi — handshake nzuri, vihesabu vinavyosogea upande mmoja, na ping kutoka A hadi B inayofanikiwa wakati hakuna kutoka B kinachofika A.

Upelekaji, njia na kiambishi cha kurudi

Linux haisambazi IPv6 hadi useme, na mpangilio ni kwa namespace si kwa kiolesura:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

Mstari wa pili ndio ambao watu husahau katika miundo inayotegemea njia. IPsec inayotegemea sera huweka sera ya XFRM inayolingana na viambishi, lakini mpangilio unaotegemea njia wenye vti6 au WireGuard unahitaji njia halisi ya IPv6 inayoelekeza kwenye kifaa hicho. Dumisha sysctl chini ya /etc/sysctl.d/; vinginevyo kuwasha upya kunarudisha upelekaji kwa kuzimwa kimya kimya.

Upelekaji una athari ya pembeni inayofaa kujulikana: kerneli hupuuza matangazo ya kipanga njia isipokuwa net.ipv6.conf.<wan>.accept_ra ni 2, kwa hivyo lango ambalo anwani yake ya WAN huja kwa SLAAC linaweza kupoteza njia yake ya kawaida mara tu unapowasha upelekaji. Weka accept_ra = 2 kwenye kiolesura hicho katika faili hiyo hiyo na njia itaendelea kuishi. Msingi wa eneo B pia lazima ujifunze 2001:db8:aa::/48 kutoka kwa lango la handaki, kwa njia tuli au itifaki ya uelekezaji juu ya handaki, vinginevyo jibu linakufa ndani ya mtandao wa B yenyewe.

Ukaguzi wa hatua nne unaobainisha mahali palipovunjika

Fanya kazi kwa mpangilio huu na usimame kwenye hatua ya kwanza inayoshindikana, kwa sababu kila hatua inayofuata inategemea zilizopita.

1. Vichaguzi: swanctl --list-sas inapaswa kuonyesha jozi ya viambishi vya IPv6 kwenye child SA, au wg show wg0 allowed-ips kiambishi cha mbali na latest-handshakes ya hivi karibuni.
2. Njia ya kerneli: ip -6 route get 2001:db8:bb::10 lazima ijibu kwa kifaa cha handaki, si kiolesura cha WAN.
3. Nakala ya ndani: tcpdump -ni wg0 ip6 wakati ukifanya ping kati ya wenyeji halisi wa LAN. Pakiti zinazotoka lakini hakuna zinazorudi zinaelekeza kwenye njia au firewall ya B; hakuna pakiti kabisa inaelekeza nyuma kwenye hatua 1 au 2.
4. Marudio: kwenye mwenyeji B, ss -6 -ltn inathibitisha kuwa huduma inasikiliza kwenye IPv6, na vihesabu vya firewall vya ndani vinaonyesha kama pakiti ilikubaliwa au kutupwa.

MTU iko katika kipindi hicho hicho. Vipanga njia vya IPv6 havigawanyi, kwa hivyo pakiti kubwa kupita kiasi hutupwa na Packet Too Big inarudi kwa mtumaji. Ikiwa handshake na ping ndogo zinafanya kazi lakini uhamishaji wa faili unakwama, punguza mzigo hadi upite: ping -6 -s 1400 -c 3 2001:db8:bb::10. Violesura vya WireGuard vina MTU ya kawaida ya baiti 1420 na IPsec juu ya IPv4 inaondoa zaidi, kwa hivyo kuweka MTU ya ndani ni bora kuliko kutumaini ugunduzi wa MTU wa njia kupitia firewall inayotupa ICMPv6.

Hali za kushindikana zinazoonekana kama matatizo ya firewall

Inayojulikana zaidi si firewall hata kidogo: huduma inaunganisha kwa 0.0.0.0 badala ya ::, rekodi ya AAAA ipo, na mteja anapokea kukataliwa haraka kwa IPv6 ambayo kivinjari cha dual-stack huficha kwa kurudi kwenye IPv4. Ikiwa ni baadhi ya programu tu zinazoshindikana, angalia familia inayosikiliza kabla ya kugusa seti ya kanuni.

Ya pili ni uchujaji wa ICMPv6. Neighbor Discovery na Packet Too Big ni sehemu ya uendeshaji wa kawaida, si uchunguzi, na sera inayotupa ICMPv6 yote huzalisha handaki inayounganisha, inathibitisha, kisha inakwama kwenye kitu chochote kikubwa kuliko pakiti ndogo. Ruhusu aina ambazo njia inategemea na uache vihesabu vikiwa kimewashwa ili kutupwa kuonekane.

Ya tatu ni kiambishi kilichoongezwa kwenye handaki lakini kamwe hakijaongezwa kwenye mpango wa anwani wa eneo linalomiliki, kwa hivyo hakuna kipanga njia kinachokitangaza na hakuna mwenyeji anayeweza kujibu kutoka kwacho. Anza na kiambishi kimoja na jozi moja ya wenyeji, thibitisha mielekeo yote miwili kwa hatua nne, kisha ongeza mengine; kiambishi kilichovunjika kinabaki mstari mmoja katika usanidi badala ya muundo mpya. Rejeleo pekee rasmi linalofaa kuwekwa wazi ni RFC 8200, linalofafanua kichwa ambacho handaki hubeba.