VPN-portkrav: tre rader att skriva innan du jämför
Ta reda på vilken portfråga du faktiskt har: utgående mål, inkommande publicering eller tunnelns egen transport. Fråga sedan leverantören bara om det.
Portlistor för VPN-tjänster kopieras mellan jämförelsesidor utan den detalj som avgör om de spelar roll: vem som startar anslutningen. En regel som tillåter utgående TCP 443 säger ingenting om huruvida en annan värd kan nå en lyssnare på din maskin. Skriv tre separata krav innan du jämför en enda plan, och markera vilka din uppgift faktiskt behöver. De flesta jämförelser krymper till en enda kort fråga när det bladet finns.
Dela upp kravet innan du läser någon portlista
Tre rader täcker nästan alla fall: att nå ett mål bortom tunneln, att publicera något så att andra kan ansluta in, och att bära själva tunneln. Varje rad misslyckas av olika skäl, och en leverantörspolicy som uppfyller en kan lämna de andra två orörda. Att sortera uppgiften i rätt rad tar fem minuter och sparar en diskussion senare.
| 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? |
Marknadsföringspåståenden suddar medvetet ut de tre raderna. Ett P2P-tillstånd beskriver en målpolicy, en dedikerad adress beskriver en adress, och påståendet att det inte finns några portbegränsningar betyder oftast att planen inte listar dem. Ingen av dessa formuleringar besvarar de andra.
Välj ett konkret flöde och skriv det som en mening: initiativtagare, transport, port, adressfamilj, riktning. En nattlig säkerhetskopieringsklient som laddar upp till en fjärrvärd är bara utgående. En spelserver på ditt skrivbord som vänner ansluter till är inkommande. Att köra båda genom en tunnel betyder att bladet behöver båda raderna, inte en kompromiss mellan dem.
Utgående åtkomst misslyckas på målpolicyn, inte på tunneln
Utgående trafik genom en översättande gateway skapar tillstånd. Det första paketet från en intern adress och port bygger en översättningspost, och svar matchar den, vilket är det mappningsbeteende som beskrivs i RFC 3022. Den mekanismen är anledningen till att en webbläsarflik vanligtvis fungerar helt utan någon portförfrågan.
Två saker bryter det fortfarande. Utgångsnoden kan filtrera mål eller portnummer som den anser missbrukbara, och programmet kan lyssna på en port som utgångspolicyn aldrig förväntade sig. Fråga om målparet i stället för om inkommande regler, och förvänta dig olika svar för TCP och UDP.
Mät innan du diskuterar. Kör dessa på maskinen som ska stå bakom tunneln, en gång med tunneln nere och en gång med den uppe:
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
Samma kommandon, samma mål, två tunneltillstånd ger en operatör en före-och-efter-jämförelse att agera på. Byt ut dokumentationsadressen mot den värd du faktiskt behöver; det viktiga är att jämförelsen upprepas, inte att någon siffra ser imponerande ut.
Inkommande publicering kräver en mappning, en adress och en livstid
Ingenting utifrån kan starta en anslutning till din lyssnare om inte något på den publika sidan vet var den ska levereras. En statisk portreservation som operatören håller, en mappning som klienten begär via UPnP, NAT-PMP eller PCP, och en routad publik adress är tre olika produkter med tre olika gränser.
Ställ fem frågor till vilken som helst av dem: vilket protokoll, vilken extern port, om den externa porten får skilja sig från den lokala, vilken adressfamilj den täcker, och hur länge mappningen överlever en återanslutning. En reservation knuten till en aktiv session försvinner när den sessionen slutar, vad plansidan än säger.
Bekräfta den lokala halvan först, eftersom en död lyssnare och en blockerad inkommande väg ser likadana ut utifrån:
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
När den lokala förfrågan returnerar 200 och en förfrågan från ett nätverk du inte kontrollerar fortfarande tar timeout, sitter gapet på den publika sidan. Det är ögonblicket att ange protokoll och extern port till operatören i stället för att beskriva appen vid namn.
Tunnelns egen transport är en separat fråga
Bärarportarna är den minsta delen av problemet och den enklaste att slå upp. Standardvärdena varierar per protokoll, och vad klienten kan förhandla om spelar större roll än någon planbeskrivning.
| 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 |
Ett nätverk som kastar utgående UDP accepterar en TCP 443-tunnel och nekar en UDP-tunnel, så ett reservläge hör hemma på kravbladet. Att byta bärare flyttar inte en programport inne i tunneln och breddar inte en målpolicy; de stannar på sina egna rader.
Fragmentering förtjänar ett prov medan du är där, eftersom en tunnel som ansluter och sedan fastnar vid stora överföringar oftast har fel MTU snarare än en stängd port:
ping -M do -s 1400 203.0.113.10 ping -M do -s 1372 203.0.113.10
I Windows är samma prov ping -f -l 1400 203.0.113.10. Sätt tunnelns MTU under den största storlek som passerar, och testa sedan om den misslyckade överföringen.
Verifiera de tre raderna innan du betalar för en plan
Sätt de tre raderna på en sida och fyll varje cell med ett uppmätt resultat i stället för ett löfte. Dessa kommandon tar fram den lokala halvan av den sidan på ungefär en 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
Läs utdata som en checklista. Utgående fungerar när målet svarar med tunneln uppe. Inkommande fungerar bara när en värd utanför ditt nätverk når lyssnaren på den externa porten. Bäraren fungerar när handskakningen slutförs på ett protokoll som ditt åtkomstnätverk tillåter.
Två vanor håller bladet ärligt. Notera datum och klientversion bredvid varje resultat, eftersom både leverantörspolicyer och klientstandardvärden rör sig. Be sedan om den smalaste mappning som tjänar flödet, eftersom en begäran att öppna allt oftast ger ett avslag eller en merförsäljning i stället för ett tekniskt svar.