NAT arxasındakı iş stansiyasına port yönləndirmədən çıxış
Daxil olan portu olmayan iş stansiyasına hub, relay və ya tətbiq brokeri vasitəsilə çıxmaq mümkündür. Birini seçməzdən əvvəl hər dizaynın nəyə zəmanət verdiyini müqayisə edin.
Operator NAT-ının arxasındakı iki son nöqtə və bağlı ofis marşrutlaşdırıcısı yönləndirmə üçün heç bir daxil olan port qoymur, refleks isə yenə də onu istəməkdir. Daha yaxşı sual hansı tərəfin xaricə zəng edə bildiyidir və hansı əlçatan xidmətə trafiki daşımağa icazə verildiyidir. Dörd dizayn bu suala fərqli cavab verir və yol bağlandıqda fərqli şəkildə uğursuz olur. Aralarında seçim etmək protokol adlarının deyil, zəmanətlərin müqayisəsidir.
Dörd dizayn, dörd fərqli vəd
Aşağıdakı cədvəl qısa versiyadır. Orta sütunu sınaya biləcəyiniz vəd kimi, sağ sütunu isə heç kimin vermədiyi vəd kimi oxuyun.
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
Hansı sətrin tətbiq olunduğu seçimdən deyil, tapşırıqdan asılıdır. Bir uzaqdan iş masası sessiyası, bir inzibati shell və bütöv bir şəxsi alt şəbəkəyə çıxış eyni maşina ilə bağlı olsalar belə, eyni giriş nöqtəsinə ehtiyacı olmayan üç tələbdir.
Hub kimin xaricə zəng etdiyini dəyişir, nəyə icazə verildiyini yox
Marşrutlaşdırılmış hub dizaynında uzaq noutbuk və iş stansiyası, ya da onların qarşısındakı sayt şlüzü hər ikisinin çıxa bildiyi xidmətə gedən xarici tunel açır. İş stansiyasının marşrutlaşdırıcısında heç nə sorğusuz bağlantı qəbul etmir; bu dizaynın NAT-dan sağ çıxmasının və saytın statik ünvanı olmadıqda da işləməsinin səbəbi məhz budur. Sonra hub iki daxili ünvan arasında trafiki öz siyasətinə uyğun yönləndirir.
Qiyməti budur ki, hub mövcud olmalı, hər iki tərəfdən əlçatan olmalı və kiminsə onu idarə etməsi lazımdır. Xarici filtrləmə nəqliyyata icazə verməlidir və onu bloklayan şəbəkə port yönləndirməsinə ehtiyac olmasa da dizaynı puça çıxaracaq.
İncə məqam odur ki, əlçatanlıq və icazəvermə fərqli yerlərdə verilən ayrı qərarlardır. Prefiksə gedən marşrut şəxsiyyətin iş stansiyasında hansı xidmətdən istifadə edə biləcəyi barədə heç nə demir, tunelə icazə verən qoruyucu divar qaydası isə hesabın daxil ola bilməsi barədə heç nə demir. Hər ikisini konfiqurasiya edin, hər ikisini sınayın və icazə qərarını marşrutlaşdırma cədvəlində deyil, resursa sahib olan sistemdə saxlayın.
Keçid yalnız hər iki stek onu tətbiq etdikdə işləyir
Peer keçidi müəyyən bir sistemin imkanıdır, VPN-i yaxşılaşdıran parametr deyil. Interactive Connectivity Establishment bir neçə namizəd ünvan toplayır və cütləri biri işləyənə qədər sınayır: yerli interfeyslərdə host namizədləri, NAT-ın açdığı məlumatdan qurulan server-refleksiv namizədlər və relay üzərində ayrılan relay namizədləri. Şəxsi ünvan təkbaşına yol deyil, çünki qarşı tərəf ora marşrut ola bilməz.
Relay halını rədd etməzdən əvvəl anlamağa dəyər. RFC 8656 TURN-ü elə protokol kimi təsvir edir ki, müştəri serverdən relay edilən nəqliyyat ünvanı istəyir və server həmin müştəri ilə onun peer-ləri arasında trafiki yönləndirir. Deməli data-nı relay daşıyır və bu, yalnız son nöqtələrin görüşməsinə kömək edən kataloqdan əsaslı şəkildə fərqlənir. Relay ünvanını peer ilə dəyişmək tətbiqin yerinə yetirməli olduğu koordinasiya addımıdır.
Vəd edə bilmədiyiniz şey birbaşa yoldur. Simmetrik NAT və bəzi korporativ qoruyucu divarlar deşik açmağı puça çıxarır və bu olduqda sistem ya relay-ə keçir, ya da uğursuz olur. Həm də belə nəticə çıxara bilməzsiniz ki, iki çevrilmiş son nöqtə heç vaxt danışa bilməz; relay ehtiyatı olan dəstəklənən stek məhz ona görə mövcuddur ki, onlar çox vaxt danışa bilir. Əlçatanlığın, yoxsa birbaşalığın daha vacib olduğunu qərarlaşdırın, sonra xoşbəxt halı fərz etmək yerinə yerləşdirmənin faktiki hansı yolu seçdiyini yoxlayın.
Broker şəbəkədən daha dardır
Tələb bir tətbiq olduqda, tətbiq brokeri və ya iş stansiyasının başlatdığı tərs bağlantı ən kiçik cavab ola bilər. İş stansiyası brokerə xaricə zəng edir, broker uzaq istifadəçini doğrular və yalnız həmin tətbiq sessiyası daşınır. İş stansiyasının alt şəbəkəsinə marşrut yaranmır, ona görə uzaq sessiyanın kompromisi yanındakı hər cihaza gedən yolu miras almır.
Bu darlığın qiyməti var: hər əlavə tətbiq öz inteqrasiyasını tələb edir və tətbiqin yerli şəbəkə barədə fərz etdiyi şeylər, məsələn yaxın serverdə açdığı fayl paylaşımı, əlçatan olmaya bilər. Brokerlər həm də siyasəti və jurnalı bir yerdə cəmləyir, bu da o yer kəsinti olana qədər faydalıdır.
Etibar sərhədlərini müqayisə edin, sonra yolu sınayın
Tunelləri sonlandıran hub yönləndirdiyi trafiki oxuya bilər. Tətbiq ucdan uca şifrələdikdə relay ayrıca qorunan mübadiləni daşıya bilər, broker isə adətən təqdim etdiyi sessiyanı sonlandırır. İki dizaynın hər ikisi şifrəli olduğu üçün ekvivalent olduğuna qərar verməzdən əvvəl müdafiənin həqiqətən harada bitdiyini müəyyən edin.
Sonra iş stansiyasının xaricə faktiki nəyə çata bildiyini yoxlayın, çünki yuxarıdakı hər dizayn bundan asılıdır. İstifadə etmək istədiyiniz host adını əvəz edərək bunu iş stansiyasında icra edin.
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comDizaynı yalnız nəzərdə tutulan uzaq əməliyyat icazəli şəxsiyyət altında uğurla başa çatdıqdan, icazəsiz şəxsiyyət rədd edildikdən və birbaşa və ya relay yolu mövcud olmadıqda davranış bilinib sənədləşdirildikdən sonra qəbul edin. Yenidən qoşulmanı və iş stansiyasının normal başlama kontekstini də daxil edin, çünki ofisdə LAN üzərindən başlayan sessiya uzaq çıxışın asılı olduğu heç nəyi sınamır.