Bitta WireGuard peer yetib bo'lmaydi, ikkinchisi ishlaydi: tekshiruv ro'yxati
Ishlayotgan peer faqat o'z kaliti, o'z oxirgi nuqtasi va yo'llarini isbotlaydi. Har qanday qoidani kengaytirishdan oldin muvaffaqiyatsiz peerning AllowedIPs ro'yxatini, hubning yo'naltirishini va ichki manbani solishtiring.
Bitta WireGuard peer trafikni o'tkazadi, ikkinchisi esa qo'l siqishni bajaradi, lekin tunnel ortidagi hech narsaga hech qachon yetib bormaydi. Ishlayotgan peer interfeys, UDP port va server kaliti, ehtimol, joyida ekanini aytadi. U ikkinchi peerning AllowedIPs ro'yxati, uning ichki manba manzili yoki ular orasidagi yo'naltirish qoidalari haqida hech narsa aytmaydi. Ro'yxatni tartib bilan o'ting va sharti bajarilmaydigan birinchi qadamda to'xtang.
1-qadam: Paket o'tishi kerak bo'lgan yo'lni yozib oling
Bitta hubdagi ikki mijoz bir-biriga avtomatik yetib bormaydi. Hub va shu'la sxemasida server paketni wg0 da qabul qiladi va uni yana wg0 dan boshqa peerga yo'naltirishi kerak, bu esa IP yo'naltirish va yo'naltirish qoidasini talab qiladi. To'g'ridan-to'g'ri peer-peer sxemasida har bir tomon ikkinchisining oxirgi nuqtasini va ikkinchisining tunnel manzilini AllowedIPs ichida saqlashi kerak. Har qanday konfiguratsiyani o'qishdan oldin qaysi sxemani tuzatayotganingizni aniqlang.
Kutilgan yo'l qayerga qarash kerakligini ham aytadi. Agar paket hubdan o'tishi kerak bo'lsa, muvaffaqiyatsiz sakrash yuboruvchining AllowedIPs ro'yxati, hubning yo'naltirishi yoki qabul qiluvchining AllowedIPs ro'yxatidir. Agar u to'g'ridan-to'g'ri ketishi kerak bo'lsa, hub ahamiyatsiz va ikkala peerning oxirgi nuqta maydonlari muhim.
2-qadam: AllowedIPs ni ikki tomonda solishtiring, faqat bir tomonda emas
WireGuard AllowedIPs ni bir vaqtda marshrut jadvali va kirish ro'yxati sifatida ishlatadi. Yuborishda tunnelni tanlash uchun manzil peerning AllowedIPs ro'yxatidan qidiriladi; qabul qilishda ichki manba manzili yuboruvchi peerning AllowedIPs ichiga tushishi kerak, aks holda paket tashlanadi. Har qanday tomonda diapazon yetishmasa, bir xil alomat paydo bo'ladi: transport ishlaydi, yuk yo'qoladi.
Faylni emas, tirik holatni o'qing, chunki qayta yuklash jimgina muvaffaqiyatsiz bo'lgan bo'lishi mumkin: sudo wg show wg0 allowed-ips. Serverda muvaffaqiyatsiz peerning yozuvi uning tunnel manzilini o'z ichiga olishi kerak, masalan 10.90.0.3/32. Klientda server peering yozuvi siz sinovdan o'tkazayotgan manzilni o'z ichiga olishi kerak, u hubning tunnel manzili bo'ladimi yoki uzoq quyi tarmoq. Bir-biriga tushadigan diapazonlar qidiruvni noaniq qiladi va siz mo'ljallamagan peerni tanlashi mumkin, shuning uchun ularni alohida tuting.
3-qadam: Ichki manba manzilini tekshiring
10.90.0.3 ni wg0 orqali marshrutlaydigan, lekin paketlarni o'zining Wi-Fi manzilidan yuboradigan klient qabul qiluvchi tomonidan rad etiladi, chunki manba peerning AllowedIPs ro'yxatiga mos kelmaydi. Yadro aslida nimani tanlashini ip route get 10.90.0.3 from 10.90.0.2 bilan, tunnel interfeysiga berilgan manzilni ip -brief addr show wg0 bilan tasdiqlang.
Qabul qiluvchi Linux xostda teskari yo'l filtrlash ikkinchi darvoza. Orqaga yo'l marshrutiga ega interfeysdagi qat'iy rp_filter qaytish yo'li kelgan interfeysga mos kelmaydigan tunnel trafigini tashlashi mumkin. Uni o'chirishdan oldin amaldagi qiymatni tekshiring; ko'p topologiyalarda to'g'ri tuzatish marshrutdir, bo'shashtirilgan filtr emas.
4-qadam: Hubning yo'naltirishi va qaytish yo'lini ko'rib chiqing
Agar hub peerlar orasida yo'naltirishi kerak bo'lsa, yadroga net.ipv4.ip_forward=1 kerak, va xavfsizlik devori yo'naltirilgan oqimni qabul qilishi kerak: wg0 ga kirish, wg0 dan chiqish, yuboruvchining tunnel manzilidan qabul qiluvchinikiga. Keng tarqalgan nosozlik - UDP 51820 ni qabul qiladigan kirish qoidasi bor, lekin yo'naltirish qoidasi yo'q], shuning uchun qo'l siqish muvaffaqiyatli bo'ladi va yuk o'ladi. Amaldagi qoidalarni sudo nft list ruleset yoki xavfsizlik devori menejeringizning ekvivalenti bilan sanab chiqing.
Keyin javobni tekshiring. Manzil xostning yuboruvchiga qaytish marshruti bo'lishi kerak, yo hub orqali yoki o'z shlyuzi orqali. Agar hub tunnel quyi tarmog'ini ham NAT qilsa, tarjima yo'naltirilgan oqimga tatbiq etilishini va javob holat tugashidan oldin hubga yetib borishini tasdiqlang. Kalit muammosiga o'xshab ko'rinadigan bir tomonlama nosozlik ko'pincha aynan shu qaytish marshrutidir.
Nihoyat, qo'l siqishni ma'lumotlardan ajrating. Qo'l siqishni tugatadigan, lekin katta uzatishlarda tiqilib qoladigan peer odatda aynan o'sha yo'lda MTU yoki MSS muammosiga ega, AllowedIPs muammosiga emas. Avval kichik ping bilan, keyin to'liq o'lchamli ping bilan sinab ko'ring va ikkala peerni solishtiring.
5-qadam: Bitta narsani o'zgartiring va ishlayotgan peerni buzilmagan holda saqlang
Muvaffaqiyatsiz yo'lda bitta o'zgarish qiling va ikkala peerni qayta sinab ko'ring. Har bir peerning AllowedIPs ni 0.0.0.0/0 bilan almashtirish allaqachon ishlagan peerni buzishning eng tez yo'lidir, chunki u o'sha interfeysdagi barcha trafik uchun marshrut qarorini o'zgartiradi. O'sha bitta yozuvni tahrirlang, qayta yuklang va tirik holatni qayta o'qing.
Qaysi yo'l muvaffaqiyatli bo'lganini, qaysi biri muvaffaqiyatsiz bo'lganini va har biri uchun aniq buyruq chiqishini yozib oling. Bu taqqoslash VPN buzilgani haqidagi umumiy hisobotdan qimmatroq va keyingi odam birinchi navbatda shuni so'raydi.