Saytlar orasidagi VPN orqali IPv6 prefiksini delegatsiya qilish: tekshiruv ro'yxati

Tunnelni ko'tarish — oson yarmi. Saytlar orasidagi aloqa kunlar davomida o'rnatilgan turganini, ammo uzoqdagi LANdagi har bir xost faqat sukunat qaytarganini ko'rdim, chunki o'sha shlyuz orqasidagi delegatsiya qilingan prefiks interfeysda sozlangan, lekin hech qachon tunnelga marshrutlanmagan. Tunnel manzillari butun vaqt davomida pingga javob berdi va aynan shuning uchun hech kim prefiksga qaramadi. Delegatsiya qilingan IPv6 prefiksi sayt VPNidan o'tishi kerak bo'lganda men tekshiradigan tartib: prefiks xaritasi, trafik selektorlari, forvarding va firewall, so'ngra qaytish yo'li.

Tunnelga tegishdan oldin prefiks xaritasini yozing

Prefiks delegatsiyasi blokni uni so'ragan marshrutizatorga beradi. U peerda marshrut o'rnatmaydi, bu blokni on-link kengaytirmaydi va uzoq shlyuzga so'rovchi marshrutizator orqasida nima borligini aytmaydi. Bu uchtasini o'zingiz sozlashingiz kerak va ular har qanday konfig fayli o'zgarishidan oldin manzillar rejasida bo'lishi lozim.

Har bir sayt uchun delegatsiya qilingan prefiks, LANda haqiqatda ishlatiladigan /64, tunnel manzillari va har bir marshrut egasini yozib qo'ying. Provayder A saytiga 2001:db8:a1::/56 ni delegatsiya qiladi, u o'z LANida 2001:db8:a1:10::/64 ni taqdim etadi; B sayti 2001:db8:b2::/64 ni saqlaydi. Agar A sayti faqat o'sha bitta /64 ni taqdim etsa, ikki tomon ham butun /56 emas, 2001:db8:a1:10::/64 ni ko'rsatishi kerak.

Deyarli har doim ikkita xato ko'rinadi. Biri uzoq prefiksni on-link deb hisoblash, uni ko'prik qilish yoki tunnel interfeysiga qo'yish, natijada shlyuz yetib bora olmaydigan xostlar uchun qo'shni so'roviga javob beradi. Ikkinchisi faqat bitta /64 sozlanganda butun /56 ni e'lon qilish: marshrut jadvali blok yetib borishini da'vo qiladi va manzillarning ko'pchiligi qora chuqurga tushadi.

Ikki tomonning trafik selektorlarini marshrutlarga moslashtiring

IKEv2 ham, WireGuard ham mos kelmaydigan trafikni rad etadi, tunnel hali ham sog'lom ko'rinadigan darajada jim.

strongSwanda selektorlar aniq ko'rsatiladi. A saytida:

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

B saytining conn yozuvi ikkala subnetni aks ettiradi. Ular mos kelmasa, javob beruvchi CHILD_SAni TS_UNACCEPTABLE bilan rad etadi, shuning uchun IKE_SA ko'tarilgan bo'lsa ham child SA hech qachon ko'tarilmaydi. Ikkala tomonda ham sozlangan subnet lokal yadro tunnel tomon marshrutlaydiganiga teng bo'lishi kerak.

WireGuard xuddi shu ma'lumotni AllowedIPs da olib yuradi, bitta burilish bilan: AllowedIPs qabul qilishda manba filtri va yuborishda marshrut. Agar B saytining A sayti uchun peer yozuvi 2001:db8:a1:10::/64 ni tashlab ketsa, A saytidan kelgan paketlar yaroqli handshake bilan keladi va ruxsat berilmagan deb tashlanadi. Shundan tanish naqsh paydo bo'ladi: handshake doimiy yangilanadi, ammo javob hech qachon chiqmaydi. Ikki tomonni wg show wg0 allowed-ips bilan solishtiring. Delegatsiya o'zgarganda o'sha ro'yxatni qayta tekshiring; eskirgan /64 sessiyani tirik saqlaydi va yangi prefiksni yetib bo'lmas qiladi.

Avval forvarding, firewall va MTUni istisno qiling

