Bir yolu sübut edən iki peer-li WireGuard testi necə qurulur

Default marşrut, LAN prefiksi, DNS və firewall istisnası daşıyan WireGuard testi hansının pozulduğunu deyə bilməz. Onu iki peer-ə, bir ünvan cütünə və bir icazəli xidmətə endirin, o zaman nasazlığın gizlənəcək yeri qalmaz. Darıxdırıcı baza diaqnostikadır. Əvvəlcə onu qurun; on beş dəqiqə çəkir və təxminlərlə keçirəcəyiniz günortadan sonranı xilas edir.

Bazanın sübut etdiyi şey çoxlarının gözlədiyindən dardır. O, iki kimliyin razılaşdığını, UDP-nin dinləmə portuna çatdığını və bir icazəli təyinatın sorğu daşıdığını sübut edir. Forward, NAT, LAN marşrutları və DNS sonra əlavə olunan ayrı funksiyalardır, hər dəfə bir.

Açarlar, ünvanlar və tək endpoint

Hər sistemdə bir açar cütü yaradın və aralarında yalnız açıq yarıları köçürün. wg genkey | tee privatekey | wg pubkey > publickey sənədləşdirilmiş birsətirlik əmrdir və şəxsi açarı sonra qoruya biləcəyiniz faylda saxlayır. Tunel ünvanlarını sahib olduğunuz heç bir digər konfiqurasiyada görünməyən diapazondan seçin, məsələn 10.99.0.1/24 və 10.99.0.2/24. Hansı ünvanın hansı maşına aid olduğunu yazın, çünki sonrakı hər yoxlama bu uyğunlaşdırmadan asılıdır.

Şəxsi açarlar heç vaxt səyahət etmir. Test onlardan birini digər tərəfə köçürməyi tələb edirsə, test artıq səhv gedib. İki sistem NAT arxasındadırsa, heç olmasa birinə çatan UDP portu lazımdır, digəri isə ona yönələn Endpoint daşıyır, açıq ünvan və port isə 51820 ilə bağlı fərziyyələrinizdə deyil, qeydlərinizdə olmalıdır.

Fərqli xarici portu uyğunlaşdıran port forward, Endpoint ona uyğun gəldikcə yaxşı işləyir. Burada uyğunsuzluqlar xəta deyil, sükut yaradır, buna görə də simdə sazlamaqdan əvvəl kağız üzərində yoxlamağa dəyər.

wg-yə aid olan sahələr və olmayanlar

Əsas sahə dəsti kiçikdir: Interface altında PrivateKey və ListenPort, Peer altında PublicKey, AllowedIPs və Endpoint. Address və DNS wg-nin özünə deyil, wg-quick-ə aiddir və bu fərq eyni konfiqurasiya başqa alətə keçdiyi anda özünü göstərir.

[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 eyni anda iki iş daşıyır. Hansı təyinatların tunelə girdiyini seçir və peer-ə həmin mənbə ünvanlarını gəlişdə istifadə etmək icazəsi verir. Buna görə digər tərəfdəki güzgü qeydi tunel ünvanınızı dəqiq adlandırmalıdır; səhv peer üçün /32 marşrut problemi kimi oxunur və avtorizasiya problemi kimi davranır. WireGuard sürətli başlanğıcı sahə adlarını müqayisə etmək istəsəniz, eyni iki peer formasını kanonik ifadə ilə göstərir.

İkonu deyil, handshake-i oxumaq

İnterfeysi kim idarə edirsə onun vasitəsilə qaldırın, sonra status işığı deyil, vəziyyəti oxuyun. wg show hər peer üçün son handshake-i bayt sayğacları ilə çap edir və son bir neçə dəqiqə ərzində handshake açarların, endpoint-in və UDP yolunun hamısının işlədiyini bildirir. Yalnız bir istiqamətdə artan sayğac öz cavabıdır və heç vaxt baş verməyən handshake ilə eyni nasazlıq deyil.

İki nasazlıq fərqli araşdırmalar tələb edir. Heç bir handshake olmaması açar uyğunsuzluğuna, səhv Endpoint-ə, bloklanmış UDP-yə və ya handshake-in özünü atan firewall-a işarə edir. Handshake uğurla keçib data heç yerə getmirsə, bu AllowedIPs-ə, tunel ünvanında dinləməyən xidmətə və ya portu LAN üçün qəbul edib tunel interfeysi üçün qəbul etməyən host firewall-a işarə edir. Bunlar sistemin fərqli yarılarıdır və baza qaydaları dəyişməyə başlamazdan əvvəl onları ayırır.

Bir icazəli xidmətin sübutu, sonra əksi

Digər peer-in tunel ünvanına cavab verməli olan bir xidmətə sorğu göndərin və ping-dən yaxşısını seçin. Çatışmayan ICMP cavabı tunel nasazlığı deyil, host filtrləməsi ola bilər, buna görə səssiz ping heç bir istiqaməti sübut etmir. Açıq olduğunu bildiyiniz porta TCP bağlantısı və ya data qaytaran sorğu sizə şərh edə biləcəyiniz cavab verir.

Əks istiqaməti öz nəticəsi olan ayrı test kimi işlədin, çünki iki istiqamətin ayrı firewall və AllowedIPs qeydləri var və müstəqil şəkildə uğursuz ola bilər. Handshake işləyib sorğu işləmirsə, problem tuneldə deyil, data yolundadır: AllowedIPs, dinləyən xidmət və ya host firewall. Bunu forward, NAT və ya DNS əlavə etməzdən əvvəl düzəldin, yoxsa günortadan sonranı heç vaxt günahkar olmayan bir funksiyanı sazlayaraq keçirəcəksiniz.

Bazanı istinad kimi saxlamaq

İşləyən topologiyanı və profil mənbəyini bərpa edə biləcəyiniz yerdə saxlayın və onu publik xidmətə sinxronlaşan heç bir qovluqda saxlamayın. Sonra hər dəfə bir funksiya əlavə edin və hər dəfədən sonra ilk sorğunu təkrarlayın: forward, NAT, LAN marşrutu və yalnız ondan sonra DNS. Testi pozan hər əlavə artıq müəyyən edilə biləndir, çünki başqa heç nə dəyişməyib.

Yalnız ikonu yaşıl edən baza növbəti nasazlığa hansı əlavənin səbəb olduğunu sizə deməyib. Bir icazəli yolu istinad kimi işlək saxlayın və hər sonrakı dəyişiklik onunla ölçülür.