Portudløsning kontra portvideresendelse til en VPN-server derhjemme

Portvideresendelse og portudløsning står i samme menu på de fleste hjemmeroutere, og derfor behandles de som to måder at gøre én ting på. Videresendelse er en statisk regel: en indgående forbindelse til en WAN-port oversættes til en fast intern adresse og port, uanset om noget andet sker. Udløsning er betinget: routeren overvåger udgående trafik og åbner først en indgående mapping, når en matchende forbindelse går ud. En VPN-server venter på, at en anden forbinder først, så netop den betingelse er det ene, den aldrig kan opfylde.

To regler med forskellige livscyklusser

IPv4-NAT er tilstandsfuld. Når en intern vært sender en pakke ud, opretter routeren en mapping, så svar kan finde vej tilbage; en indgående pakke, der ikke matcher nogen mapping, kasseres, og det er den adfærd, der holder en uopdateret computer væk fra internettet. Videresendelse er en permanent oversættelsespost, der tilføjes manuelt. Udløsning er et midlertidigt hul, der bevogtes af et trafikmønster.

Den praktiske forskel er tid. En videresendelse findes fra det øjeblik, den gemmes, til nogen sletter den. En udløst mapping findes, efter udløseren har slået til, og lukker på en inaktivitetstimer, målt i minutter på forbrugerhardware, eller straks ved genstart.

Ingen af dem er mere sikker i abstrakt forstand. En videresendelse blotlægger én port hele tiden; en udløser blotlægger den først efter bestemt udgående trafik. For en tjeneste, der skal tage imod den første pakke fra en fremmed, passer kun én af de to til opgaven.

Hvorfor udløsning ikke offentliggør en server

En VPN-server er passiv af design. Modparten, være sig en laptop på en café eller en telefon på mobildata, sender den første pakke, og routeren har ingen mapping til den. Intet indeni har startet trafik til udløserporten, så reglen udløses aldrig, og forbindelsen dør, før håndtrykket begynder.

Hvor udløsning ser ud til at virke, er det noget andet, der genererer trafik på udløserporten: en klient på LAN'et, en overvågningssonde eller serverens egne udgående kontroller. Så åbner mappingen for den ene vært og lukker, når trafikken stopper, så den næste eksterne modpart fejler igen, mens den første succes ligger i loggen og ligner et bevis.

Udløsning er også normalt enkeltværts. Mange implementeringer lader kun én intern enhed holde mappingen ad gangen, hvilket er helt forkert for en server, der skal svare flere modparter. Funktionen blev bygget til programmer, der åbner en kontrolforbindelse ud og forventer indgående data på en anden port, og den passer stadig til den form.

Hvad en videresendelse faktisk mapper

En videresendelse er én oversættelsespost: WAN-port og protokol til intern adresse og port. Den kræver en lytter, der allerede kører i den anden ende, og den kræver, at den interne adresse bliver, hvor den er. Et DHCP-lease, der flytter til en anden maskine, sender hver tunnel til den forkerte vært, i stilhed, så opret reservationen før reglen.

Protokollen betyder mere, end formularen antyder. OpenVPN over UDP kræver en UDP-videresendelse, WireGuard kræver UDP, og IPsec-data ankommer som ESP, IP-protokol 50, som slet ikke har nogen porte. En videresendelsesformular, der kun accepterer TCP eller UDP, kan ikke udtrykke det, så IPsec kræver passthrough eller en statisk en-til-en-mapping i stedet for en portregel.

Laget over din router

En videresendelse styrer kun den oversættelse, du ejer. Hvis WAN-adressen ikke er din, hvilket er tilfældet bag carrier-grade NAT, hvor abonnenter deler 100.64.0.0/10 som beskrevet i RFC 6598, når den indgående forbindelse aldrig din router, fordi udbyderen oversatte først. Ingen regel på din enhed kan rette den rækkefølge.

Dobbelt NAT er det samme problem i miniature. Din router videresender til ISP-routeren, som ikke har en matchende regel og kasserer pakken. Tilføj enten reglen på den ydre enhed, eller sæt den ydre enhed i bridge-tilstand og lad din beholde den offentlige adresse.

Derfor skal testen komme udefra. En test fra samme LAN gennem den offentlige adresse afhænger af hairpin NAT og kan bestå eller fejle af grunde, der intet har med reglen at gøre; en telefon på mobildata eller en ven på et andet netværk er den renere kontrol.

Afgræns reglen, og verificér så begge halvdele

Videresend én port til én adresse. Et interval, der blev tilføjet, fordi de første forsøg fejlede, er hvordan administrationsgrænseflader ender på internettet, og VPN-lytteren har ikke brug for routerens admin-side offentliggjort ved siden af.

Behold alt, hvad der allerede beskyttede den lytter: certifikat- eller nøgleidentitet, værtens firewall, aktuelle pakkeversioner. En videresendelse lukker en pakke ind; autentificering afgør, om pakken bliver en tunnel, og det er to separate fejl, når noget går galt.

Verifikationen har to halvdele. Håndtrykket skal fuldføres fra et eksternt netværk, og derefter skal en privat ressource bag serveren svare gennem tunnelen. Videresendelse lukker tunnelens forbindelse ind og intet mere; routing og autorisation for 10.8.0.0/24 er en anden indstilling på en anden skærm.

Beslut med tre spørgsmål

Tre spørgsmål afgør valget hurtigere end enhver sammenligningstabel:

• Forbinder noget udefra som den første pakke? Så brug videresendelse eller et relay. Udløsning kan ikke åbne uden udgående trafik, som aldrig vil opstå.
• Skal hullet overleve inaktiv tid? Så brug videresendelse, fordi en udløst mapping lukker efter sin egen tidsplan.
• Er WAN-adressen din at offentliggøre? Hvis ikke, så ret laget ovenover, før du redigerer nogen regel.

Hvis svaret på alle tre er nej, hvilket er tilfældet for en laptop, der selv ringer til en kommerciel udbyder, er ingen af reglerne nødvendige. En klient bag NAT virker, fordi den selv opretter den tilstandsfulde mapping, og det dækker de fleste af de mennesker, der læser en side om portvideresendelse ved midnat.