Saytlararası VPN cavabı tuneldən keçmir

Bir səhəri təmiz qalxan və trafiki yalnız bir istiqamətdə daşıyan tunelə sərf etdim: filial baş ofisdəki fayl serverinə çatırdı, baş ofisdən filiala açılan hər bağlantı isə ilk SYN-də ölürdü. SA-lar aktiv idi, tunel sayğacları artırdı və əl sıxma heç vaxt problem deyildi. Cavab tunelin əhatə etmədiyi bir yerə yönləndirilirdi və bu seçim uzaq tərəfə aiddir. Saytdan-sayta VPN yalnız hostun şlüzə verdiyi paketləri daşıyır və hər host bu seçimi ayrıca, hər istiqamətdə, öz marşrut cədvəlindən edir.

Hər iki istiqamət ayrı-ayrı yönləndirilir

IP söhbətin istiqaməti barədə heç bir yaddaş saxlamır. Paket göndərən hər host öz ən uzun prefiks axtarışını aparır, bir növbəti hop seçir və qərarı unudur. Sorğu və cavab eyni bağlantıya təsadüfən aid olan iki əlaqəsiz paketdir və tunel onlardan hər birinin istifadə edə biləcəyi və ya etməyə biləcəyi bir hopdur. IKE mübadiləsində heç nə uzaq serverə sizin alt şəbəkənizə necə çatacağını öyrətmir; razılaşma yalnız hansı prefikslərin şifrələnə biləcəyini qəbul edir.

Bu razılaşma ikinci qapıdır. strongSwan-da trafik selektorları leftsubnet və rightsubnet-dir və mənbəyi və ya təyinatı razılaşdırılmış cütdən kənara düşən paket şifrələnmir, marşrut cədvəli nə deyirsə desin. Tunelə yönləndirilən, lakin selektorlarda olmayan prefiks sakit birtərəfli nasazlıqdır: marşrut doğru görünür, paket yenə açıq şəkildə çıxır və ya atılır və yalnız charon jurnalı şikayət edir.

Uzaq host tuneliniz barədə heç nə bilmir

Uzaq LAN daxilində cavab müştərinizə ünvanlanmış adi paketdir. Təyinat hostu heç bir IPsec başlığı görmür və VPN şlüzünə üstünlük vermək üçün heç bir səbəbi yoxdur; prefiksinizə baxır, defolt marşrutundan daha dəqiq heç nə tapmır və onu izləyir. Əgər defolt əsas firewall-a işarə edirsə, firewall-un ya tunelə geri marşrutu var, ya yoxdur. Olmadıqda sükutla atılma, ICMP əlçatmazlığı və ya internetə baxan interfeysdən çıxıb ölən cavab alırsınız.

Marşrut mövcud olsa belə, ikinci interfeys bunu pozmağa kifayətdir. Digər VLAN-da idarəetmə linki olan NAS, ehtiyat uplink-i olan server, bir mənbə aralığını ikinci cədvələ göndərən siyasət qaydası: bunlardan hər hansı cavabı tuta bilər. Linux-da ip rule show və ip route show table all defolt siyahının gizlətdiyi qaydaları və cədvəlləri göstərir.

Qərarı cavabı göndərən qutuda oxuyun

Heç nəyi dəyişməzdən əvvəl kerneldən soruşun və ona mənbə ünvanını verin, çünki mənbədən asılı qaydalar cavabı dəyişir.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Çıxış çıxan interfeysi və növbəti hopu göstərir. Əgər interfeys VPN şlüzünə baxan interfeys deyilsə, nasazlığı tapmısınız və qalan iş marşrutun hara aid olduğunu seçməkdir. Şlüzdən edilən ping burada az şey sübut edir: o, uzaq hostun yerləşdirə biləcəyi bir ünvanla cavab verir, noutbukunuzun ünvanı ilə deyil.

