VPN-dən ping: əks-səda cavab qaydaları dönüş yolunu niyə əldən verir

VPN üzərindən bir hosta ping göndərin: sorğu bir ICMP tipi ilə çıxır və başqa bir tipi ilə qayıdır; bu, portlar baxımından yazılmış istənilən qaydanı çaşdırmağa kifayətdir. Əks-səda mübadiləsində dönüş qaydasına köçürüləcək hədəf xidmət portu yoxdur və simmetriya gözləyən filtr sorğu maneəsiz keçərkən cavabı atacaq. Düzəliş paketi olduğu kimi oxumaqla, sonra yol boyunca hansı sərhədin qərar verdiyini müəyyən etməklə başlayır. Adətən iki qat işləyir, üçüncü qat isə cavabı səssizcə atır. Aşağıdakı bölmələr onları paketin onlarla rastlaşma sırası ilə ayırır.

Paket portu deyil, tipi dəyişir

Əks-səda sorğusu ICMP tip 8, kod 0-dır və identifikatorla ardıcıllıq nömrəsi daşıyır. Cavab tip 0, kod 0-dır, identifikator və ardıcıllıq eynidir, IP son nöqtələri isə dəyişdirilib. Bu sahələri RFC 792 müəyyən edir və göndərənin cavabları öz sorğuları ilə uyğunlaşdırmasına məhz identifikator imkan verir.

Çatışmayan da eyni dərəcədə vacibdir: TCP və ya UDP başlığı yoxdur, yəni icazə veriləcək port da yoxdur. Əks-səda cavabı üçün port adlandıran qayda heç vaxt mövcud olmayacaq paketi təsvir edir. Bu, VPN ping müraciətlərində ən çox rast gəlinən səhvdir. Qayda konkret görünür, heç bir şeyə aid edilmir və nasazlığı olduğu yerdə saxlayır.

Paket barədə üç kontekst qərar verir

Ping uzaq LAN-dakı hosta yönəlibsə, sorğu şlüz tərəfindən yönləndirilməlidir. Əgər hədəf şlüzün özünə aid ünvandırsa, o, yerli giriş yolunda sona çatır. Ping-i şlüz başladırsa, paket öz çıxış yolunda başlayır və yönləndirmə qərarını heç keçmir.

Bu üç kontekstin qayda zəncirləri və sayğacları fərqlidir; onları bir kimi qəbul etmək “firewall ICMP-yə icazə verir” ifadəsinin yenə də uğursuz ping verməsinin səbəbidir. Xarici tunel dördüncü kontekstdir: VPN dinləyicisinə icazə vermək dekaplə edilmiş daxili sorğuya avtomatik icazə vermir və daxili icazə xarici tunelin açıq olub-olmadığı barədə heç nə demir.

Vəziyyət saxlayan və saxlamayan filtrlər cavabı fərqli idarə edir

Sorğunun çıxdığını görən vəziyyət saxlayan firewall cavabı həmin axınla əlaqələndirib ikinci qayda olmadan buraxa bilər. Vəziyyət saxlamayan filtrdə belə yaddaş yoxdur, buna görə dönüş istiqaməti mənbə və hədəf dəyişdirilməklə öz açıq icazəsini tələb edir.

Heç nə yazmadan əvvəl məhsulun əslində hansı modeli tətbiq etdiyini yoxlayın. Əks-səda sorğusu üçün qayda mütləq əks-səda cavabını əhatə etmir və ICMP sorğularını izləyən məhsul başqa interfeysə gələn cavablara fərqli siyasət tətbiq edə bilər.

İcazə verdiyinizin əhatəsini müəyyənləşdirin. Hər yerdən gələn bütün əks-səda cavablarına icazə vermək vəziyyət əlaqələndirməsini tamamlamaqla eyni deyil və tip nömrəsi göndərəni doğrulamır.

Tərcümə identifikatoru da dəyişir

Mənbə tərcüməsi qəsdən edilibsə, uzaq tərəfdəki dəst müştərinin göndərdiyi ilə uyğun gəlmir. NAT ICMP sorğu identifikatorunu ünvanlarla birlikdə tərcümə edə bilər, buna görə hər iki tərəfdə eyni nömrənin görünməsində israr etmək yalançı uyğunsuzluq yaradır.

Əvəzində tərcüməçinin bildirdiyi uyğunluğu əlaqələndirin. İdentifikatoru yenidən yazan tərcüməçi müştərinizin qeyd etdiyi nömrəni saxlamayacaq, buna görə kimliyi nömrə deyil, uyğunluq kimi qəbul edin. Sonra bir identifikasiya edilə bilən sorğunu yol boyunca izləyin: onun hədəfə gözlənilən mənbə ilə çatdığını təsdiqləyin, hədəfin cavab göndərdiyini təsdiqləyin, həmin cavabın geri dönüş marşrutunu izləyin, və müştərinin onu aldığını təsdiqləyin, sadəcə şlüz sayğacının artmasını izləməklə kifayətlənməyin.

ICMP xətalarını əks-səda siyasətinə qatmayın

Yol MTU kəşfi üçün istifadə edilən “parçalanma tələb olunur” mesajı əks-səda cavabı deyil və onun yükü həmin mesajı tetikləyən paketi sitat gətirir. Bu xətaları səssizcə atan yalnız-əks-səda icazəsi ölçü problemini asılı qalan bağlantıya çevirir ki, bu da faydalının əksidir.

Eyni ehtiyat ünvan ailələrinə də aiddir. ICMPv6 fərqli mesaj tiplərindən istifadə edir və IPv4-də olmayan vacib funksiyaları daşıyır, buna görə bu nömrələri IPv6 qaydasına köçürmək sadəcə yanlışdır.

Əks-səda mübadiləsi işləyəndə real tətbiqi ayrıca yoxlayın. Uğurlu ping bir protokolun bir ölçüdə bir hədəfə gediş-dönüşünü sübut edir və HTTPS, SMB və ya hər hansı digər axına icazə verildiyini güman etmək üçün lisenziya deyil.