NAT vasitəsilə L2TP/IPsec: həqiqətdə nə pozulur və niyə

NAT-ın L2TP/IPsec-i pozduğu iddiası yarı doğrudur və buna görə faydasızdır. Ünvan çevrilməsi normaldır, NAT keçidi məhz ondan sağ çıxmaq üçün mövcuddur və milyonlarla müştəri hər gün routerin arxasından qoşulur. Pozulan şey konkret mübadilənin konkret mərhələsidir: IKE heç vaxt cavab almır, kapsüllənmiş tunel yalnız bir protokola icazə verən siyasətlə atılır və ya tunel boş qalarkən çevrilmə xəritəsi bitir. Hansı mərhələdə olduğunuzu bildikdən sonra düzəliş adətən yeni VPN dizaynı deyil, tək bir qayda və ya keepalive olur.

Mif səhv sualdır

Faydalı sual «NAT bunu pozurmu» deyil, «mübadilənin hansı hissəsi çevrilir və çevirməni edən cihaz onunla nə edir» sualıdır. L2TP/IPsec qatlı protokoldur: IKE danışıq aparır, ESP qoruyur və L2TP həmin qoruma daxilində PPP daşıyır. Ünvan çevrilməsi hər qatla fərqli qarşılıqlı təsir edir və uğursuzluq imzaları xəta pəncərəsinə deyil, danışıq mərhələsinə baxsanız ayırd edilə bilər.

Veb-səhifələri uğurla gəzən router yalnız mənbə portu çevrilməsi ilə TCP-nin işlədiyini sübut edir. UDP 500, UDP 4500 və ya 50 protokolu haqqında heç nə demir və bu yerləşdirmənin asılı olduğu üç şey məhz bunlardır.

Mərhələ 1: IKE ümumiyyətlə cavab almalıdır

İlk mübadilə UDP 500 üzərində cavab verənə gedir. Heç bir cavab qayıtmırsa, başqa heç nə əhəmiyyət kəsb etmir: əvvəlcədən paylaşılan açar, təklif və etimad məlumatları oxunmamış qalır. Müştərinin gözləmə müddətindən nəticə çıxarmaq əvəzinə sorğuya və cavaba baxın:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Cavabsız sorğu adətən firewall və ya yuxarı operatorun paketi atdığını bildirir, serverin onu rədd etdiyini deyil. Təklif və ya sertifikat problemini adlandıran bildiriş yükü ilə gələn cavab paketlərin çatdığını və danışığın məzmun üzündən uğursuz olduğunu bildirir ki, bu tamamilə başqa düzəlişdir.

Hər iki tərəf çevrilmənin arxasındadırsa, başladan yalnız cavab verənə çatmalıdır, buna görə müştəri tərəfindəki yerləşdirmələrin çoxu 1-ci mərhələdən işləyir. Server tərəfində hostinq daxil olan problemin başladığı yerdir və buna görə iki vəziyyət heç vaxt biri kimi müzakirə olunmamalıdır.

Mərhələ 2: kapsullama firewallun gördüyünü dəyişir

ESP TCP və ya UDP portu deyil, IP protokoludur və adi port ünvan çevrilməsinin içində yenidən yazacaq port sahəsi yoxdur. Buna görə NAT keçidi qorunan yükü UDP 4500-ə köçürür: kapsullama çevirən cihaza necə çevirəcəyini bildiyi bir şey verir. Bu baş verdikdən sonra yalnız UDP 500 üçün yazılmış firewall qaydası danışığa icazə verir və tuneli atır, bu da jurnalın uğurlu 1-ci fazanı və heç bir trafik göstərmədiyi qarışıq nəticə yaradır.

IKE mübadiləsinin özü də NAT aşkarlandıqdan sonra UDP 4500-ə keçə bilər ki, bu, yalnız 500-ə icazə verənləri təəccübləndirir. Yolda hər iki portu hər iki istiqamətdə açın və unutmayın ki, vəziyyət saxlayan firewall axını yalnız trafik gördükcə saxlaya bilər.

