IPv6 երթևեկություն երկու վայրերի միջև գոյություն ունեցող VPN-ով

Միայն IPv4-ով WAN-ը դեռ կարող է կրել ներքին IPv6։ Հետևե՛ք ընտրիչներին, կեռնելի երթուղիներին, փոխանցմանը և վերադարձի նախածանցին, որը լուռ թողնում է պատասխանները։

Երբ վայր-վայր թունելին ավելացնում եք IPv6 նախածանց, փաթեթը չի շարժվում այնպես, ինչպես հուշում է գծապատկերը։ Տեղական դարպասը վերցնում է ամբողջ IPv6 փաթեթը, գաղտնագրում այն և դիմացը դնում արտաքին IP վերնագիր, որի հասցեների ընտանիքը որոշվում է ծայրամասերի հասցեներով, ոչ թե ներքինով։ Հեռավոր դարպասը հեռացնում է այդ արտաքին վերնագիրը և բնօրինակ փաթեթը փոխանցում է իր LAN, որտեղ այն կրկին սովորական IPv6 փաթեթ է։ Արտաքին թունելը և ներքին հոսքը երկու առանձին զրույց են, որոնք կիսում են բանալի, ծայրամասերի զույգ և ուրիշ ոչինչ։

Երկու վերնագիր, հասցեների երկու ընտանիք

IPsec թունելի ռեժիմում ներքին IPv6 փաթեթը դառնում է ESP վերնագրի հետևի բեռնվածությունը։ Այդ ESP փաթեթը կրող արտաքին վերնագիրը կարող է լինել IPv4 կամ IPv6 և հետևում է local_addrs-ին ու remote_addrs-ին։ WireGuard-ը նույնն է անում ավելի քիչ արարողությամբ․ ներքին փաթեթը UDP դատագրամի բեռնվածությունն է դեպի գործընկերոջ ծայրամաս։ Երկուսն էլ ներքին վերնագիրը թողնում են անխախտ, դրա համար հեռավոր կողմը կարող է այն երթուղել ապափաթեթավորումից հետո։

Վայրերի միջև ուղին տեսնում է միայն UDP 4500, երբ IPsec-ը օգտագործում է NAT-ի անցում, կամ UDP 51820 WireGuard-ի լռելյայն ունկնդրի համար։ Ուղու ցանկացած երթուղիչ կարող է լինել միայն IPv4, և IPv6 հոսքը միևնույն է անցնում է, որովհետև այդ ուղու վրա այն երբեք չի երևում որպես IPv6 փաթեթ։ Դա տալիս է մաքուր առաջին բաժանում․ tcpdump -ni eth0 udp port 51820 ցույց է տալիս գաղտնագրված ուղին, tcpdump -ni wg0 ip6 ցույց է տալիս ներքին հոսքը։ Զբաղված արտաքին որսումը լուռ ներքինի հետ նշանակում է, որ կեռնելը IPv6 չի դնում թունելի մեջ․ դա երթուղում կամ քաղաքականություն է, ոչ թե կապի վիճակ։

Դարպասը նաև իջեցնում է ներքին Hop Limit-ը փոխանցելիս, ուստի ծայրամասերը հաշվվում են որպես երթուղիչներ IPv6 ուղու վրա։ Արտաքին թռիչքների քանակը և ներքին Hop Limit-ը շարժվում են անկախ, և հեռավոր դարպասում մահացած փաթեթը մահացել է փոխանցման ժամանակ, ոչ գաղտնագրման։

Ընտրիչները և AllowedIPs-ը թույլտվությունների ցանկն են

IKEv2-ը համաձայնեցնում է, թե ինչ ներքին նախածանցեր child SA-ն կարող է կրել։ strongSwan 5.9-ում և ավելի նորում դրանք swanctl.conf-ում գրելը այսպիսի տեսք ունի․

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

