Konfiqurasiya edə bilmədiyiniz NAT arxasındakı VPN: nə hələ də işləyir

Hər tunel son nöqtəsi qarşı tərəfin çata bildiyi ünvan və porta ehtiyac duyur, idarə etmədiyiniz marşrutlaşdırıcı isə bu tələbin uğursuz olmasının adi səbəbidir. Maraqlı hissə hiylələrin mövcud olması deyil, hər birinin müştəridən görə bilmədiyiniz xəritələmə cədvəlinin xassəsindən asılı olmasıdır. Bu xassələrdən ikisi demək olar ki, hər şeyə qərar verir: xəritələmənin necə yaradıldığı və daxilin heç vaxt əlaqə saxlamadığı ünvandan paket qəbul edib-etmədiyi. Mühiti bu xassələrə görə sıralayın və işlək həllər folklor olmaqdan çıxır.

Xəritələmə cədvəli hər şeyə qərar verir

Şəbəkə ünvanı çevrilməsi daxili ünvan və portun ictimai ünvan və porta qarşı qeyd olunduğu cədvəl saxlayır. Qeydə uyğun cavablar geri çevrilir, kənardan gələn və uyğun qeydi olmayan paketin isə heç bir təyinatı yoxdur. Bu tək davranış marşrutlaşdırıcının arxasındakı dinləyicinin internetdən niyə əlçatmaz olduğunu izah edir. Həm də hər istiqamətdə ilk paketin niyə daxildən başlamalı olduğunu izah edir.

Cədvələ marşrutlaşdırıcı tərəfindən baxın və həllər aydın olur: ya nəsə daimi qeyd yaradır, ya müvəqqəti qeyd yaradıb onu təzə saxlayır, ya da trafik heç vaxt o yolla getmir. Bu məqalənin qalan hissəsi həmin üç hal, sıra ilə. Burada heç nə cədvəlin qeyd etdiyindən kənar satıcı funksiyasından asılı deyil.

Görüşmə xidmətinin nə edə biləcəyi və nə edə bilmədiyi

UDP dəlik açma filtri məğlub etmək əvəzinə giden qeydi müvəqqəti açılış kimi istifadə edir. Hər iki həmkar görüşmə xidməti ilə əlaqə saxlayır; xidmət hər ictimai son nöqtəni öyrənir və qarşı tərəfin son nöqtəsini geri bildirir. Sonra hər ikisi bir-birinə doğru göndərir və hər giden paket cavabın içəri girməsinə imkan verən qeydi yaradır və ya təzələyir. Sıra onu işlədir, sıra həm də onu kövrək edir: qarşı tərəf qeydini yaratmadan göndərən həmkar sadəcə atılır, bir an sonra təkrar cəhd isə uğur qazanır. Xidmətin özü heç bir VPN trafiki daşımır, ona görə yeganə təsiri əlaqələndirdiyi vaxtlamadır.

Xəritələmə davranışı qalanı həll edir və RFC 4787 üç formanı adlandırır: son nöqtədən asılı olmayan, ünvandan asılı və ünvan və portdan asılı. Sonuncusunda həmkarın hədəf almalı olduğu port hər təyinatla dəyişir, buna görə proqnoz etibarlı olmaqdan çıxır. Texnika öz çıxılmaz nöqtəsinə burada çatır, çünki operator səviyyəli NAT və sərt korporativ firewall sxemin ehtiyac duyduğu proqnozlaşdırılanlığı birlikdə aradan qaldırır və heç bir təkrar cəhd onu geri qaytarmır.

Keepalive-lar, yenidən başlatmalar və yerini dəyişən son nöqtə

Dəlik açılmış yol dinləyici deyil, axındır, ona görə onun üzərində işləyən hər şey dəyişikliyə tab gətirməlidir. Xəritələməni dövri trafiklə canlı saxlamalı, ictimai son nöqtənin nə vaxt yerini dəyişdiyini görməli və marşrutlaşdırıcı yenidən başladıqdan ya ünvan yenidən təyin edildikdən sonra bərpa etməlidir. Mesh VPN məhsulları bu məntiqi öz idarəetmə müstəvisinə qoyur, adi server isə onu sizə buraxır. Keepalive-lar yalnız eyni xəritələmə qaldıqca kömək edir və mobil müştəridə batareya xərcləyir, buna görə aqressiv interval pulsuz deyil.

Bir saat yatan noutbuk adətən başqa ictimai son nöqtəyə qayıdır. Yolu bərpa edən hər şey yenidən daxildən işləməlidir, bu da eyni tələbi müştəriyə qaytarır.

Çatışmayan yönləndirmənin üç yolu

Birinci yol marşrutlaşdırıcıdan qeydi özünün yaratmasını xahiş edir, UPnP IGD, NAT-PMP və ya PCP vasitəsilə, funksiya varsa və açıqdırsa. İkinci yol trafiki ictimai ünvanı olan relay-ə verir, bu həmişə işləyir və həmişə bant genişliyi üstəgəl fərqli etimad sərhədi xərcləyir. Üçüncü yol istiqaməti tərsinə çevirir: daxili host ictimai serverə giden tunel açır və qalan hər şey onun içində gedir.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Relay son nöqtəsi bu mübadiləni müştəri konfiqurasiyasında görünən edir, burada son nöqtə həmkarın öz ünvanı deyil, relay-dir. Daimi keepalive xəritələməni isti saxlayır, icazə verilən prefikslər isə müştərinin onun üzərindən nə göndərə biləcəyini həll edir. Daxili hostdan tərs tunel başqa sahiblə eyni fikirdir və heç bir NAT dəyişikliyi tələb etmir. Üçü də daxil olan tələbi aradan qaldırır, lakin xahiş olunmayan trafiki dizaynla bloklayan firewall-u məğlub etmir, çünki trafik yenə daxildən başlayır.

İşlək həlli marşrutlaşdırıcının sahibinə uyğunlaşdırın

Marşrutlaşdırıcını idarə edirsinizsə, statik UDP yönləndirməsi hər hansı dəlik açma sxemindən daha asan yoxlanılır və gördüyünüz şəkildə uğursuz olur. Etmirsinizsə, satıcının relay və ya host edilmiş idarəetmə müstəvisi təklif edib-etmədiyini və siyasətin ondan istifadəyə icazə verib-verməyəcəyini öyrənin. Heç biri yoxdursa, qalan seçimlər tərs tunel və ya son nöqtənin kənardan əlçatmaz olduğunu qəbul etməkdir. Hansının istifadə edildiyini qeyd etmək göründüyündən daha vacibdir, çünki seçimlər trafiki kimin müşahidə edə bilməsi və üçüncü tərəf nəyisə dəyişəndə nə baş verməsi ilə fərqlənir.

Gəldiyiniz yolun birbaşa və ya relay vasitəsilə olduğunu qeyd edin, çünki bu tək fakt həm gecikməni, həm də uğursuzluq davranışını proqnozlaşdırır. RFC 4787 bütün bunların altındakı xəritələmə davranışı üçün istinad olaraq qalır və onun xəritələmə bölməsini oxumaq üç həlli ardıcıl sınamaqdan sürətlidir. Cədvəl hansı variantı seçdiyinizə əhəmiyyət vermir; o yalnız növbəti paketin nəyə icazəsi olduğunu qeyd edir.