Bitta yo'lni isbotlovchi ikki peer'li WireGuard testini qanday qurish kerak

Standart marshrut, LAN prefiksi, DNS va firewall istisnosini olib yuruvchi WireGuard testi qaysi biri buzilganini ayta olmaydi. Uni ikki peerga, bitta manzil juftiga va bitta ruxsat etilgan xizmatga qisqartiring, shunda nosozlikning yashirinadigan joyi qolmaydi. Zerikarli asos — o'sha diagnostika. Avval uni quring; u o'n besh daqiqa oladi va taxmin bilan o'tadigan tushdan keyinni tejaydi.

Asos isbotlagan narsa ko'pchilik kutganidan torroq. U ikki shaxsiyat kelishishini, UDP tinglayotgan portga yetishini va bitta ruxsat etilgan manzil so'rov olib yurishini isbotlaydi. Forwarding, NAT, LAN marshrutlari va DNS keyin birma-bir qo'shiladigan alohida funksiyalar.

Kalitlar, manzillar va yagona endpoint

Har bir tizimda kalit juftini yarating va ular orasida faqat ochiq yarmini ko'chiring. wg genkey | tee privatekey | wg pubkey > publickey hujjatlashtirilgan bir qatorli buyruq bo'lib, shaxsiy kalitni keyin himoya qilishingiz mumkin bo'lgan faylda qoldiradi. Tunnel manzillarini sizdagi boshqa hech qanday konfiguratsiyada uchramaydigan diapazondan tanlang, masalan 10.99.0.1/24 va 10.99.0.2/24. Qaysi manzil qaysi mashinaga tegishli ekanini yozib qo'ying, chunki keyingi har bir tekshiruv shu moslikka bog'liq.

Shaxsiy kalitlar hech qachon sayohat qilmaydi. Agar test ulardan birini boshqa tomonga ko'chirishni talab qilsa, test allaqachon xato ketgan. Ikki tizim NAT orqasida bo'lsa, hech bo'lmaganda biriga yetib boriladigan UDP port kerak, ikkinchisi unga qaratilgan Endpoint olib yuradi, ochiq manzil va port esa 51820 haqidagi taxminlaringizda emas, yozuvlaringizda bo'lishi kerak.

Boshqa tashqi portni moslashtiruvchi port forwarding Endpoint unga mos kelguncha yaxshi ishlaydi. Bu yerdagi nomuvofiqliklar xato emas, sukunat keltiradi, shuning uchun simda tuzatishdan oldin qog'ozda tekshirishga arziydi.

wg ga tegishli maydonlar va tegishli bo'lmaganlari

Asosiy maydonlar to'plami kichik: Interface ostida PrivateKey va ListenPort, Peer ostida PublicKey, AllowedIPs va Endpoint. Address va DNS wg ning o'ziga emas, wg-quick ga tegishli, va bu farq o'sha konfiguratsiya boshqa vositaga o'tgan lahzada tishlaydi.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs bir vaqtning o'zida ikkita ish qiladi. Qaysi manzillar tunnelga kirishini tanlaydi va peerga kelganda o'sha manba manzillarini ishlatishga ruxsat beradi. Shuning uchun narigi tomondagi ko'zgu yozuvi tunnel manzilingizni aniq nomlashi kerak; noto'g'ri peer uchun /32 marshrut muammosi sifatida o'qiladi va avtorizatsiya muammosidek tutadi. WireGuard tez boshlash maydon nomlarini solishtirmoqchi bo'lsangiz, xuddi shu ikki peer shaklini kanonik ifoda bilan ko'rsatadi.

Belgi o'rniga handshake o'qish

Interfeysni unga egalik qiluvchi narsa orqali ko'taring, so'ng status chirog'i emas, holatni o'qing. wg show har bir peer uchun oxirgi handshake ni bayt hisoblagichlari bilan chop etadi, oxirgi bir necha daqiqadagi handshake kalitlar, endpoint va UDP yo'lining barchasi ishlayotganini bildiradi. Faqat bir yo'nalishda o'sadigan hisoblagich o'zining javobi, va u hech qachon sodir bo'lmaydigan handshake bilan bir xil nosozlik emas.

Ikki nosozlik turli tekshiruvlarni bildiradi. Handshake umuman bo'lmasligi kalitlar nomuvofiqligiga, noto'g'ri Endpointga, bloklangan UDPga yoki handshake ning o'zini tashlaydigan firewallga ishora qiladi. Handshake muvaffaqiyatli bo'lib, ma'lumot hech qayerga ketmasa, bu AllowedIPsga, tunnel manzilida tinglamaydigan xizmatga yoki portni LAN uchun qabul qilib, tunnel interfeysi uchun qabul qilmaydigan host firewallga ishora qiladi. Bular tizimning turli yarmlari, va asos qoidalarni o'zgartirishdan oldin ularni ajratadi.

Bitta ruxsat etilgan xizmatni isbotlash, so'ng teskarisi

Boshqa peer ning tunnel manziliga javob berishi kerak bo'lgan xizmatga so'rov yuboring va pingdan yaxshiroq narsani tanlang. ICMP javobining yo'qligi tunnel nosozligi emas, host filtrlash bo'lishi mumkin, shuning uchun jim ping hech bir yo'nalishni isbotlamaydi. Ochiq deb bilgan portga TCP ulanishi yoki ma'lumot qaytaradigan so'rov sizga talqin qilish mumkin bo'lgan javob beradi.

Teskari yo'nalishni o'z natijasiga ega alohida test sifatida ishga tushiring, chunki ikki yo'nalishning alohida firewall va AllowedIPs yozuvlari bor va ular mustaqil ravishda muvaffaqiyatsiz bo'lishi mumkin. Agar handshake ishlab, so'rov ishlamasa, muammo tunnelda emas, ma'lumot yo'lida: AllowedIPs, tinglayotgan xizmat yoki host firewall. Forwarding, NAT yoki DNS qo'shishdan oldin buni tuzating, aks holda hech qachon aybdor bo'lmagan funksiyani tuzatish bilan tushdan keyinni o'tkazasiz.

Asosni etalon sifatida saqlash

Ishlayotgan topologiya va profil manbasini tiklash mumkin bo'lgan joyda saqlang va ularni ommaviy xizmat bilan sinxronlanadigan har qanday papkadan uzoqda tuting. So'ng bir vaqtning o'zida bitta funksiya qo'shing, har biridan keyin asl so'rovni takrorlang: forwarding, NAT, LAN marshruti va shundan keyingina DNS. Testni buzadigan har bir qo'shimcha endi aniqlanadi, chunki boshqa hech narsa qimirlamadi.

Faqat belgini yashil qiladigan asos keyingi nosozlikka qaysi qo'shimcha sabab bo'lgani haqida sizga hech narsa aytmadi. Yagona ruxsat etilgan yo'lni etalon sifatida ishlab turing, va keyingi har bir o'zgarish unga nisbatan o'lchanadi.