Cerințe de porturi pentru VPN: trei linii de scris înainte de a compara
Stabiliți ce întrebare despre porturi aveți de fapt: destinație de ieșire, publicare de intrare sau transportul propriu al tunelului. Apoi întrebați furnizorul doar despre asta.
Listele de porturi pentru serviciile VPN sunt copiate între paginile de comparație fără detaliul care decide dacă contează: cine începe conexiunea. O regulă care permite TCP 443 de ieșire nu spune nimic despre dacă alt host poate ajunge la un ascultător de pe mașina dumneavoastră. Scrieți trei cerințe separate înainte de a compara un singur plan, și marcați care sunt cele de care are nevoie sarcina dumneavoastră. Majoritatea comparațiilor se reduc la o singură întrebare scurtă odată ce există această fișă.
Separați cerința înainte de a citi orice listă de porturi
Trei linii acoperă aproape toate cazurile: atingerea unei destinații dincolo de tunel, publicarea a ceva pentru ca alții să se poată conecta înăuntru, și transportarea tunelului însuși. Fiecare linie eșuează dintr-un motiv diferit, iar o politică de furnizor care satisface una poate lăsa celelalte două neatinse. Încadrarea sarcinii în linia corectă durează cinci minute și economisește o dispută mai târziu.
| Line | Who starts it | What can block it | Question for the provider |
|---|---|---|---|
| Outbound destination | Your application | Egress filter on the exit node | Is this protocol and port allowed to that destination? |
| Inbound publishing | A remote peer | No mapping, no public address, short lifetime | Which protocol, which external port, and how long does the mapping last? |
| Tunnel transport | Your client to the gateway | The access network drops that protocol | Does the client offer a fallback the local network permits? |
Afirmațiile de marketing estompează cele trei linii intenționat. O permisiune P2P descrie o politică de destinație, o adresă dedicată descrie o adresă, iar afirmația că nu există restricții de porturi înseamnă de obicei că planul nu le enumeră. Niciuna dintre aceste formulări nu răspunde celorlalte.
Alegeți un flux concret și scrieți-l ca o propoziție: inițiator, transport, port, familie de adrese, direcție. Un client de backup nocturn care încarcă pe un host îndepărtat este doar de ieșire. Un server de jocuri pe biroul dumneavoastră la care se alătură prietenii este de intrare. Rularea ambelor printr-un singur tunel înseamnă că fișa are nevoie de ambele linii, nu de un compromis între ele.
Accesul de ieșire eșuează pe politica de destinație, nu pe tunel
Traficul de ieșire printr-o poartă care traduce creează stare. Primul pachet de la o adresă și un port interne construiește o intrare de traducere, iar răspunsurile se potrivesc cu ea, ceea ce este comportamentul de mapare descris în RFC 3022. Acel mecanism este motivul pentru care un tab de browser funcționează de obicei fără nicio cerere de port.
Două lucruri îl mai strică. Nodul de ieșire poate filtra destinații sau numere de port pe care le consideră abuzabile, iar aplicația poate asculta pe un port la care politica de ieșire nu s-a așteptat niciodată. Întrebați despre perechea de destinație, nu despre regulile de intrare, și așteptați-vă la răspunsuri diferite pentru TCP și UDP.
Măsurați înainte de a argumenta. Rulați acestea pe mașina care va sta în spatele tunelului, o dată cu tunelul oprit și o dată cu el pornit:
ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://example.com
Aceleași comenzi, aceeași destinație, două stări ale tunelului dau unui operator o comparație înainte și după pe care poate acționa. Înlocuiți adresa de documentație cu hostul de care aveți nevoie cu adevărat; important este ca comparația să se repete, nu ca vreun număr să pară impresionant.
Publicarea de intrare are nevoie de o mapare, o adresă și o durată de viață
Nimic din exterior nu poate începe o conexiune către ascultătorul dumneavoastră decât dacă ceva din partea publică știe unde să o livreze. O rezervare statică de port ținută de operator, o mapare cerută de client prin UPnP, NAT-PMP sau PCP, și o adresă publică rutată sunt trei produse diferite cu trei limite diferite.
Puneți cinci întrebări despre oricare dintre ele: ce protocol, ce port extern, dacă portul extern poate diferi de cel local, ce familie de adrese acoperă și cât supraviețuiește maparea unei reconectări. O rezervare legată de o sesiune activă dispare când acea sesiune se termină, orice ar spune pagina planului.
Confirmați mai întâi jumătatea locală, pentru că un ascultător mort și o cale de intrare blocată arată la fel din exterior:
ss -lntup | grep -E ':(8080|51820)\b'
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
Când cererea locală returnează 200 iar o cerere dintr-o rețea pe care nu o controlați încă expiră, golul este în partea publică. Acesta este momentul să îi spuneți operatorului protocolul și portul extern în loc să descrieți aplicația după nume.
Transportul propriu al tunelului este o întrebare separată
Porturile purtătorului sunt cea mai mică parte a problemei și cea mai ușor de căutat. Valorile implicite diferă în funcție de protocol, iar ce poate clientul negocia contează mai mult decât orice descriere a planului.
| Client | Outer transport | Default port | When it helps |
|---|---|---|---|
| OpenVPN | UDP | 1194 | Default mode; needs outbound UDP to pass |
| OpenVPN | TCP | 443 | UDP is dropped and TCP 443 is not |
| WireGuard | UDP | 51820 | Short handshake; there is no TCP mode |
| IKEv2/IPsec | UDP | 500 and 4500 | Mobile clients; 4500 carries NAT traversal |
O rețea care aruncă UDP de ieșire va accepta un tunel TCP 443 și va refuza unul UDP, așa că un mod de rezervă aparține fișei de cerințe. Schimbarea purtătorului nu mută un port de aplicație în interiorul tunelului și nu lărgește o politică de destinație; acelea rămân pe liniile lor.
Fragmentarea merită o sondă cât timp sunteți acolo, pentru că un tunel care se conectează și apoi se blochează la transferuri mari are de obicei un MTU greșit, nu un port închis:
ping -M do -s 1400 203.0.113.10 ping -M do -s 1372 203.0.113.10
În Windows aceeași sondă este ping -f -l 1400 203.0.113.10. Setați MTU-ul tunelului sub cea mai mare dimensiune care trece, apoi retestați transferul care a eșuat.
Verificați cele trei linii înainte de a plăti un plan
Puneți cele trei linii pe o singură pagină și completați fiecare celulă cu un rezultat măsurat în loc de o promisiune. Aceste comenzi produc jumătatea locală a paginii în aproximativ un minut:
ss -lntup | sort
nc -vz -w 3 203.0.113.10 443
python3 -m http.server 8080 --bind 0.0.0.0
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080
ping -M do -s 1400 203.0.113.10
Citiți ieșirea ca o listă de verificare. Ieșirea funcționează când destinația răspunde cu tunelul pornit. Intrarea funcționează doar când un host din afara rețelei dumneavoastră ajunge la ascultător pe portul extern. Purtătorul funcționează când strângerea de mână se încheie pe un protocol pe care rețeaua dumneavoastră de acces îl permite.
Două obiceiuri țin fișa cinstită. Notați data și versiunea clientului lângă fiecare rezultat, pentru că se mișcă atât politicile furnizorilor, cât și valorile implicite ale clienților. Apoi cereți cea mai îngustă mapare care servește fluxul, pentru că o cerere de a deschide tot obține de obicei un refuz sau o vânzare suplimentară în loc de un răspuns tehnic.