Եթե բաց թողնեք local_ts-ը և remote_ts-ը, strongSwan-ը դրանք բխեցնում է իր ընտրած միջերեսի ենթացանցերից։ Dual-stack հոսթում այդ կարճուղին հաճախ տալիս է միայն IPv4 զույգ․ SA-ն բարձրանում է, և IPv6-ը մերժվում է մինչև ESP կոդին հասնելը։ Երկու նախածանցերն էլ գրելը SA-ն դարձնում է դրանք կրելու ունակ, և start_action = trap այն բարձրացնում է առաջին համապատասխան փաթեթում։

WireGuard-ն ունի մեկ ցանկ, որ երկու աշխատանք է կատարում։ Գործընկերոջ բլոկում AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48-ը և՛ ուղին է, որ տեղադրվում է ուղարկելիս, և՛ ֆիլտրը, որ կիրառվում է ընդունելիս․ ապակոդավորված փաթեթը, որի ներքին աղբյուրը դուրս է ընկնում այդ գործընկերոջ ցանկից, լուռ թափվում է։ wg-quick ամեն գրառման համար ուղի է ավելացնում, ուստի ներքևի գործընկերոջ բլոկին առանձին ip -6 route հրաման պետք չէ։

[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

Երկու ցանկերն էլ պետք է հայելային լինեն․ B վայրը ընդունում է A վայրի նախածանցը որպես հեռավոր ընտրիչ և երթուղում է այն հետ, և թունելը աշխատում է միայն, երբ երկու ուղղությունները համաձայն են։ Ասիմետրիկ ցանկը տալիս է ամենաշատ ժամանակ խլող ախտանիշը․ առողջ ձեռքսեղմում, հաշվիչներ, որոնք շարժվում են մի կողմում, և ping A-ից B, որը հաջողվում է, մինչդեռ B-ից ոչինչ չի հասնում A։

Փոխանցում, երթուղիներ և վերադարձի նախածանց

Linux-ը IPv6 չի փոխանցում, քանի դեռ չեք ասել, և կարգավորումը վերաբերում է namespace-ին, ոչ միջերեսին․

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

Երկրորդ տողն այն է, որ մարդիկ մոռանում են երթուղու վրա հիմնված նախագծերում։ Քաղաքականության վրա հիմնված IPsec-ը տեղադրում է XFRM քաղաքականություն, որը համապատասխանում է նախածանցերին, բայց vti6-ով կամ WireGuard-ով երթուղու վրա հիմնված կարգավորումը պահանջում է իսկական IPv6 երթուղի, որն ուղղված է այդ սարքին։ Պահպանեք sysctl-ը /etc/sysctl.d/-ի տակ, այլապես վերագործարկումը լուռ վերադարձնում է փոխանցումը անջատված վիճակի։

Փոխանցումն ունի կողմնակի ազդեցություն, որ արժե իմանալ․ կեռնելն այնուհետև անտեսում է երթուղիչների հայտարարությունները, քանի դեռ net.ipv6.conf.<wan>.accept_ra-ը 2 չէ, ուստի դարպասը, որի WAN հասցեն գալիս է SLAAC-ով, կարող է կորցնել իր լռելյայն երթուղին այն պահին, երբ միացնում եք փոխանցումը։ Սահմանեք accept_ra = 2-ը այդ միջերեսի վրա նույն ֆայլում, և երթուղին կենդանի կմնա։ B վայրի կեռնելը նույնպես պետք է սովորի 2001:db8:aa::/48-ը թունելի դարպասից՝ ստատիկ երթուղով կամ թունելի վրայով երթուղման արձանագրությամբ, այլապես պատասխանը մահանում է B-ի սեփական ցանցում։

Չորս քայլ ստուգում, որը տեղայնացնում է խախտումը

Աշխատեք այս կարգով և կանգ առեք առաջին քայլում, որ ձախողվում է, որովհետև յուրաքանչյուր հաջորդ քայլ կախված է նախորդներից։

  1. Ընտրիչներ․ swanctl --list-sas պետք է ցույց տա IPv6 նախածանցերի զույգը child SA-ի վրա, կամ wg show wg0 allowed-ips հեռավոր նախածանցը թարմ latest-handshakes-ով։
  2. Կեռնելի երթուղի․ ip -6 route get 2001:db8:bb::10 պետք է պատասխանի թունելի սարքով, ոչ WAN միջերեսով։
  3. Ներքին որսում․ tcpdump -ni wg0 ip6 իրական LAN հոսթերի միջև ping անելիս։ Փաթեթներ, որոնք դուրս են գալիս, բայց ոչ մեկը չի վերադառնում, մատնանշում են B-ի երթուղին կամ պատնեշը․ փաթեթների լրիվ բացակայությունը մատնանշում է 1 կամ 2 քայլին։
  4. Նպատակակետ․ B հոսթում ss -6 -ltn հաստատում է, որ ծառայությունը լսում է IPv6-ով, և տեղական պատնեշի հաշվիչները ցույց են տալիս՝ փաթեթն ընդունվե՞լ է, թե՞ թափվել։

MTU-ն նույն անցման մեջ է։ IPv6 երթուղիչները չեն հատվածավորում, ուստի չափից մեծ փաթեթը թափվում է և Packet Too Big-ը վերադառնում է ուղարկողին։ Եթե ձեռքսեղմումներն ու փոքր ping-երը աշխատում են, բայց ֆայլի փոխանցումը կանգ է առնում, փոքրացրեք բեռնվածությունը, մինչև այն անցնի․ ping -6 -s 1400 -c 3 2001:db8:bb::10։ WireGuard միջերեսները լռելյայն ունեն 1420 բայթ MTU, և IPv4-ի վրայով IPsec-ը ավելի շատ է հանում, ուստի ներքին MTU-ն սահմանելը ավելի լավ է, քան ICMPv6-ը թափող պատնեշի միջով ուղու MTU-ի հայտնաբերման հույսը։

Ձախողման ռեժիմներ, որոնք նման են պատնեշի խնդիրների

Ամենատարածվածը ամենևին էլ պատնեշ չէ․ ծառայությունը կապվում է 0.0.0.0-ին ::-ի փոխարեն, AAAA գրառումը գոյություն ունի, և հաճախորդը IPv6-ով արագ մերժում է ստանում, որը dual-stack զննարկիչը թաքցնում է IPv4-ին հետ գալով։ Եթե միայն որոշ ծրագրեր են ձախողվում, ստուգեք լսող ընտանիքը՝ կանոնների հավաքածուն դիպչելուց առաջ։

Երկրորդը ICMPv6-ի ֆիլտրումն է։ Neighbor Discovery-ն ու Packet Too Big-ը նորմալ աշխատանքի մասն են, ոչ ախտորոշման, և քաղաքականությունը, որ թափում է ողջ ICMPv6-ը, ստեղծում է թունել, որը միանում է, իսկույն վավերացվում և հետո կանգ է առնում ամեն ինչի վրա, որ փոքր փաթեթից մեծ է։ Թույլատրեք տեսակները, որոնցից կախված է ուղին, և թողեք հաշվիչները միացված, որ թափումը տեսանելի լինի։

Երրորդը նախածանց է, որ ավելացվում է թունելին, բայց երբեք՝ այն վայրի հասցեների պլանին, որին պատկանում է, ուստի ոչ մի երթուղիչ այն չի հայտարարում և ոչ մի հոսթ չի կարող պատասխանել դրանից։ Սկսեք մեկ նախածանցով և մեկ հոսթերի զույգով, ապացուցեք երկու ուղղությունները չորս քայլերով, ապա ավելացրեք մնացածը․ փչացած նախածանցը մնում է մեկ տող կարգավորումներում՝ վերակառուցման փոխարեն։ Միակ պաշտոնական հղումը, որ արժե բաց պահել, RFC 8200-ն է, որը սահմանում է վերնագիրը, որ թունելը կրում է։

Առնչվող հոդվածներ