Hairpin NAT: VPN son nöqtəsi niyə içəridən işləmir

Mobil şəbəkədən cavab verən, amma divandan işləməyən VPN serveri adətən sertifikat problemi deyil. LAN daxilindəki müştəri marşrutlaşdırıcıdan təyinatı marşrutlaşdırıcının öz ümumi ünvanı olan paketi çevirməsini xahiş edir, yəni paket çıxıb dərhal geri qayıtmalıdır. Bu manevr hairpinning adlanır və bir çox marşrutlaşdırıcı ya onu ümumiyyətlə tətbiq etmir, ya da yalnız bir onay qutusu aktivləşdirildikdə tətbiq edir. Xarici testin keçməsi məhz bunu qarışıq edir, çünki dinləyicinin və yönləndirmə qaydasının qaydasında olduğunu sübut edir.

Paket çıxır və geri qayıdır

Paketi izləyin. Müştəri ümumi adı həll edir, ümumi ünvana qoşulur və marşrutlaşdırıcının təyinat NAT-ı təyinatı daxili serverə yenidən yazır. Serverdən gələn cavab müştərinin LAN ünvanına ünvanlanıb, ona görə də mənbəni geri çevirəcək NAT qaydasından heç keçmədən marşrutlaşdırıcının LAN interfeysindən geri qayıdır.

İndi müştəri heç vaxt heç nə göndərmədiyi ünvandan paket alır və onu atır. Bütün nasazlıq bu asimmetriyadır.

RFC 4787 bu halda NAT-ın gözlənilən davranışını təsvir edir və qısa versiya budur ki, nəzəri olaraq müəyyən edilsə də praktikada bu opsionaldır. Bəzi marşrutlaşdırıcılar parametri NAT loopback, bəziləri hairpin NAT və ya NAT reflection adlandırır, bəziləri isə heç nə göstərmir. Bu funksiyası olmayan marşrutlaşdırıcı səhv konfiqurasiya edilməyib; o, adi işi görür və düzəliş başqa yerdədir. Yerli testin uğursuzluğundan ümumi yönləndirmə qaydasının səhv olduğu nəticəsini çıxarmayın.

Yoxlama 1: iki yolu ayrı-ayrılıqda yoxlayın

LAN-dan kənarda real istifadəçinin istifadə edəcəyi eyni profillə qoşulun və sessiyanın qurulduğunu təsdiqləyin. İçəridən eyni profillə ümumi ünvana qoşulun və dəqiq xətanı və vaxtı qeyd edin.

Dəqiq yerli test host adını saxlayır və yalnız ünvanı əvəz edir: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ sorğunu ümumi ünvana göndərir, eyni zamanda düzgün server adını təqdim edir. Bu, ad həlli problemini çevirmə probleminə qarışmaqdan ayırır; eyni ad kafedən işləyəndə ikisini qarışdırmaq asandır. Müştərinin TCP qoşulmasında, yoxsa sonra TLS-də uğursuz olduğunu qeyd edin, çünki birinci çevirməyə, ikinci şəxsiyyətə işarə edir.

Yoxlama 2: serverin nə gördüyünü oxuyun

Ən faydalı müşahidə serverin görünüşüdür. VPN hostunda müştərinin LAN ünvanına və marşrutlaşdırıcının LAN ünvanına filtrlənmiş tutma işə salın, sonra yerli cəhdi təkrarlayın. Heç nə gəlmirsə, paket çevirmədən sağ çıxmayıb.

Əgər bağlantı müştərinin ünvanından deyil, marşrutlaşdırıcının LAN ünvanından gəlirsə, hairpinning baş verir və mənbə yenidən yazılıb. Bu işləyən konfiqurasiyadır, nasazlıq deyil.

Yoxlama 3: xarici yola toxunmadan düzəldin

Üç dəstəklənən forma var, təsir radiusu artan sıra ilə. Ən darı bölünmüş DNS-dir: daxili qeyd yayımlayın ki, eyni server adı LAN-dakı müştərilər üçün daxili ünvana həll olunsun və ümumi yoldan tamamilə yayınılsın. Növbəti, marşrutlaşdırıcının sənədləşdirilmiş loopback və ya reflection parametrini, əgər varsa, aktivləşdirmək və yalnız bu xidmətə tətbiq etməkdir. Ən genişi marşrutlaşdırıcıda mənbə-NAT qaydasıdır ki, LAN-dan gələn trafiki serverə yenidən yazır və cavab marşrutlaşdırıcıdan geri qayıdır; Linux marşrutlaşdırıcısında bu, MASQUERADE qaydasıdır və POSTROUTING zəncirində serverin ünvanına və portuna uyğun gəlir. Hamısı xarici yolu toxunulmaz saxlayır və bu, qorunmalı olan xassədir.

Əlaqəsiz port yönləndirməsini yerli yolu xarici yola bənzətmək üçün genişləndirməyin və problemi yayınmaq üçün xidməti başqa porta köçürməyin. Hər iki dəyişiklik yalnız daxili dünyanın gördüyü bir şeyi düzəltmək üçün xarici dünyanın çata bildiyini dəyişir.

Bölünmüş DNS-in ad çəkməyə dəyər bir tələsi var. Host adını ixtiyari IP ilə əvəz etmək müştərinin yoxladığını dəyişir, ona görə daxili qeyd hələ də sertifikatın adına uyğun olmalıdır.

Yoxlama 4: sonra hər iki yolu yoxlayın

Xarici cəhdi LAN-dan kənarda təkrarlayın, daxili cəhdi eyni profillə təkrarlayın və server jurnalının bir uğur və bir sükut deyil, iki ayrı uğurlu sessiya göstərdiyini təsdiqləyin. Sonra digər müştərilərin hələ də dinləyiciyə çatdığını və şəxsi resurslara marşrutların dəyişmədiyini yoxlayın.

Qeydi qısa saxlayın: hər müştəri hansı ünvandan istifadə etdi, server nə gördü və üç düzəlişdən hansı tətbiq olundu. RFC 4787 hairpinning tələbləri burada NAT-dan gözlənilənlərin istinadıdır və bu funksiya olmayan marşrutlaşdırıcının niyə normal davrandığını izah edir. Xarici dünyanın təkrar edə bilmədiyi yerli uğursuzluq, əksi sübut olunana qədər bir çevirmə sualıdır, ona görə onu belə sınaqdan keçirin.