Requisiti delle porte VPN: tre righe da scrivere prima di confrontare
Determinate quale domanda sulle porte avete davvero: destinazione in uscita, pubblicazione in entrata o il trasporto proprio del tunnel. Poi chiedete al fornitore solo quello.
Gli elenchi di porte dei servizi VPN vengono copiati tra pagine di confronto senza il dettaglio che decide se contano: chi avvia la connessione. Una regola che consente TCP 443 in uscita non dice nulla sulla possibilità che un altro host raggiunga un listener sulla vostra macchina. Scrivete tre requisiti separati prima di confrontare un solo piano, e segnate quali serve davvero al vostro compito. La maggior parte dei confronti si riduce a una sola domanda breve quando quel foglio esiste.
Separate il requisito prima di leggere qualsiasi elenco di porte
Tre righe coprono quasi ogni caso: raggiungere una destinazione oltre il tunnel, pubblicare qualcosa perché altri possano connettersi verso l’interno, e trasportare il tunnel stesso. Ogni riga fallisce per un motivo diverso, e una politica del fornitore che ne soddisfa una può lasciare intatte le altre due. Ordinare il compito nella riga giusta richiede cinque minuti e risparmia una discussione più tardi.
| 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? |
Le dichiarazioni di marketing confondono le tre righe di proposito. Un permesso P2P descrive una politica di destinazione, un indirizzo dedicato descrive un indirizzo, e l’affermazione che non ci sono restrizioni di porte di solito significa che il piano non le elenca. Nessuna di queste frasi risponde alle altre.
Scegliete un flusso concreto e scrivetelo come una frase: iniziatore, trasporto, porta, famiglia di indirizzi, direzione. Un client di backup notturno che carica su un host remoto è solo in uscita. Un server di gioco sulla vostra scrivania a cui si uniscono gli amici è in entrata. Eseguire entrambi attraverso un solo tunnel significa che il foglio ha bisogno di entrambe le righe, non di un compromesso tra loro.
L’accesso in uscita fallisce sulla politica di destinazione, non sul tunnel
Il traffico in uscita attraverso un gateway che traduce crea stato. Il primo pacchetto da un indirizzo e una porta interni costruisce una voce di traduzione, e le risposte vi corrispondono, che è il comportamento di mappatura descritto in RFC 3022. Quel meccanismo è il motivo per cui una scheda del browser di solito funziona senza alcuna richiesta di porta.
Due cose lo rompono ancora. Il nodo di uscita può filtrare destinazioni o numeri di porta che ritiene abusabili, e l’applicazione può ascoltare su una porta che la politica di uscita non ha mai previsto. Chiedete della coppia di destinazione invece delle regole in entrata, e aspettatevi risposte diverse per TCP e UDP.
Misurate prima di discutere. Eseguite questi comandi sulla macchina che starà dietro il tunnel, una volta con il tunnel spento e una con il tunnel acceso:
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
Gli stessi comandi, la stessa destinazione, due stati del tunnel, danno a un operatore un confronto prima e dopo su cui può agire. Sostituite l’indirizzo di documentazione con l’host che vi serve davvero; l’importante è che il confronto si ripeta, non che qualche numero sembri impressionante.
La pubblicazione in entrata richiede una mappatura, un indirizzo e una durata
Nulla dall’esterno può avviare una connessione verso il vostro listener se qualcosa sul lato pubblico non sa dove consegnarla. Una prenotazione di porta statica tenuta dall’operatore, una mappatura richiesta dal client tramite UPnP, NAT-PMP o PCP, e un indirizzo pubblico instradato sono tre prodotti diversi con tre limiti diversi.
Fate cinque domande a ognuno di essi: quale protocollo, quale porta esterna, se la porta esterna può differire da quella locale, quale famiglia di indirizzi copre e quanto sopravvive la mappatura a una riconnessione. Una prenotazione legata a una sessione attiva scompare quando quella sessione finisce, qualunque cosa dica la pagina del piano.
Confermate prima la metà locale, perché un listener morto e un percorso in entrata bloccato sembrano uguali dall’esterno:
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
Quando la richiesta locale restituisce 200 e una richiesta da una rete che non controllate va ancora in timeout, il divario è sul lato pubblico. È il momento di indicare all’operatore protocollo e porta esterna invece di descrivere l’applicazione per nome.
Il trasporto proprio del tunnel è una questione separata
Le porte del vettore sono la parte più piccola del problema e la più facile da cercare. I valori predefiniti variano per protocollo, e ciò che il client può negoziare conta più di qualsiasi descrizione del piano.
| 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 |
Una rete che scarta UDP in uscita accetterà un tunnel TCP 443 e rifiuterà quello UDP, quindi una modalità di riserva appartiene al foglio dei requisiti. Cambiare il vettore non sposta una porta applicativa dentro il tunnel e non allarga una politica di destinazione; quelle restano sulle loro righe.
La frammentazione merita una sonda mentre siete lì, perché un tunnel che si connette e poi si blocca sui trasferimenti grandi di solito ha un MTU sbagliato più che una porta chiusa:
ping -M do -s 1400 203.0.113.10 ping -M do -s 1372 203.0.113.10
Su Windows la stessa sonda è ping -f -l 1400 203.0.113.10. Impostate l’MTU del tunnel sotto la dimensione più grande che passa, poi riprovate il trasferimento che ha fallito.
Verificate le tre righe prima di pagare un piano
Mettete le tre righe su una pagina e riempite ogni cella con un risultato misurato invece che con una promessa. Questi comandi producono la metà locale di quella pagina in circa un minuto:
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
Leggete l’output come una lista di controllo. L’uscita funziona quando la destinazione risponde con il tunnel attivo. L’entrata funziona solo quando un host fuori dalla vostra rete raggiunge il listener sulla porta esterna. Il vettore funziona quando la stretta di mano si completa su un protocollo che la vostra rete di accesso permette.
Due abitudini mantengono onesto il foglio. Annotate la data e la versione del client accanto a ogni risultato, perché sia le politiche dei fornitori sia i valori predefiniti dei client si muovono. Poi chiedete la mappatura più stretta che serve al flusso, perché una richiesta di aprire tutto ottiene di solito un rifiuto o una vendita aggiuntiva invece di una risposta tecnica.