IPv4 VPN serveri orqali IPv6 hamon haqiqiy IPv6 chiqishini talab qiladi

Tunnel ko‘tariladi, mijoz hovuzdan IPv6 manzilini oladi, va baribir har bir IPv6 manzil vaqt tugashi bilan yakunlanadi. Tunnelda hech narsa buzilmagan: IPv6 IPv4 transporti ichida juda yaxshi harakatlanadi, va bu hech qachon qiyin qism bo‘lmagan. Siz bergan manzil — server bajara olmaydigan va’da, chunki chiqishda uni yuboradigan IPv6 upstream yo‘q. Tuzatish chiqishda bo‘lishi kerak, mijoz profilida emas.

Alomat: manzil bor, yo‘l yo‘q

Mijoz tomonidagi tekshiruv tunnel qurilmasida global ko‘rinadigan IPv6 manzilini va unga ishora qiluvchi yo‘lni ko‘rsatadi, shuning uchun bu noto‘g‘ri ravishda mijoz xatosi deb o‘qiladi. Trafik tunnelga kiradi, server uni dekapsulyatsiya qiladi, so‘ngra paket marshrutlash jadvalida haqiqiy joyga IPv6 standart yo‘li bo‘lmagan xostga tushadi. Stekka qarab darhol yetib bo‘lmaslik yoki jimgina tashlab yuborish olasiz, ikkala holatda ham mijoz xuddi xavfsizlik devoriga o‘xshash vaqt tugashini ko‘radi.

Mijozga tegishdan oldin serverning o‘z marshrutlash jadvalini o‘qing, chunki yo‘lning yetishmayotgan yarmi shu yerda yashaydi. Bitta IPv4 standart yo‘li bo‘lgan server sizga javobni allaqachon bergan.

Dekapsulyatsiyadan keyin paketni kuzatib boring

Tunnel ichida paket oddiy IPv6, uning manbasi esa mijoz manzili. Server transport kapsulyatsiyasini yechadi va keyin keyingi IPv6 sakrashiga uzatilishi kerak bo‘lgan mahalliy IPv6 paketini ushlab turadi. IPv4 standart yo‘li uni ko‘tara olmaydi, va uni IPv4 ga aylantirish hech kim joriy qilmagan boshqa funksiya. Bu butun nosozlik, va bu VPN tinglovchisining IPv4 orqali javob berganiga hech qanday aloqasi yo‘q.

IPv6 ni IPv4 ustida kapsulyatsiya qilish mexanikasi RFC 4213 da tasvirlangan, va u yerdagi muhim tafsilot shuki, uchlar tunnelning narigi tomonida hali ham haqiqiy IPv6 ulanishiga muhtoj. Sarlavhani o‘rash upstreamni yo‘qdan yaratmaydi.

Ikki tunnel qatlami, ikki mustaqil tekshiruv

Har bir qatlamni alohida tekshiring, chunki ishlayotgan tashqi tunnel buzilgan ichki tunnelni yashiradi. Tashqi yo‘lni mijozdan serverga IPv4 ping bilan tekshiring va ishlatayotgan portni tasdiqlang. So‘ngra serverda ichki yo‘lni tekshiring, u yerda ip -6 route haqiqiy upstreamdan o‘rganilgan standart yoki aniq yo‘lni ko‘rsatishi kerak, va ip -6 addr upstream qabul qiladigan manba prefiksini ko‘rsatishi kerak. Bundan kam narsa interfeysdagi bezakdir.

Noyob-mahalliy manzil yoki global ko‘rinadigan, lekin hech narsa unga qaytib marshrutlamaydigan prefiks interfeysda xursandchilik bilan paydo bo‘ladi va hech qayerga ketmaydi. Ommaviy yetib borishni upstream beradi, manzilning shakli emas.

Xuddi shu narsa mijozga ham tegishli: ip -6 route get 2001:4860:4860::8888 tunnel qurilmasini nomlashi kerak, agar u jismoniy qurilmani nomlasa, mijoz IPv6 uchun VPN dan umuman foydalanmaydi.

Manba prefiksi, o‘lchami va ICMPv6

Upstreamdan yuborish uchun qaysi manba prefikslarini qabul qilishini so‘rang va ulardan birini mijoz hovuzi uchun ishlating. Serverning o‘z interfeysi uchun sizga /64 beradigan provayder sizga ikkinchi /64 yoki kattaroq blokni albatta marshrutlamaydi, va farq — bitta qo‘llab-quvvatlash chiptasi bitta savol bilan hal qiladigan yarim kunlik disk raskadrovka. Yozma ravishda so‘rang va javobni konfiguratsiya bilan birga saqlang.

Stekingiz haqiqatda ishlatadigan qo‘shimcha kapsulyatsiya uchun byudjet ajrating va ICMPv6 ni Packet Too Big bilan birga ishlab turing. Ikkinchi sarlavha foydali yukni kichraytiradi, shuning uchun kichik pinglarga javob beradigan yo‘l fayl uzatishda baribir muvaffaqiyatsiz bo‘lishi mumkin, va butun ICMPv6 ni tashlaydigan xavfsizlik devori tuzatish mumkin bo‘lgan o‘lcham muammosini qora tuynukka aylantiradi. Xizmatni e’lon qilishdan oldin bitta katta uzatishni sinab ko‘ring.

Nima butunlay boshqa muammo

Faqat IPv4 ishlaydigan ilovaga faqat IPv6 ishlaydigan mijozdan yetib borish — bu tarjima, tunnel emas, va ataylab joylashtirilgan NAT64 kabi narsani talab qiladi. Manzil faqat siz qo‘shimcha tunnel sarlavhasini qo‘shganingiz uchun uni tushunmaydi. Tarixiy o‘tish xizmatlari ham xuddi shunday e’tiborga loyiq: RFC 7526 6to4 anycast relay modelini bekor qildi, shuning uchun uning atrofida yozilgan qo‘llanma endi qo‘llab-quvvatlanadigan ommaviy relayga ega bo‘lmagan narsani tasvirlaydi.

Agar serverda foydalanishga yaroqli IPv6 upstream bo‘lmasa, tanlovlar — qo‘llab-quvvatlanadigan upstream, boshqa chiqish yoki IPv6 tunneldan tashqarida qoladi degan hujjatlashtirilgan qaror. Qabul qilib bo‘lmaydigan narsa — mijozlarga IPv6 xizmati borligini aytish, vaholanki ularning oddiy IPv6 ulanishi VPN ni jimgina chetlab o‘tmoqda.