WireGuard faqat server avval yuborgandan keyin ishlaydi: so'nggi nuqtani bilish

Tunnel faqat server avval biror narsa yuborgandan keyin ishlayotgandek ko'rinadi. Mijozdan boshlang va hech narsa bo'lmaydi, bir necha soniya kuting, qayta urinib ko'ring va u muvaffaqiyatli bo'ladi. Odatiy tashxis buzuq NAT, va odatiy tashxis noto'g'ri. O'zgargan narsa — bir tomon ikkinchisi qayerda yashashini bilib oldi.

So'nggi nuqtani bilish, erishish emas

WireGuard tomoni qayerga yuborishni bilmaguncha qo'l berib ko'rishishni boshlamaydi. Konfiguratsiya buni manzil va portdan iborat so'nggi nuqta sifatida beradi, ishlab turgan holat esa hozir ishonayotgan so'nggi nuqtani kuzatadi.

wg show bu manzaraning ikkala tomonini ham chiqaradi, va chiqishda so'nggi nuqtasi yo'q tomon, uning ochiq kaliti va ruxsat etilgan prefikslari qanchalik to'g'ri bo'lsa ham, hech narsa boshlay olmaydi. Har qanday qoidani o'zgartirishdan oldin mijozning qarashini serverniki bilan solishtiring, chunki ikkisi kim nima bilishini ko'p hollarda kelishtirmaydi.

Tomon so'nggi nuqtani qanday o'rganadi

WireGuard ataylab jim. To'g'ri autentifikatsiya qilingan paket tomon kutmagan manzildan kelganda, amalga oshirish o'sha tomonning so'nggi nuqtasini yangi manbaga yangilaydi, va tarmoqlarni almashtiruvchi noutbukda rouming shunday ishlaydi. Bu xatti-harakat yo'nalishga bog'liqlikni tushuntiradi: agar server birinchi yuborsa va uning paketi mijozga yetsa, mijoz serverning joriy manzilini o'rganadi va javob bera oladi. Ungacha uning yuboradigan joyi yo'q. Mexanizm birinchi foydalanishdagi ishonch qisqartmasi emas, autentifikatsiyalangan rouming, chunki paket so'nggi nuqta siljishidan oldin haqiqiy bo'lishi kerak edi.

wg uchun asboblar hujjati o'sha yangilanishni tavsiflaydi, va agar shu atrofida loyihalashtirmoqchi bo'lsangiz, bir marta o'qishga arziydi.

Holat saqlovchi tarjima o'z yo'nalishini qo'shadi

UDP tarjima qiluvchi shlyuzdan o'tganda, shlyuz o'zi ko'rgan birinchi paket uchun holat yaratadi. RFC 4787 bu xatti-harakatni va xaritani oxir-oqibat olib tashlaydigan muddatlarni tavsiflaydi. Bo'sh xarita muddati tugaydi, va uzoq tomondan kelgan kiruvchi paket hostga yetmasdan oldin shlyuz tomonidan tashlanadi. Butun ertalab ishlagan tunnel aynan shu sababdan tushdan keyin javob berishni to'xtatadi.

Bu bir xil yo'nalish belgisini keltirib chiqaradigan ikkinchi va mustaqil mexanizm. So'nggi nuqtani bilish ham, tarjima holati ham to'g'ri bo'lishi kerak, va birini tuzatish ikkinchisini tuzatmaydi.

Haqiqatan xohlagan yo'nalishni sozlang

Ulanishni boshlashi kerak bo'lgan mijoz uchun serverning so'nggi nuqtasini mijozning tomonlar bo'limiga qo'ying va o'sha yerda qoldiring. Server birinchi yuboradi deb ishonish — tinch tarmoqda o'zgaradigan trafik tartibidagi tasodifga ishonish. Konfiguratsiya mo'ljallangan yo'nalishni e'lon qilishi kerak, uni kashf qilmasligi kerak.

Tarjima orqasidagi va erishish mumkin bo'lib qolishi kerak bo'lgan tomon uchun o'sha tomonda doimiy keepalive yoqing. Har 25 soniyada keepalive odatiy boshlang'ich qiymat, va uning maqsadi tunnelni sinash emas, xaritani ochiq saqlash. Uni olib yurish uchun bir tomonni tanlang, chunki ikkala tomonda yoqish natijani yaxshilamasdan trafik va jurnal shovqinini ikki barobar oshiradi.

Holatni qo'zg'atuvchidan oldin va keyin solishtiring

U muvaffaqiyatsiz bo'lgan paytda ikkala qarashni yozib oling, keyin server yuborgandan keyin yana. Birinchi buyruq so'nggi nuqtalarni va qo'l berib ko'rishish yoshini ko'rsatadi. Ikkinchisi port uchun tarjima yozuvi bor-yo'qligini ko'rsatadi. Yozuv qaysi yo'nalish haqiqatan simdan o'tganini ko'rsatadi, marshrut tekshiruvi esa mijoz bu trafikni butunlay boshqa joyga yubormayotganini tasdiqlaydi.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

So'nggi nuqta ustunini va tarjima yozuvini birga yozib qo'ying. So'nggi nuqtasi yo'q tomon va xaritasi yo'q shlyuz ikki xil nosozlik. Ulardan faqat bittasini keepalive tuzatadi.