50 protokolu çevrilmə olmayan yollarda və ara qurğunun ona icazə verdiyi yollarda hələ də vacibdir. Əgər aradan qaldırma üsulu ilə diaqnostika edirsinizsə, qaydaları toplu əlavə etmək əvəzinə fərziyyəni söndürün: 500, 4500 və ESP-yə icazə verin, tunelin qalxdığını təsdiqləyin, sonra lazımsız çıxanı silin. Heç kimin izah edə bilmədiyi qayda, növbəti kəsintinin səbəbi olanda heç kimin silməyəcəyi qaydadır. Daralmanı düzəltdiyi mərhələ ilə birlikdə dəyişiklik qeydinə yazın ki, növbəti mühəndis eyni təcrübə qaydasından deyil, sizin sübutunuzdan başlasın.

Mərhələ 3: xəritə bitir və tunel ölür

Çevirən cihaz ötürdüyü axınlar üçün vəziyyət saxlayır və bu vəziyyətin ömrü var. L2TP/IPsec tuneli heç kim istifadə etmədikdə az trafik daşıyır, buna görə boş tunel xəritəsindən uzun yaşaya və geri trafik almağı dayandıra bilər. Müştəri qoşulduğuna əmin qalır, server heç nə görmür və ilk simptom adətən VPN xətası deyil, tətbiq gözləmə müddətidir.

Ölü peer aşkarlanması və NAT keepalive-ları bunun üçündür və hər iki tərəf onları göndərməyə hazır olmalıdır. Serveriniz çevrilmənin arxasındadırsa, Windows tərəfindəki tələb serverin öz çıxan paketləri üçün UDP kapsullamasını fərz etməsini təmin edən sənədləşdirilmiş registry parametridir; o olmadan cavab verən çevirən cihazın geri xəritələyə bilmədiyi ESP göndərir. Bu müştəri deyil, server konfiqurasiyası məsələsidir.

WAN ünvanının dəyişməsi eyni nəticəni başqa istiqamətdən verir: xəritə yeni ünvan ətrafında yenidən qurulur və köhnə təhlükəsizlik assosiasiyası artıq mövcud olmayan dəstəyə yönəlir. Yenidən qoşulma davranışı müştəri tətbiqinə aiddir, buna görə «router yenidən başladıqdan sonra qoşul» bir müştəridə işləyir, digərində əl ilə keçid tələb edir.

Operator səviyyəli NAT arxasında hostinq başqa problemdir

L2TP/IPsec serverini evdə hostinq etmək və kənardan ona çatmaq istəyirsinizsə, tələb olunmamış daxil olan əlçatanlıqdır və NAT keçidinin təqdim etdiyi bu deyil. Routerinizin qarşısında operator səviyyəli NAT olması o deməkdir ki, sizi əlçatan edəcək yönləndirə biləcəyiniz port yoxdur, çünki ümumi ünvan paylaşılır və xəritə yalnız çıxandır.

Heç bir IPsec keçirmə qeydi bunu dəyişmir və heç bir müştəri konfiqurasiyası bunu kompensasiya etmir. Dəstəklənən cavablar həqiqətən əlçatan ünvan, hostinq edilmiş son nöqtə və ya hər iştirakçının çıxan bağlantı qurduğu arxitekturadır. UDP kapsullama spesifikasiyası mövcud axınlar üçün çevrilmə problemini həll edir; operatorun təklif etmədiyi yerdə daxil olan yol yaratmır.

Buna görə təxmin etmək əvəzinə şəbəkələri müqayisə edin. Eyni cihazı və profili başqa icazəli şəbəkəyə aparın və orada hansı mərhələnin uğursuz olduğuna baxın. Başqa yerdə işləyirsə, fərq yoldadır və bu, axtarışı bütün konfiqurasiya yerinə yuxarıdakı üç mərhələyə daraldır.