WireGuard yalnız server əvvəlcə göndərdikdən sonra işləyir: son nöqtə biliyi

Tonel yalnız server əvvəlcə nəsə göndərdikdən sonra işləyirmiş kimi görünür. Müştəridən başladın və heç nə olmur, bir neçə saniyə gözləyin, yenidən cəhd edin və uğur qazanır. Adi diaqnoz pozulmuş NAT-dır və adi diaqnoz səhvdir. Dəyişən odur ki, bir peer digərinin harada olduğunu öyrənib.

Son nöqtə biliyi, əlçatanlıq deyil

WireGuard peer-i hara göndərəcəyini bilməyincə handshake başlatmır. Konfiqurasiya bunu ünvan və portdan ibarət son nöqtə kimi verir, işləyən vəziyyət isə hazırda inandığı son nöqtəni izləyir.

wg show həmin mənzərənin hər iki tərəfini göstərir və çıxışda son nöqtəsi olmayan peer, açıq açarı və icazə verilmiş prefiksləri nə qədər düzgün olsa da, heç nə başlada bilməz. Hər hansı qaydayı dəyişməzdən əvvəl müştərinin görüşünü serverinki ilə müqayisə edin, çünki ikisi çox vaxt kimin nə bildiyi barədə razılaşmır.

Peer son nöqtəni necə öyrənir

WireGuard qəsdən səssizdir. Düzgün autentifikasiya olunmuş paket peer-in gözləmədiyi ünvandan gələndə tətbiq həmin peer-in son nöqtəsini yeni mənbəyə yeniləyir və şəbəkələri dəyişən noutbukda rouminq belə işləyir. Bu davranış istiqamətdən asılılığı izah edir: əgər server əvvəlcə göndərirsə və paketi müştəriyə çatırsa, müştəri serverin cari ünvanını öyrənir və cavab verə bilir. O vaxta qədər onun göndərəcək yeri yoxdur. Mexanizm ilk istifadədə etimad qısayolundan deyil, autentifikasiya olunmuş rouminqdən ibarətdir, çünki paket son nöqtə dəyişməzdən əvvəl keçərli olmalı idi.

wg üçün alət sənədləri həmin yeniləməni təsvir edir və onun ətrafında dizayn quracaqsınızsa, bir dəfə oxumağa dəyər.

Vəziyyət saxlayan tərcümə öz istiqamətini əlavə edir

UDP tərcümə edən şlüzdən keçəndə şlüz gördüyü ilk paket üçün vəziyyət yaradır. RFC 4787 bu davranışı və xəritələnməni nəhayət silən taymautları təsvir edir. Boş xəritələnmənin vaxtı bitir və qarşı tərəfdən gələn daxil olan paket hosta çatmazdan əvvəl şlüz tərəfindən atılır. Bütün səhər işləyən tonel məhz bu səbəbdən günortadan sonra cavab verməyi dayandırır.

Bu, eyni istiqamət simptomunu doğuran ikinci və müstəqil mexanizmdir. Həm son nöqtə biliyi, həm tərcümə vəziyyəti düzgün olmalıdır və birini düzəltmək digərini düzəltmir.

Həqiqətən istədiyiniz istiqaməti konfiqurasiya edin

Bağlantını başlatmalı olan müştəri üçün serverin son nöqtəsini müştərinin peer bölməsinə qoyun və orada saxlayın. Serverin əvvəlcə göndərməsinə güvənmək sakit şəbəkədə dəyişəcək trafik sırası təsadüfünə güvənməkdir. Konfiqurasiya nəzərdə tutulan istiqaməti bildirməli, onu kəşf etməməlidir.

Tərcümənin arxasında qalmalı və əlçatan olmalı peer üçün həmin tərəfdə davamlı keepalive aktivləşdirin. Hər 25 saniyədən bir keepalive adi başlanğıc dəyəridir və məqsədi toneli sınamaq deyil, xəritələnməni açıq saxlamaqdır. Onu daşıyacaq bir tərəf seçin, çünki hər iki tərəfdə aktivləşdirmək nəticəni yaxşılaşdırmadan trafiki və jurnal səs-küyünü ikiqat artırır.

Vəziyyəti tetikdən əvvəl və sonra müqayisə edin

Uğursuzluq anında iki görüşü, sonra server göndərdikdən sonra yenidən çəkin. Birinci əmr son nöqtələri və handshake yaşını göstərir. İkincisi port üçün tərcümə qeydinin olub-olmadığını göstərir. Çəkiliş hansı istiqamətin həqiqətən naqildən keçdiyini göstərir və marşrut yoxlaması müştərinin bu trafiki tamam başqa yerə göndərmədiyini təsdiqləyir.

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

Son nöqtə sütununu və tərcümə qeydini birlikdə yazın. Son nöqtəsi olmayan peer ilə xəritələnməsi olmayan şlüz iki fərqli nasazlıqdır. Onlardan yalnız birini keepalive düzəldir.