Portutløsing kontra portvideresending for en VPN-server hjemme

Portvideresending og portutløsing ligger i samme meny på de fleste hjemmerutere, og derfor behandles de som to måter å gjøre én jobb på. Videresending er en statisk regel: en innkommende tilkobling til en WAN-port oversettes til en fast intern adresse og port, uansett om noe annet skjer. Utløsing er betinget: ruteren overvåker utgående trafikk og åpner en innkommende mapping først når en samsvarende tilkobling går ut. En VPN-server venter på at noen andre kobler til først, så nettopp den betingelsen er det ene den aldri kan oppfylle.

To regler med ulike livssykluser

IPv4-NAT er tilstandsbasert. Når en intern vert sender en pakke ut, oppretter ruteren en mapping slik at svar kan finne veien tilbake; en innkommende pakke som ikke samsvarer med noen mapping, forkastes, og det er denne oppførselen som holder en uoppdatert maskin unna internett. Videresending er en permanent oversettelsesoppføring som legges til manuelt. Utløsing er et midlertidig hull som voktes av et trafikkmønster.

Den praktiske forskjellen er tid. En videresending finnes fra den lagres til noen sletter den. En utløst mapping finnes etter at utløseren slår til, og lukkes på en inaktivitetstimer, målt i minutter på forbrukerutstyr, eller umiddelbart ved omstart.

Ingen av dem er sikrere i abstrakt forstand. En videresending eksponerer én port hele tiden; en utløser eksponerer den først etter bestemt utgående trafikk. For en tjeneste som må ta imot den første pakken fra en fremmed, passer bare én av de to til oppgaven.

Hvorfor utløsing ikke publiserer en server

En VPN-server er passiv av design. Motparten, enten det er en bærbar PC på en kafé eller en telefon på mobildata, sender den første pakken, og ruteren har ingen mapping for den. Ingenting innenfra har startet trafikk til utløserporten, så regelen slår aldri til og tilkoblingen dør før håndtrykket begynner.

Der utløsing ser ut til å virke, er det noe annet som genererer trafikk på utløserporten: en klient på LAN-et, en overvåkingssonde eller serverens egne utgående kontroller. Da åpnes mappingen for den ene verten og lukkes når trafikken stopper, så neste eksterne motpart feiler igjen mens den første suksessen ligger i loggen og ser ut som bevis.

Utløsing er også vanligvis for én vert. Mange implementasjoner lar bare én intern enhet holde mappingen om gangen, noe som er helt feil for en server som skal svare flere motparter. Funksjonen ble laget for applikasjoner som åpner en kontrolltilkobling ut og forventer innkommende data på en andre port, og den passer fortsatt til den formen.

Hva en videresending faktisk mapper

En videresending er én oversettelsesoppføring: WAN-port og protokoll til intern adresse og port. Den trenger en lytter som allerede kjører i andre enden, og den trenger at den interne adressen blir der den er. En DHCP-lease som flytter til en annen maskin sender hver tunnel til feil vert, i stillhet, så opprett reservasjonen før regelen.

Protokollen betyr mer enn skjemaet antyder. OpenVPN over UDP trenger en UDP-videresending, WireGuard trenger UDP, og IPsec-data kommer som ESP, IP-protokoll 50, som ikke har noen porter i det hele tatt. Et videresendingsskjema som bare godtar TCP eller UDP kan ikke uttrykke det, så IPsec trenger passthrough eller en statisk en-til-en-mapping i stedet for en portregel.

Laget over ruteren din

En videresending styrer bare oversettelsen du eier. Hvis WAN-adressen ikke er din, som er tilfellet bak operatør-NAT der abonnenter deler 100.64.0.0/10 som beskrevet i RFC 6598, når den innkommende tilkoblingen aldri ruteren din fordi leverandøren oversatte først. Ingen regel på enheten din kan rette opp den rekkefølgen.

Dobbel NAT er det samme problemet i miniatyr. Ruteren din videresender til ISP-ruteren, som ikke har en samsvarende regel og forkaster pakken. Enten legger du til regelen på den ytre enheten, eller setter den ytre enheten i bromodus og lar din beholde den offentlige adressen.

Derfor må testen komme utenfra. En test fra samme LAN gjennom den offentlige adressen avhenger av hairpin NAT-støtte og kan bestå eller feile av grunner som ikke har med regelen å gjøre; en telefon på mobildata, eller en venn på et annet nettverk, er den renere kontrollen.

Avgrens regelen, og verifiser så begge halvdeler

Videresend én port til én adresse. Et område som ble lagt til fordi de første forsøkene feilet, er hvordan administrasjonsgrensesnitt ender opp på internett, og VPN-lytteren trenger ikke ruterens admin-side publisert ved siden av.

Behold alt som allerede beskyttet den lytteren: sertifikat- eller nøkkelidentitet, vertens brannmur, oppdaterte pakkeversjoner. En videresending slipper en pakke inn; autentisering avgjør om pakken blir en tunnel, og det er to separate feil når noe går galt.

Verifiseringen har to halvdeler. Håndtrykket må fullføres fra et eksternt nettverk, og deretter må en privat ressurs bak serveren svare gjennom tunnelen. Videresending slipper tunnelens tilkobling inn og ingenting mer; ruting og autorisasjon for 10.8.0.0/24 er en annen innstilling på en annen skjerm.

Bestem med tre spørsmål

Tre spørsmål avgjør valget raskere enn noen sammenligningstabell:

• Kobler noe til utenfra som den første pakken? Bruk da videresending, eller et relay. Utløsing kan ikke åpne uten utgående trafikk som aldri vil finnes.
• Må hullet overleve inaktiv tid? Bruk da videresending, fordi en utløst mapping lukkes etter sin egen plan.
• Er WAN-adressen din å publisere? Hvis ikke, reparer laget over før du redigerer noen regel.

Hvis svaret på alle tre er nei, som er tilfellet for en bærbar PC som selv ringer en kommersiell leverandør, trengs ingen av reglene. En klient bak NAT virker fordi den selv oppretter den tilstandsbaserte mappingen, og det dekker de fleste som leser en side om portvideresending ved midnatt.