VPN-portkrav: tre linjer, du skriver, før du sammenligner

Portlister for VPN-tjenester kopieres mellem sammenligningssider uden den detalje, der afgør, om de betyder noget: hvem der starter forbindelsen. En regel, der tillader udgående TCP 443, siger intet om, hvorvidt en anden vært kan nå en lytter på din maskine. Skriv tre separate krav, før du sammenligner en enkelt plan, og markér hvilke din opgave faktisk har brug for. De fleste sammenligninger falder sammen til ét kort spørgsmål, når det ark findes.

Del kravet op, før du læser nogen portliste

Tre linjer dækker næsten alle tilfælde: at nå en destination ud over tunnelen, at publicere noget, så andre kan forbinde ind, og at bære selve tunnelen. Hver linje fejler af en anden grund, og en udbyderpolitik, der opfylder den ene, kan lade de to andre være urørt. At sortere din opgave i den rigtige linje tager fem minutter og sparer en diskussion senere.

Markedsføringsudsagn slører de tre linjer med vilje. En P2P-tilladelse beskriver en destinationspolitik, en dedikeret adresse beskriver en adresse, og en påstand om ingen portbegrænsninger betyder normalt, at planen ikke opregner dem. Ingen af de formuleringer besvarer de andre.

Vælg ét konkret flow og skriv det som en sætning: initiator, transport, port, adressefamilie, retning. En natlig backup-klient, der uploader til en fjern vært, er kun udgående. En spillerserver på dit skrivebord, som venner forbinder til, er indgående. At køre begge gennem én tunnel betyder, at arket har brug for begge linjer, ikke et kompromis mellem dem.

Udgående adgang fejler på destinationspolitik, ikke på tunnelen

Udgående trafik gennem en oversættende gateway skaber tilstand. Den første pakke fra en intern adresse og port bygger en oversættelsespost, og svar matcher den, hvilket er den mappingadfærd, der er beskrevet i RFC 3022. Den mekanisme er grunden til, at en browservane normalt virker helt uden nogen portanmodning.

To ting ødelægger det stadig. Exit-noden kan filtrere destinationer eller portnumre, som den anser for misbrugelige, og applikationen kan lytte på en port, som exit-politikken aldrig forventede. Spørg om destinationsparret i stedet for om indgående regler, og forvent forskellige svar for TCP og UDP.

Mål, før du diskuterer. Kør disse på den maskine, der skal stå bag tunnelen, én gang med tunnelen nede og én gang med den oppe:

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

De samme kommandoer, den samme destination, to tunneltilstande giver en operatør en før-og-efter, som de kan handle på. Erstat dokumentationsadressen med den vært, du faktisk har brug for; det afgørende er, at sammenligningen gentages, ikke at noget tal ser imponerende ud.

Indgående publicering kræver en mapping, en adresse og en levetid

Intet udefra kan starte en forbindelse til din lytter, medmindre noget på den offentlige side ved, hvor den skal leveres. En statisk portreservation, som operatøren holder, en klientanmodet mapping gennem UPnP, NAT-PMP eller PCP, og en routet offentlig adresse er tre forskellige produkter med tre forskellige grænser.

Stil fem spørgsmål til enhver af dem: hvilken protokol, hvilken ekstern port, om den eksterne port må afvige fra den lokale, hvilken adressefamilie den dækker, og hvor længe mappingen overlever en genopkobling. En reservation knyttet til en aktiv session forsvinder, når den session slutter, uanset hvad plansiden siger.

Bekræft den lokale halvdel først, fordi en død lytter og en blokeret indgående vej ser ens ud udefra:

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 lokale anmodning returnerer 200, og en anmodning fra et netværk, du ikke kontrollerer, stadig løber ud, sidder hullet på den offentlige side. Det er øjeblikket til at oplyse protokol og ekstern port til operatøren i stedet for at beskrive appen ved navn.

Tunnelens egen transport er et separat spørgsmål

Bærerporterne er den mindste del af problemet og den letteste at slå op. Standarderne varierer efter protokol, og hvad klienten kan forhandle om, betyder mere end nogen planbeskrivelse.

Et netværk, der dropper udgående UDP, accepterer en TCP 443-tunnel og afviser en UDP-tunnel, så en fallback-tilstand hører på kravarket. At skifte bærer flytter ikke en applikationsport inde i tunnelen og udvider ikke en destinationspolitik; de bliver på deres egne linjer.

Fragmentering fortjener en prøve, mens du er der, fordi en tunnel, der forbinder og derefter går i stå på store overførsler, normalt har den forkerte MTU snarere end en lukket port:

ping -M do -s 1400 203.0.113.10
ping -M do -s 1372 203.0.113.10

På Windows er den samme prøve ping -f -l 1400 203.0.113.10. Sæt tunnelens MTU under den største størrelse, der passerer, og test derefter den overførsel, der fejlede, igen.

Bekræft de tre linjer, før du betaler for en plan

Sæt de tre linjer på én side, og udfyld hver celle med et målt resultat i stedet for et løfte. Disse kommandoer giver den lokale halvdel af den side på cirka et 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 outputtet som en tjekliste. Udgående virker, når destinationen svarer med tunnelen oppe. Indgående virker kun, når en vært uden for dit netværk når lytteren på den eksterne port. Bæreren virker, når håndtrykket fuldføres på en protokol, som dit adgangsnetværk tillader.

To vaner holder arket ærligt. Notér datoen og klientversionen ved siden af hvert resultat, fordi både udbyderpolitikker og klientstandarder flytter sig. Bed derefter om den snævreste mapping, der tjener flowet, fordi en anmodning om at åbne alt normalt giver et afslag eller et mersalg i stedet for et teknisk svar.