Windows-da ekvivalentlər qərar üçün Find-NetRoute -RemoteIPAddress 10.10.5.10 və cədvəl üçün Get-NetRoute-dir. Defoltdan daha yüksək metrika daşıyan New-NetRoute ilə əlavə edilmiş marşrut sükutla uduzur, ona görə metrika sütununu oxuyun, girişi deyil. Sonra paketlərlə təsdiqləyin: uzaq LAN interfeysində tcpdump -ni any "host 10.10.5.10 and tcp port 445" sorğunu göstərir və tunel tərəfində eyni filtr cavabın qayıdıb-qayıtmadığını göstərir. Sorğu görünür, cavab yoxdur — deməli cavab başqa yerə yönləndirilib və ya atılıb; yanlış interfeysdə cavab isə marşruta toxunmazdan əvvəl günahkarı verir.

Server şlüzü VPN son nöqtəsi olmadıqda

Bir çox sayt serverlərlə konsentrator arasında firewall qoyur. Bu firewall cavabı yönləndirir, ona görə müştəri prefiksiniz üçün VPN şlüzünə işarə edən marşruta və hər iki istiqamətdə yönləndirmə siyasətinə ehtiyacı var. Vəziyyət saxlayan cihazlar işi pisləşdirir: sorğu firewall-u icazə verdiyi LAN hostundan keçib, cavab indi başqa istiqamətdən gəlir və bağlantı izləmə qeydi artıq uyğun gəlmir, ona görə paket rədd edilmək əvəzinə etibarsız kimi atılır. Siyasət jurnalının boş görünməsi, trafik isə yoxa çıxması buna görədir.

Şlüzün özünün ikinci filtri var. Linux-un tərs yol filtri mənbəyi gəldiyi interfeysdən əlçatan olmayan paketləri atır və bu, qanuni asimmetrik qayıdış yolunun tam formasıdır. strongSwan yönləndirmə təlimatı bu səbəbdən net.ipv4.ip_forward və yumşaldılmış net.ipv4.conf.all.rp_filter tələb edir. Hər iki şlüzdə sərt 1 dəyəri düzgün marşrutu sükutla pozur və nstat -az hara baxacağınızı bilirsinizsə atmaları göstərir.

Marşrutlaşdırın və ya tərcümə edin, sonra hər iki istiqamətdə yoxlayın

İki düzəliş ekvivalent deyil. Marşrut əlavə etmək müştəri ünvanını toxunulmaz saxlayır, ona görə mənbəyə əsaslanan qaydalar, audit jurnalları və zəng edəni qeyd edən tətbiqlər işləməyə davam edir; qiyməti isə qərarı verən hər hopun marşruta ehtiyacı olmasıdır, yəni səhv ola biləcək daha çox yer. Uzaq şlüzdə maskarad qayıdış yolunu bir hopa yığır, çünki cavab indi şlüzün özünə ünvanlanır və hansı müştərinin nə etdiyini gizlədir.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Onu qəsdən seçin: müştərilər şlüz ünvanı kimi görünməyə başlayanda, mənbəyə əsaslanan ACL-lər onları bir-birindən ayırmağı dayandırır və cavabın tunelə geri yazılması üçün conntrack xəritələməni saxlamalıdır. Əgər selektorlar hələ də müştəri prefiksini istisna edirsə, NAT heç nəyi dəyişmir, çünki sorğu tunelə heç vaxt girməyib.

Düzəldildi deməzdən əvvəl dörd şeyi sıra ilə təsdiqləyin: cavabı göndərən hostdakı marşrut, onu yönləndirən hər hopdakı marşrut, hər iki prefiksi əhatə edən selektorlar və cavabın gözlədiyiniz mənbə ilə tunelə girdiyini göstərən çəkiliş. Sonra testi digər saytdan təkrarlayın. Bir istiqamətin keçməsi yarım-açıq dizayndır və ikinci istiqamət adətən indicə düzəltdiyinizdən fərqli səbəbdən uğursuz olur.