Keyingi log satrini o'qishdan oldin shlyuzlar umuman forvard qilishini tasdiqlang. sysctl net.ipv6.conf.all.forwarding ikkalasida ham 1 qaytarishi kerak, tunnel va LAN interfeyslariga ham qo'llaniladi. Bitta tuzoq ham bor: forvarding yoqilgach, accept_ra=1 bo'lgan interfeys provayderdan marshrutizator e'lonlarini qabul qilishni to'xtatadi, shuning uchun qurilma tunnel ichida mukammal marshrutlab turib, yuqori oqimdagi standart marshrutini yo'qotishi mumkin. Provayder RA hali kerak bo'lgan joyda accept_ra=2 o'rnating.

Keyin firewall qoidalari prefiksni ikki yo'nalishda ruxsat berishi kerak, ICMPv6 esa omon qolishi lozim: qo'shni aniqlash, packet-too-big va destination-unreachable ixtiyoriy emas. Ularni tashlasangiz, yo'l MTUsini aniqlash buziladi va ochilib, birinchi katta javobda to'xtab qoladigan ulanishlar olasiz. Minimal qoidalar juftligi shunday ko'rinadi:

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 buning orqasida turadi. Tunnel foydalanish mumkin bo'lgan MTUni 1500 dan pastga tushiradi, IPv6 esa har bir bog'lanish kamida 1280 olib yurishini talab qiladi. Kichik pinglar o'tadi, SSH sessiyasi katta portlashda qotib qoladi va /proc/net/snmp6 hech qachon qaytmaydigan packet-too-big xabarlarini ko'rsatadi. Tunnel MTUsini aniq belgilang yoki mangle jadvalida TCP MSSni cheklang va kichikroq MTU haqida xabar beruvchi ICMPv6 qaytishiga yo'l qo'ying.

Tunnel manzilini emas, qaytish yo'lini sinang

Eng ko'p vaqt oladigan nosozlik — bir tomonlama marshrutlash. Har bir shlyuz uzoq prefiksni tunnelga marshrutlaydi, ammo xostlar o'zlarining standart shlyuzi orqali javob beradi, chunki ularning /64 i o'sha yerda joylashgan. Paketni manzilga yetkazish — yo'lning yarmi.

Ikki buyruq ko'p qismini hal qiladi. A saytida ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 o'sha manbadan keladigan javob qaysi interfeysdan foydalanishini ko'rsatadi; B saytida oynali tekshiruvni bajaring. So'ngra trafikni shlyuzdan emas, xostdan hosil qiling va ikki tomondagi hisoblagichlarni solishtiring.

Agar uzoq prefiks uchun qo'shni so'rovi tunnelda ko'rinsa, o'sha prefiks bo'lmasligi kerak joyda on-link; marshrutlarni sozlashdan oldin buni tuzating. Proxy NDP ko'prik chindan ham zarur bo'lgan holatlarni qamrab oladi, marshrutning o'rnini bosmaydi.

Prefiks o'zgarishini rejalashtiring

Prefiks delegatsiyasi delegatsiya qiluvchi va so'rovchi marshrutizator o'rtasidagi ijara bo'lib, yangilash boshqa blok qaytarishi mumkin: provayder migratsiyasidan keyin boshqa /56 yoki tunnel ishlagan davrdan qisqaroq ijara. Eski prefiksni tilga oladigan har bir joy birdan eskiradi: marshrutlar, selektorlar, AllowedIPs, firewall qoidalari, DNS yozuvlari va harfiy manzillarni hardcode qilgan har qanday monitoring. Xabarlar oqimi RFC 8415 da.

Prefiks ko'chishi kutiladigan joyda unga bog'liq bo'lmagan ichki manzillar rejasini saqlang va chegarada tarjima qiling. NPTv6 holatsiz variant bo'lib, ichki siyosatni o'qiladigan saqlaydi, ammo bu prefiks tarjimasi, sehrli qatlam emas: /64 chegaralari mos kelishi kerak, checksumlar tuzatiladi, harfiy manzillarni o'z ichiga olgan ilovalar esa baribir buziladi. Provayder manzillarini uchtan-uchiga saqlasangiz, ijara xatti-harakati va o'zgartirish tartibini manzillar rejasida yozib qo'ying.

Vaqtga bardosh beradigan sinov bilan yakunlang: har bir LANdagi ruxsat etilgan xost boshqa LANdagi xizmatga yetadi, javob tunnel orqali qaytadi va o'sha juftlik tunnel qayta ishga tushirilgandan hamda delegatsiya yangilangandan keyin ham ishlaydi. Agar oxirgi qism muvaffaqiyatsiz bo'lsa, loyiha haftaga chidamaydigan holatga bog'liq.