OpenVPN evdə işləyir, amma bir şəbəkədə işləmir: UDP, yoxsa TCP?
Bir şəbəkə tuneli bloklayır, digəri yox. UDP filtrasiyasını, kommutatorun daşqın qorunmasını, TCP 443 ehtiyat variantını və ünvan planı toqquşmasını müqayisə edin.
Eyni profil evdən qoşulur və otel, kampus və ya filial şəbəkəsində dayanır. Etimad məlumatları dəyişməyib, deməli maraqlı dəyişən yoldur: paketlərə OpenVPN onları oxumazdan əvvəl nə baş verir. Dörd ehtimal səbəbi yoxlanıla biləcəkləri sıra ilə müqayisə etmək sertifikatlar barədə təxmin yürütməkdən yaxşıdır. Hər biri fərqli iz qoyur və iz onları ayıran şeydir.
Hansı mərhələnin uğursuz olduğu hansı müqayisənin vacib olduğunu deyir
Müştəri jurnalı artıq nə qədər irəlilədiyinizi qeyd edir. TLS açar razılaşmasının vaxt aşımı ərzində baş vermədiyini deyən sətir ilk paketin çıxdığını və geri heç bir yararlı şeyin gəlmədiyini bildirir, bu da yola işarə edir. Sertifikat rəddi tamam başqa görünür: cavab gəlir, sonra konkret yoxlama xətası səbəbi adlandırır. Təkrar cəhd dövrəsindən əvvəlki son sətri qeyd edin, çünki şəbəkələr arasında müqayisə etdiyiniz dəyər odur.
Təkrar cəhd edərkən çəkiliş aparın, sonra yox. Müştəridə tcpdump -ni any udp port 1194 ümumiyyətlə hər hansı cavabın qayıdıb-qayıtmadığını göstərir. Bunu nəzarət etdiyiniz serverin WAN interfeysində təkrarlayın; bu, həmin paketlərin ümumiyyətlə uzaq tərəfə çatıb-çatmadığını üzə çıxarır.
Birtərəfli trafik burada mövcud olan ən faydalı nəticədir, çünki aralıq şikayəti araşdırma istiqamətinə çevirir. Çəkiliş fayllarını saxlayın, çünki eyni problemin növbəti hesabatını təsvirlə deyil, sübutla bağlamaq daha asandır.
UDP filtrasiyası qapalı portla müqayisədə
Bir çox giriş şəbəkəsi davamlı UDP-ni şübhəli sayır və bəzi ISP-lər onlarla razılaşır. Qapalı port müştəri tərəfindən eyni səssizliyi yaradır. Fərq seçicilikdir: filtr hansı təyinatları və ya portları atdığına görə seçici olur, qapalı port isə həmin bir porta yönəlmiş hər şeyi rədd edir.
443 portunda TCP profili adi həlldir, çünki adi HTTPS axınına bənzəyir və əksər captive portal və çıxış filtrlərindən keçir. İki şərt yerinə yetməlidir. Server proto tcp-server ilə dinləməli, müştəri proto tcp-client ilə uyğunlaşmalı və operator həmin alternativ son nöqtəni dərc etməlidir. İşləyən UDP profilini TCP 443 iddiası ilə yenidən yazmaq, o biri tərəfdə heç kim dinləmədikdə heç yerə aparmır.
Qapalı port senzura problemi deyil, konfiqurasiya problemidir. Ev marşrutlaşdırıcısının arxasındakı server UDP portunun yönləndirilməsinə ehtiyac duyur və marşrutlaşdırıcının firewall-u buna icazə verməlidir. Porta heç vaxt icazə verilmədikdə hər müştəri etimad məlumatlarından asılı olmayaraq razılaşmada uğursuz olur və nasazlıq şəbəkəni deyil, serveri izləyir.
Köhnə protokollar bu oxda pis müqayisə olunur. PPTP TCP 1723 üstəgəl GRE tələb edir və GRE port deyil, IP protokolu 47-dir, ona görə heç bir adi port yönləndirməsi bunu ifadə etmir.
Paketləri kommutator atdıqda
İdarə olunan kommutator tuneli qəsdən ata bilər. Bəzi HPE və Aruba modelləri qabaqcıl təhlükəsizlik bölməsində UDP daşqın qorunması nəzarətini, bəzən Prevent UDP Blat Attack adı ilə, təqdim edir. Bu nəzarət aktiv olduqda kommutatorun arxasındakı server heç nə cavablandırmır və hər müştəri eyni şəkildə vaxt aşımına uğrayır. Onu söndürüb cari konfiqurasiyanı yadda saxlamaq bütün təmir işidir, ancaq kommutatorun həqiqətən yolda olduğunu müəyyən etdikdən sonra.
Əks sübut kommutator atmasını provayder blokundan ayıran şeydir. ISP ilə bilet açmazdan əvvəl interfeys sayğaclarını və daşqın qorunması jurnalını oxuyun. DoS və ya daşqın qoruması olan istehlakçı marşrutlaşdırıcıları eyni formada uğursuz olur, qısa UDP boşdayanma vaxtı olan hər hansı ara qurğu da belədir. Heç tamamlanmayan əl sıxışma atmağa işarə edir, bir neçə dəqiqə sükutdan sonra ölən tunel isə vaxt aşımına işarə edir.
Profili dəyişməzdən əvvəl müştəri ilə server arasındakı hər cihazı yazın. Yanlış qatda tətbiq olunan düzəliş növbəti şəbəkəyə qədər doğru görünür. Bu siyahı növbəti mühəndisə bütün araşdırmanı təkrarlamadan hara baxacağını da deyir.
DNS nasazlığına bənzəyən ünvan toqquşması
10.0.0.0/8 daxilində nömrələnmiş giriş şəbəkəsi tunel hovuzu ilə toqquşa bilər və həlledici adətən həmin hovuzun içində yaşayır. Noutbuk Wi-Fi-da /8 maskası ilə 10.184.178.50 kimi ünvan aldıqda hər 10.x təyinatı tərifə görə lokaldır. 10.4.0.1 üçün paketlər sonra LAN-a gedir, tunel açıq qalır və ad həlli uğursuz olur.
ip addr toqquşmanı bir baxışda üzə çıxarır və ip route get 10.4.0.1 paketin həqiqətən hara çatdırılacağını göstərir. Görünən simptom həlledici nasazlığı olduğu üçün bu, tez-tez bir neçə dövrə DNS dəyişikliyindən sağ çıxır.
Hovuzu yenidən nömrələyin və ya həmin giriş şəbəkəsini əhatə dairəsindən kənarda saxlayın. Heç bir müştəri tərəfi parametri toqquşmadan bərpa etmir.
TCP ehtiyat variantı ilə yol düzəlişi arasında qərar
Yola nəzarət etmədikdə və istifadəçilər bu gün işləməli olduqda TCP ehtiyat variantını seçin və xərclərini qəbul edin: TCP içində TCP itkili xətlərdə pis davranır və ehtiyat variant sizin idarə etdiyiniz dinləyici tələb edir. Blok sizə məxsus infrastrukturda olduqda yol düzəlişini seçin, çünki firewall qaydası ikinci dinləyicidən ucuzdur. Hər halda qatları sıra ilə işləyin: keçid, xarici nəqliyyat, razılaşma, daxili marşrutlaşdırma. Bu şəbəkədə uğursuz olan mərhələ vacib olan yeganə faktdır.
Nəticəni istifadəçi üzrə deyil, şəbəkə üzrə qeyd edin. Eyni nasazlığın növbəti hesabatı onda sertifikat nəzəriyyəsindən deyil, məlum mərhələdən başlayır. Bu qeyd həm də daimi ikinci dinləyicini, əgər bir gün lazım olsa, əsaslandıran şeydir.