VPN-portkrav: tre linjer som skrives før du sammenligner

Portlister for VPN-tjenester kopieres mellom sammenligningssider uten detaljen som avgjør om de betyr noe: hvem som starter forbindelsen. En regel som tillater utgående TCP 443, sier ingenting om hvorvidt en annen vert kan nå en lytter på maskinen din. Skriv tre separate krav før du sammenligner én enkelt plan, og merk hvilke oppgaven din faktisk trenger. De fleste sammenligninger faller sammen til ett kort spørsmål når det arket finnes.

Del opp kravet før du leser noen portliste

Tre linjer dekker nesten alle tilfeller: å nå en destinasjon utenfor tunnelen, å publisere noe slik at andre kan koble inn, og å bære selve tunnelen. Hver linje feiler av en annen grunn, og en leverandørpolicy som oppfyller én, kan la de to andre være urørt. Å sortere oppgaven i riktig linje tar fem minutter og sparer en diskusjon senere.

Markedsføringsutsagn slører de tre linjene med vilje. En P2P-tillatelse beskriver en destinasjonspolicy, en dedikert adresse beskriver en adresse, og påstanden om ingen portbegrensninger betyr vanligvis at planen ikke lister dem opp. Ingen av disse formuleringene besvarer de andre.

Velg én konkret flyt og skriv den som en setning: initiator, transport, port, adressefamilie, retning. En nattlig sikkerhetskopiklient som laster opp til en ekstern vert, er bare utgående. En spillserver på skrivebordet ditt som venner kobler til, er inngående. Å kjøre begge gjennom én tunnel betyr at arket trenger begge linjene, ikke et kompromiss mellom dem.

Utgående tilgang feiler på destinasjonspolicy, ikke på tunnelen

Utgående trafikk gjennom en oversettende gateway skaper tilstand. Den første pakken fra en intern adresse og port bygger en oversettelsesoppføring, og svar samsvarer med den, som er oppførselsen beskrevet i RFC 3022. Den mekanismen er grunnen til at en nettleserfane vanligvis fungerer helt uten noen portforespørsel.

To ting bryter det fortsatt. Utgangsnoden kan filtrere destinasjoner eller portnumre den anser som misbrukbare, og applikasjonen kan lytte på en port som utgangspolicyen aldri forventet. Spør om destinasjonsparet i stedet for om inngående regler, og forvent ulike svar for TCP og UDP.

Mål før du diskuterer. Kjør disse på maskinen som skal stå bak 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 kommandoene, den samme destinasjonen, to tunneltilstander gir en operatør en før-og-etter-sammenligning de kan handle på. Erstatt dokumentasjonsadressen med verten du faktisk trenger; det viktige er at sammenligningen gjentas, ikke at noe tall ser imponerende ut.

Inngående publisering krever en mapping, en adresse og en levetid

Ingenting utenfra kan starte en forbindelse til lytteren din med mindre noe på den offentlige siden vet hvor det skal leveres. En statisk portreservasjon som operatøren holder, en mapping klienten ber om via UPnP, NAT-PMP eller PCP, og en rutet offentlig adresse er tre forskjellige produkter med tre forskjellige grenser.

Still fem spørsmål til hvilken som helst av dem: hvilken protokoll, hvilken ekstern port, om den eksterne porten kan avvike fra den lokale, hvilken adressefamilie den dekker, og hvor lenge mappingen overlever en gjentilkobling. En reservasjon knyttet til en aktiv sesjon forsvinner når den sesjonen slutter, uansett hva plansiden sier.

Bekreft den lokale halvdelen først, fordi en død lytter og en blokkert inngående vei ser like ut utenfra:

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 forespørselen returnerer 200 og en forespørsel fra et nettverk du ikke kontrollerer fortsatt går ut på tid, sitter gapet på den offentlige siden. Det er øyeblikket for å oppgi protokoll og ekstern port til operatøren i stedet for å beskrive appen ved navn.

Tunnelens egen transport er et eget spørsmål

Bærerportene er den minste delen av problemet og den letteste å slå opp. Standardverdiene varierer etter protokoll, og hva klienten kan forhandle om betyr mer enn noen planbeskrivelse.

Et nettverk som dropper utgående UDP, godtar en TCP 443-tunnel og avviser en UDP-tunnel, så en reserve-modus hører hjemme på kravarket. Å bytte bærer flytter ikke en applikasjonsport inne i tunnelen og utvider ikke en destinasjonspolicy; de blir på sine egne linjer.

Fragmentering fortjener én test mens du er der, fordi en tunnel som kobler til og deretter stopper på store overføringer vanligvis har feil MTU snarere enn 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 testen ping -f -l 1400 203.0.113.10. Sett tunnelens MTU under den største størrelsen som passerer, og test deretter overføringen som feilet på nytt.

Bekreft de tre linjene før du betaler for en plan

Sett de tre linjene på én side og fyll hver celle med et målt resultat i stedet for et løfte. Disse kommandoene gir den lokale halvdelen av den siden på omtrent et minutt:

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

Les utdataene som en sjekkliste. Utgående virker når destinasjonen svarer med tunnelen oppe. Inngående virker bare når en vert utenfor nettverket ditt når lytteren på den eksterne porten. Bæreren virker når håndtrykket fullføres på en protokoll som aksessnettverket ditt tillater.

To vaner holder arket ærlig. Noter datoen og klientversjonen ved siden av hvert resultat, fordi både leverandørpolicyer og klientstandarder beveger seg. Be deretter om den smaleste mappingen som tjener flyten, fordi en forespørsel om å åpne alt vanligvis gir en avvisning eller et mersalg i stedet for et teknisk svar.