proto udp, yoxsa tcp-client: serveriniz hansını eşidir?

Keçən ay işləyən profil indi vaxt aşımına düşür və kimsə proto udp parametrini proto tcp-client ilə əvəzləməyi təklif edir. Bəzən bu düzgün addımdır, bəzən isə heç kimin dinləmədiyi porta qoşulan müştəri yaradır, çünki server heç vaxt digər nəqliyyat üçün qurulmayıb. Direktiva sizin tərəfin necə danışdığını təsvir edir; o, qarşı tərəfdə dinləyici yarada bilməz. Hər ikisini dəyişməzdən əvvəl profili və serveri birlikdə oxuyun.

Seçilmiş bağlantının istifadə etdiyi nəqliyyatı oxuyun

Profil bir neçə remote girişi daşıya bilər və hər biri öz nəqliyyatını göstərə bilər. Müştəri onları sıra ilə işləyir, ona görə ilk gördüyünüz sətir mütləq tətbiq olunan sətir deyil.

Həqiqətən sınanan girişi tapın, sonra onun nəqliyyatını oxuyun. Sıra vacibdir, çünki müştəri səssizcə növbətiyə keçmir. Bəzi qurğular növbəti girişi yalnız vaxt aşımından sonra sınayır, ona görə faylın sonundakı işlək alternativə gözlədiyinizdən bir neçə saniyə gec çatılır. İlk sətrin qazandığını güman etmək əvəzinə, sınanan son nöqtəni jurnalda izləyin.

Faylda yuxarıda bir proto sətri və altında bir neçə remote girişi varsa, həmin sətir onu üstələməyən hər remote üçün standartdır. Standarta yerli düzəliş, öz nəqliyyatını göstərən remote girişi üçün heç nə etmir.

grep -nE '^(remote|proto)\b' client.ovpn

UDP və TCP sürət ayarı deyil

UDP sifarişli axın qurmadan veraqramlar göndərir, ona görə tunelin öz trafiki ikinci etibarlı nəqliyyatın içində bükülmür. TCP UDP-ni atan və ya bloklayan şəbəkələrdən keçən yol verir, amma iç-içə yenidən göndərmə itkili xətti daha pis hiss etdirə bilər.

Bu, universal reytinq deyil, əlçatanlıq mübadiləsidir. Düzgün seçim müştərinin qarşısındakı şəbəkənin icazə verdiyidir. VPN portunda UDP-ni atan yol heç vaxt razılaşmaya gəlməyəcək, profil nə qədər yaxşı yazılsa da. Yolu sınayın, sonra nəqliyyatı seçin.

Onları yalnız ölçmə nəticəsi ilə müqayisə etmək səhvdir, çünki cavab qarşınızdakı şəbəkənin nəyə icazə verdiyindən asılıdır. Otel və ya korporativ proksi 443 portunda yalnız çıxan TCP-yə icazə verə bilər, buna görə provayderlər bu variantı təklif edir. Bu, həmin portda OpenVPN bağlantısı olaraq qalır, HTTPS sessiyası deyil, hətta port nömrəsi tanış olsa da.

tcp-client əslində nə deməkdir

Müştəri tərəfindəki direktiva TCP bağlantısının başladan ucunu adlandırır. Server tərəfi öz dinləmə formasını işlədir və müştərinin sözünü server konfiqurasiyasına köçürmək, qoşulma gözləyən deyil, zəng gözləyən dinləyici yaradır.

Uyğunluq iki tərəfin nəqliyyatda razılaşması deməkdir, eyni sətri paylaşması deyil.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Profili səhv hesab etməzdən əvvəl serverdən nəyi dinlədiyini soruşun. UDP dinləyicisi TCP soket siyahısında görünmür və əksi də doğrudur, ona görə ümumi deyil, protokola xas görünüşü yoxlayın.

Profil idxal olunur, amma heç vaxt qoşulmur

Dərhal vaxt aşımına düşən idxal edilmiş profil adətən hər hansı autentifikasiyadan əvvəl uğursuz olur. Paket dinləyicisi olmayan porta gedir və ya şəbəkə onu səssizcə atır.

Yolu ən sadə şəkildə sınayın: uğursuz müştərinin olduğu şəbəkədən, profilin iddia etdiyi nəqliyyatla eyni host və porta qoşulun.

UDP yoxlaması heç nə almırsa və TCP yoxlaması qoşulursa, server digər nəqliyyatı təklif edir və profil sadəcə köhnəlib. Heç biri cavab vermirsə, problem nəqliyyat seçimindən yuxarıdadır və profilə heç bir düzəliş onu həll etməyəcək. Bu iki halı ayırd etmək bir dəqiqə çəkir və heç vaxt aidiyyəti olmayan sertifikat sazlamağından bir saat qənaət edir.

İşləyən nəqliyyatı qeyd edin

Birləşmə işlədikdə onu server, port və protokolla birlikdə yazın və hansı şəbəkədən sınandığını qeyd edin.

Əks halda vaxt aşımına düşən növbəti şəxs eyni təcrübəni əks istiqamətdə təkrarlayacaq və bəlkə də yaxşı işləyən serveri dəyişəcək.

Provayder hər iki variantı dərc edirsə, iki faylı da saxlayın və onları uyğun olduqları şəbəkəyə görə adlandırın. Aydın adlanmış iki profil müştəri nəqliyyatının heç vaxt onun üçün qurulmamış server dinləyicisi ilə təsadüfən qarışmasının qarşısını alır.