Ping printr-un VPN: de ce regulile pentru răspunsul echo ratează calea de întoarcere

Trimiteți ping către un host printr-un VPN și cererea pleacă cu un tip ICMP și se întoarce cu altul, ceea ce este suficient pentru a încurca orice regulă scrisă în termeni de porturi. Într-un schimb echo nu există niciun port de serviciu destinație care să fie copiat în regula de întoarcere, iar un filtru care așteaptă simetrie va arunca răspunsul în timp ce cererea trece fără obstacole. Corectarea începe prin a citi pachetul așa cum este în realitate, apoi prin a decide care graniță de pe traseu ia decizia. De obicei lucrează două straturi în timp ce al treilea aruncă răspunsul în tăcere. Secțiunile de mai jos le separă în ordinea în care un pachet le întâlnește.

Pachetul schimbă tipul, nu portul

O cerere echo este ICMP tip 8, cod 0, și poartă un identificator și un număr de secvență. Răspunsul este tip 0, cod 0, cu același identificator și aceeași secvență, iar capetele IP sunt schimbate. RFC 792 definește aceste câmpuri, iar identificatorul este cel care îi permite unui expeditor să potrivească răspunsurile cu propriile cereri.

Ce lipsește este la fel de important: nu există antet TCP sau UDP, deci nu există niciun port de permis. O regulă care numește un port pentru un răspuns echo descrie un pachet care nu va exista niciodată. Aceasta este cea mai frecventă greșeală în tichetele ping prin VPN. Regula pare specifică, nu se aplică la nimic și lasă defecțiunea exact acolo unde era.

Trei contexte decid pachetul

Dacă pingul vizează un host din LAN-ul îndepărtat, cererea trebuie transmisă mai departe de gateway. Dacă vizează o adresă care aparține gateway-ului însuși, se termină în calea de intrare locală. Dacă gateway-ul inițiază el însuși pingul, pachetul începe în propria cale de ieșire și nu traversează deloc decizia de forwarding.

Aceste trei contexte au lanțuri de reguli și contoare diferite, iar tratarea lor ca unul singur este motivul pentru care „firewall-ul permite ICMP” poate produce totuși un ping eșuat. Tunelul exterior este un al patrulea context: permiterea ascultătorului VPN nu permite automat cererea internă decapsulată, iar o permisiune internă nu spune nimic despre dacă tunelul exterior este activ.

Filtrele cu stare și fără stare tratează răspunsul diferit

Un firewall cu stare care a văzut cererea plecând poate asocia răspunsul cu acel flux și îl poate admite fără o a doua regulă. Un filtru fără stare nu are o astfel de memorie, așa că direcția de întoarcere are nevoie de propria permisiune explicită, cu sursa și destinația inversate.

Verificați ce model implementează de fapt produsul înainte de a scrie ceva. O regulă pentru cererea echo nu acoperă neapărat răspunsul echo, iar un produs care urmărește interogări ICMP poate aplica totuși o altă politică răspunsurilor care sosesc pe altă interfață.

Limitați ceea ce permiteți. Permiterea fiecărui răspuns echo de oriunde nu este același lucru cu finalizarea unei asocieri cu stare, iar un număr de tip nu autentifică expeditorul.

Traducerea schimbă și identificatorul

Dacă traducerea sursei este intenționată, tuplul de la capătul îndepărtat nu corespunde celui trimis de client. Un NAT poate traduce identificatorul interogării ICMP împreună cu adresele, așa că insistarea ca același număr să apară pe ambele părți produce o nepotrivire falsă.

În schimb, corelați maparea pe care o raportează traducătorul. Un traducător care rescrie identificatorul nu va păstra numărul pe care clientul dumneavoastră l-a înregistrat, așa că tratați maparea ca identitate, nu numărul. Apoi urmăriți o cerere identificabilă de-a lungul traseului: confirmați că ajunge la destinație cu sursa așteptată, confirmați că destinația a emis un răspuns, urmăriți ruta acelui răspuns înapoi, și confirmați că clientul l-a primit, în loc să priviți doar cum crește un contor al gateway-ului.

Nu includeți erorile ICMP în politica echo

Mesajul „este nevoie de fragmentare” folosit de descoperirea MTU a traseului nu este un răspuns echo, iar conținutul său citează pachetul care l-a declanșat. O permisiune doar pentru echo care aruncă în tăcere acele erori transformă o problemă de dimensiune într-o conexiune blocată, ceea ce este opusul a ceva util.

Aceeași prudență se aplică și familiilor de adrese. ICMPv6 folosește alte tipuri de mesaje și transportă funcții esențiale pe care IPv4 nu le are, așa că a copia aceste numere într-o regulă IPv6 este pur și simplu greșit.

Când schimbul echo funcționează, testați aplicația reală separat. Un ping reușit dovedește dus-întorsul unui protocol, la o dimensiune și către o destinație, și nu este o licență pentru a presupune că HTTPS, SMB sau orice alt flux este permis.