IPv6 նախածանցի պատվիրակումը կայքից կայք VPN-ով. ստուգաթերթ
Պատվիրակված IPv6 նախածանցը կայքից կայք VPN-ով երթուղելու ստուգումներ. նախածանցի քարտեզ, թրաֆիկի սելեկտորներ, փոխանցում, MTU, վերադարձի ուղի և վերահամարակալում։
Թունելը բարձրացնելը հեշտ կեսն է։ Ես տեսել եմ կայքից կայք կապ, որը օրերով մնում էր հաստատված, մինչդեռ հեռավոր LAN-ի բոլոր հոսթերը լռություն էին ստանում, որովհետև այդ գեյթվեյի հետևում գտնվող պատվիրակված նախածանցը կարգավորվել էր ինտերֆեյսի վրա, բայց երբեք չէր ուղղորդվել թունելի մեջ։ Թունելի հասցեները ամբողջ ընթացքում պատասխանում էին ping-երին, և հենց դրա համար ոչ ոք չէր նայում նախածանցին։ Ահա այն հերթականությունը, որը ես ստուգում եմ, երբ պատվիրակված IPv6 նախածանցը պետք է անցնի կայքից կայք VPN-ով՝ նախածանցի քարտեզը, թրաֆիկի սելեկտորները, փոխանցումը և firewall-ը, ապա վերադարձի ուղին։
Գրեք նախածանցի քարտեզը, նախքան թունելին դիպչելը
Նախածանցի պատվիրակումը բլոկ է տալիս այն երթուղիչին, որը պահանջել է այն։ Այն երթուղի չի տեղադրում զուգընկերոջ վրա, չի տարածում այդ բլոկը on-link, և չի հայտնում հեռավոր գեյթվեյին, թե ինչ է գտնվում պահանջող երթուղիչի հետևում։ Այս երեքը դուք պետք է կարգավորեք, և դրանք պատկանում են հասցեների պլանին, նախքան որևէ կոնֆիգ ֆայլի փոփոխությունը։
Յուրաքանչյուր կայքի համար գրանցեք պատվիրակված նախածանցը, LAN-ում փաստացի օգտագործվող /64-ը, թունելի հասցեները և յուրաքանչյուր երթուղու սեփականատերը։ Մատակարարը A կայքին պատվիրակում է 2001:db8:a1::/56, որը իր LAN-ում սպասարկում է 2001:db8:a1:10::/64-ը. B կայքը պահում է 2001:db8:b2::/64-ը։ Եթե A կայքը սպասարկում է միայն այդ մեկ /64-ը, երկու ծայրերը պետք է նշեն 2001:db8:a1:10::/64-ը, այլ ոչ ամբողջ /56-ը։
Երկու սխալ գրեթե միշտ ի հայտ է գալիս։ Առաջինը հեռավոր նախածանցը on-link համարելն է՝ այն bridge-ելը կամ թունելի ինտերֆեյսի վրա դնելը, որպեսզի գեյթվեյը պատասխանի հարևանության հարցումներին այն հոսթերի համար, որոնց չի կարող հասնել։ Երկրորդը ամբողջ /56-ը գովազդելն է, երբ կարգավորված է միայն մեկ /64. երթուղային աղյուսակը պնդում է, որ բլոկը հասանելի է, և հասցեների մեծ մասը ընկնում է սև խոռոչի մեջ։
Համապատասխանեցրեք երկու ծայրերի թրաֆիկի սելեկտորները երթուղիներին
Ինչպես IKEv2-ը, այնպես էլ WireGuard-ը մերժում են անհամապատասխան թրաֆիկը՝ բավական լուռ, որ թունելը դեռ առողջ տեսք ունենա։
strongSwan-ում սելեկտորները բացահայտ են։ 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=startB կայքի conn-ը հայելացնում է երկու ենթացանցերը։ Երբ դրանք չեն համընկնում, պատասխանողը մերժում է CHILD_SA-ն TS_UNACCEPTABLE-ով, այնպես որ child SA-ն երբեք չի բարձրանում, թեև IKE_SA-ն բարձրացել է։ Երկու կողմերում էլ կարգավորված ենթացանցը պետք է հավասար լինի այն ամենին, ինչ տեղական kernel-ը ուղղորդում է դեպի թունել։
WireGuard-ը նույն տեղեկատվությունը կրում է AllowedIPs-ում, մեկ հնարքով. AllowedIPs-ը սկզբնաղբյուրի զտիչ է ընդունելիս և երթուղի ուղարկելիս։ Եթե B կայքի peer գրառումը A կայքի համար բաց թողնի 2001:db8:a1:10::/64-ը, A կայքից եկած փաթեթները կհասնեն վավեր handshake-ով և կմերժվեն որպես չթույլատրված։ Դա ստեղծում է ծանոթ օրինաչափություն. handshake-ը շարունակ նորոգվում է, մինչդեռ ոչ մի պատասխան դուրս չի գալիս։ Համեմատեք երկու ծայրերը wg show wg0 allowed-ips-ով։ Վերաստուգեք այդ ցանկը ամեն անգամ, երբ պատվիրակումը փոխվում է. հնացած /64-ը սեսիան կենդանի է պահում, իսկ նոր նախածանցը՝ անհասանելի։
Նախ բացառեք փոխանցումը, firewall-ը և MTU-ն
Նախքան հերթական լոգի տողը կարդալը համոզվեք, որ գեյթվեյները ընդհանրապես փոխանցում են։ sysctl net.ipv6.conf.all.forwarding-ը պետք է վերադարձնի 1 երկուսի վրա էլ՝ կիրառված թունելի և LAN-ի ինտերֆեյսներին նույնպես։ Մեկ թակարդ էլ կա. փոխանցումը միացնելուց հետո accept_ra=1 ինտերֆեյսը դադարում է ընդունել մատակարարի երթուղիչի հայտարարությունները, այնպես որ սարքը կարող է կորցնել վերևին ուղղված լռելյայն երթուղին, թեև թունելի ներսում կատարյալ ուղղորդում է։ Սահմանեք accept_ra=2 այնտեղ, որտեղ մատակարարի RA-ն դեռ պետք է։
Այնուհետև firewall-ի կանոնները պետք է թույլատրեն նախածանցը երկու ուղղությամբ, և ICMPv6-ը պետք է գոյատևի. հարևանի հայտնաբերումը, packet-too-big-ը և destination-unreachable-ը պարտադիր են։ Գցեք դրանք, և ուղու MTU հայտնաբերումը կկոտրվի՝ տալով կապեր, որոնք բացվում են և հետո կանգ են առնում առաջին մեծ պատասխանի վրա։ Կանոնների նվազագույն զույգն այսպիսի տեսք ունի.
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 } acceptMTU-ն դրա հետևում է։ Թունելը օգտագործելի MTU-ն իջեցնում է 1500-ից ցածր, և IPv6-ը պահանջում է, որ յուրաքանչյուր կապ առնվազն 1280 տեղափոխի։ Փոքր ping-երը անցնում են, SSH-սեսիան սառչում է մեծ պոռթկումի վրա, և /proc/net/snmp6-ը ցույց է տալիս packet-too-big հաղորդագրություններ, որոնք երբեք չեն վերադառնում։ Սահմանեք թունելի MTU-ն բացահայտ, կամ սեղմեք TCP MSS-ը mangle աղյուսակում, և թույլ տվեք վերադառնալ ICMPv6-ին, որը հայտնում է ավելի փոքր MTU-ի մասին։
Փորձարկեք վերադարձի ուղին, ոչ թե թունելի հասցեն
Ամենաշատ ժամանակ խլող խափանումը միակողմանի երթուղումն է։ Յուրաքանչյուր գեյթվեյ հեռավոր նախածանցը ուղղորդում է թունելի մեջ, բայց հոսթերը պատասխանում են սեփական լռելյայն գեյթվեյով, որովհետև հենց այնտեղ է ապրում նրանց /64-ը։ Փաթեթը նպատակակետ հասցնելը ուղու կեսն է։
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
Երկու հրաման լուծում են մեծ մասը։ A կայքում ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5-ը ցույց է տալիս, թե որ ինտերֆեյսը կօգտագործեր այդ աղբյուրից եկող պատասխանը. գործարկեք հայելային ստուգումը B կայքում։ Այնուհետև երթևեկություն առաջացրեք հոսթից, ոչ թե գեյթվեյից, և համեմատեք հաշվիչները երկու ծայրերում։
Եթե հեռավոր նախածանցի համար հարևանության հարցումը հայտնվում է թունելի վրա, այդ նախածանցը ինչ-որ տեղ on-link է, որտեղ չպետք է լիներ. ուղղեք դա նախքան երթուղիները կարգավորելը։ Proxy NDP-ն ընդգրկում է այն դեպքերը, երբ bridge-ը իսկապես անհրաժեշտ է, և ոչ թե երթուղու փոխարինող։
Պլանավորեք, որ նախածանցը կփոխվի ձեր տակ
Նախածանցի պատվիրակումը վարձակալություն է պատվիրակող և պահանջող երթուղիչների միջև, և նորոգումը կարող է վերադարձնել այլ բլոկ. այլ /56 մատակարարի տեղափոխումից հետո, կամ ավելի կարճ վարձակալություն, քան թունելը գործել է։ Հին նախածանցը հիշատակող յուրաքանչյուր տեղ միանգամից հնանում է. երթուղիներ, սելեկտորներ, AllowedIPs, firewall-ի կանոններ, DNS գրառումներ և ցանկացած մոնիտորինգ, որը բառացի հասցեներ է կոդավորում։ Հաղորդագրությունների հոսքը RFC 8415-ում է։
Երբ նախածանցը սպասվում է տեղափոխվել, պահեք ներքին հասցեների պլան, որը կախված չէ դրանից, և թարգմանեք սահմանին։ NPTv6-ը անվիճակ տարբերակն է և ներքին քաղաքականությունը ընթեռնելի է պահում, բայց դա նախածանցի թարգմանություն է, ոչ թե կախարդական շերտ. /64 սահմանները պետք է համընկնեն, ստուգիչ գումարները ճշգրտվում են, և բառացի հասցեներ ներառող հավելվածները դեռ կոտրվում են։ Եթե մատակարարի հասցեները պահում եք ծայրից ծայր, գրանցեք վարձակալության վարքը և փոփոխության ընթացակարգը հասցեների պլանում։
Ավարտեք ժամանակին դիմացող թեստով. յուրաքանչյուր LAN-ի թույլատրված հոսթ հասնում է մյուս LAN-ի ծառայությանը, պատասխանը վերադառնում է թունելով, և նույն զույգը դեռ աշխատում է թունելի վերագործարկումից և պատվիրակման նորոգումից հետո։ Եթե վերջին մասը ձախողվի, դիզայնը կախված է վիճակից, որը չի դիմանա շաբաթվան։