Ce porturi VPN să deschizi într-un firewall: protocol cu protocol

Două reguli separate decid dacă un tunel VPN supraviețuiește unui firewall: portul pe care apelează clientul și protocolul care transportă încărcătura. Deschide doar prima și tunelul se autentifică, dar apoi nu mai mută date. Minimul este un port TCP plus GRE pentru PPTP, două porturi UDP plus ESP pentru L2TP/IPsec și IKEv2, și un singur port pentru SSTP, OpenVPN și WireGuard. Direcția, urmărirea stării și NAT decid restul.

Începe cu portul pe care apelează clientul

Fiecare familie are un punct de intrare pe care clientul îl contactează primul, iar acel punct de intrare este cel pe care trebuie să îl numească regula ta de permisiune. Clienții PPTP se conectează la TCP 1723. L2TP/IPsec pornește IKE pe UDP 500 și trece pe UDP 4500 când se folosește traversarea NAT, iar cadrul L2TP propriu-zis stă pe UDP 1701 în interiorul tunelului. SSTP înfășoară sesiunea în TLS pe TCP 443, IKEv2 negociază pe UDP 500 și 4500, OpenVPN folosește implicit UDP 1194 dar este mutat adesea pe TCP 443, iar WireGuard ascultă pe UDP 51820.

Tratează aceste numere ca valori implicite, nu ca proprietăți fixe. O interfață WireGuard folosește orice port de ascultare declarat de configurația ei, iar un server OpenVPN poate sta pe orice port ales de administrator. Citește configurația serverului înainte de a scrie regula, pentru că un firewall deschis pentru 1194 nu face nimic pentru un server mutat pe 443.

A treia coloană este locul unde majoritatea tichetelor de modificare merg greșit. Regula există, dar indică o destinație greșită, o direcție greșită sau un transport greșit.

GRE și ESP sunt numere de protocol, nu porturi

GRE și ESP nu au niciun port, așa că un formular de firewall care acceptă doar numere de port nu le poate exprima. GRE este protocolul IP 47, iar ESP este protocolul IP 50, ambele potrivite prin câmpul de protocol din antetul IP. O regulă scrisă ca port TCP 47 nu se potrivește cu nimic, și astfel o politică PPTP pare corectă și totuși aruncă fiecare pachet după strângerea de mână.

Routerele de consum ascund asta în spatele unei casete de trecere care instalează regula de protocol și, pentru GRE, ajutorul NAT necesar pentru maparea fluxului. Pe un firewall real adaugi protocolul singur: permite protocolul IP 47 către serverul PPTP, permite protocolul IP 50 către poarta IPsec. Unde platforma nu oferă câmp de protocol, încapsularea este soluția, de aceea IKEv2 poate reveni la UDP 4500 și de aceea OpenVPN și WireGuard nu întâlnesc niciodată problema.

Verifică ce potrivește regula de fapt înainte să dai vina pe client. Un contor de pachete care rămâne pe zero la poartă spune că regula nu s-a declanșat niciodată, iar nicio reinstalare de partea clientului nu schimbă asta.

Direcția, starea și NAT schimbă răspunsul

Un client care apelează spre exterior și o poartă care ascultă spre interior sunt cerințe diferite, iar aceeași listă de porturi poate fi corectă într-o direcție și greșită în cealaltă. Un firewall cu stare urmărește fluxul UDP pe 500 și 4500 și lasă răspunsurile să revină fără o a doua regulă. ESP și GRE nu transportă porturi, așa că un dispozitiv NAT nu are de ce să se prindă și are nevoie de un ajutor sau de o încapsulare pentru a urmări sesiunea.

Traversarea NAT este partea care se uită. IKEv2 începe pe UDP 500, detectează un dispozitiv NAT și continuă pe UDP 4500, așa că o politică ce permite doar 500 dă un tunel care se stabilește și apoi tace. L2TP/IPsec face aceeași mișcare. Dacă captura ta arată primul schimb dar nu trafic susținut, caută o regulă care se oprește la 500.

Notează direcția la fiecare regulă. „Permite UDP 4500” nu înseamnă nimic până nu spui de unde până unde, iar o regulă corectă pentru un client nomad este de obicei greșită pentru un partener sit-la-sit.

Verifică fiecare cale cu o captură

Rulează captura pe poartă, nu pe client: un client înregistrează doar ce a ajuns. Aceste filtre acoperă familiile de mai sus și arată ce etapă lipsește:

sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50

Citește ieșirea ca o secvență. Când negocierea apare dar protocolul de încărcătură nu, aruncarea se produce undeva între client și poartă. Când apar ambele și pagina tot eșuează, firewallul nu mai este suspectul; uită-te la rutare, DNS sau la pool-ul de adrese dat clientului.

Pe o mașină fără tcpdump, aceleași dovezi vin din contoarele de interfață și de reguli. Octeții care intră dar nu ies pe interfața tunelului indică calea de întoarcere și nu regula inițială de permisiune.

Lasă un set de reguli pe care îl poți apăra

SSTP pe TCP 443 este imposibil de distins de un HTTPS obișnuit pentru orice filtru bazat pe porturi, și exact acesta este scopul când o rețea permite doar trafic web. De aceea regula pentru 443 trebuie să numească poarta ca destinație, nu tot internetul. Șterge regulile temporare de orice-către-orice imediat ce tunelul funcționează. Notează ce regulă s-a potrivit, numărul de protocol unde există și direcția, ca următoarea persoană să pornească de la dovezi.

Porțile cloud de tip punct-la-sit fac alegerea vizibilă: profilul descărcat folosește fie SSTP pe 443, fie IKEv2 pe 500 și 4500, și ar trebui să deschizi doar pe cel pe care profilul îl alege efectiv. PPTP nu merită excepția GRE într-o rețea modernă, fiindcă operatorii mobili aruncă adesea protocolul 47 indiferent de firewall. Înainte să închizi tichetul, confirmă că regula corespunde portului din configurația serverului, că câmpul de protocol este setat acolo unde familia are nevoie și că destinația este poarta, nu orice adresă.