Portutløysing kontra portvideresending for ein VPN-server heime

Portvideresending og portutløysing ligg i same meny på dei fleste heimerutarar, og difor vert dei handsama som to måtar å gjere éi oppgåve på. Videresending er ein statisk regel: ei innkomande tilkopling til ein WAN-port vert omsett til ein fast intern adresse og port, uansett om noko anna skjer. Utløysing er vilkårleg: rutaren overvakar utgåande trafikk og opnar ei innkomande kartlegging fyrst når ei samsvarande tilkopling går ut. Ein VPN-server ventar på at nokon andre koplar til fyrst, så nettopp det vilkåret er det einaste han aldri kan oppfylle.

To reglar med ulike livssyklusar

IPv4-NAT er tilstandsbasert. Når ein intern vert sender ein pakke ut, lagar rutaren ei kartlegging slik at svar kan finne vegen tilbake; ein innkomande pakke som ikkje passar med noka kartlegging, vert kasta, og det er denne åtferda som held ein uoppdatert maskin utanfor internett. Videresending er ein permanent omsetjingsoppføring som vert lagd til manuelt. Utløysing er eit mellombels hol som vert vakta av eit trafikkmønster.

Den praktiske skilnaden er tid. Ei videresending finst frå ho vert lagra til nokon slettar ho. Ei utløyst kartlegging finst etter at utløysaren slår til, og vert stengd på ein inaktivitetstimar, målt i minutt på forbrukarutstyr, eller straks ved omstart.

Ingen av dei er tryggare i abstrakt tyding. Ei videresending blottlegg ein port heile tida; ein utløysar blottlegg han fyrst etter bestemd utgåande trafikk. For ein teneste som må ta imot den fyrste pakken frå ein framand, passar berre éin av dei to til oppgåva.

Kvifor utløysing ikkje publiserer ein server

Ein VPN-server er passiv av design. Motparten, anten det er ein berbar PC på ein kafé eller ein telefon på mobildata, sender den fyrste pakken, og rutaren har inga kartlegging for han. Ingenting innanfrå har starta trafikk til utløysarporten, så regelen slår aldri til og tilkoplinga døyr før handtrykket byrjar.

Der utløysing ser ut til å verke, er det noko anna som lagar trafikk på utløysarporten: ein klient på LAN-et, ein overvakingssond eller serveren sine eigne utgåande kontrollar. Då opnar kartlegginga for den eine verten og stengjer når trafikken stoppar, så neste eksterne motpart feilar igjen medan den fyrste suksessen ligg i loggen og ser ut som prov.

Utløysing er også vanlegvis for éin vert. Mange implementasjonar lèt berre éi intern eining halde kartlegginga om gongen, noko som er heilt feil for ein server som skal svare fleire motpartar. Funksjonen vart bygd for program som opnar ei kontrolltilkopling ut og ventar innkomande data på ein andre port, og han passar framleis til den forma.

Kva ei videresending faktisk kartlegg

Ei videresending er éin omsetjingsoppføring: WAN-port og protokoll til intern adresse og port. Ho treng ein lyttar som alt køyrer i andre enden, og ho treng at den interne adressa vert der ho er. Ein DHCP-lease som flyttar til ein annan maskin sender kvar tunnel til feil vert, i stillheit, så lag reservasjonen før regelen.

Protokollen tyder meir enn skjemaet antydar. OpenVPN over UDP treng ei UDP-videresending, WireGuard treng UDP, og IPsec-data kjem som ESP, IP-protokoll 50, som ikkje har nokon portar i det heile. Eit videresendingsskjema som berre godtek TCP eller UDP kan ikkje uttrykkje det, så IPsec treng passthrough eller ei statisk éin-til-éin-kartlegging i staden for ein portregel.

Laget over rutaren din

Ei videresending styrer berre omsetjinga du eig. Viss WAN-adressa ikkje er di, som er tilfellet bak operatør-NAT der abonnentar deler 100.64.0.0/10 som skildra i RFC 6598, når den innkomande tilkoplinga aldri rutaren din fordi leverandøren omsette fyrst. Ingen regel på eininga di kan rette opp den rekkjefølgja.

Dobbel NAT er det same problemet i miniatyr. Rutaren din videresender til ISP-rutaren, som ikkje har nokon samsvarande regel og kastar pakken. Anten legg du til regelen på den ytre eininga, eller set den ytre eininga i bromodus og lèt di halde den offentlege adressa.

Difor må testen kome utanfrå. Ein test frå same LAN gjennom den offentlege adressa er avhengig av hairpin NAT-støtte og kan gå gjennom eller feile av grunnar som ikkje har med regelen å gjere; ein telefon på mobildata, eller ein ven på eit anna nettverk, er den reinare kontrollen.

Avgrens regelen, og verifiser så begge helftene

Videresend éin port til éi adresse. Eit område som vart lagt til fordi dei fyrste freistnadene feila, er korleis administrasjonsgrensesnitt hamnar på internett, og VPN-lyttaren treng ikkje ruterens admin-side publisert ved sida av.

Hald på alt som alt verna den lyttaren: sertifikat- eller nøkkelidentitet, vertens brannmur, oppdaterte pakkeversjonar. Ei videresending slepp ein pakke inn; autentisering avgjer om pakken vert ein tunnel, og det er to separate feil når noko går gale.

Verifiseringa har to helfter. Handtrykket må fullførast frå eit eksternt nettverk, og deretter må ein privat ressurs bak serveren svare gjennom tunnelen. Videresending slepp tilkoplinga til tunnelen inn og ingenting meir; ruting og autorisasjon for 10.8.0.0/24 er ei anna innstilling på ein annan skjerm.

Avgjer med tre spørsmål

Tre spørsmål avgjer valet raskare enn noka samanlikningstabell:

• Koplar noko til utanfrå som den fyrste pakken? Bruk då videresending, eller eit relay. Utløysing kan ikkje opne utan utgåande trafikk som aldri vil finnast.
• Må holet overleve inaktiv tid? Bruk då videresending, fordi ei utløyst kartlegging stengjer etter sin eigen plan.
• Er WAN-adressa di å publisere? Viss ikkje, reparer laget over før du endrar nokon regel.

Viss svaret på alle tre er nei, som er tilfellet for ein berbar PC som sjølv ringjer ein kommersiell leverandør, trengst ingen av reglane. Ein klient bak NAT verkar fordi han sjølv lagar den tilstandsbaserte kartlegginga, og det dekkjer dei fleste som les ei side om portvideresending ved midnatt.