Poorttriggering teenoor poortaanstuur vir ’n tuis-VPN-bediener

Poortaanstuur en poorttriggering sit in dieselfde kieslys op die meeste tuisroeteerders, en daarom word hulle as twee maniere beskou om een taak te doen. Aanstuur is ’n statiese reël: ’n inkomende verbinding na ’n WAN-poort word na ’n vaste binne-adres en poort vertaal, of daar nou iets anders aan die gang is of nie. Triggering is voorwaardelik: die roeteerder hou uitgaande verkeer dop en maak eers ’n inkomende kartering oop nadat ’n passende verbinding uitgaan. ’n VPN-bediener wag dat iemand anders eerste verbind, so daardie voorwaarde is juis die een ding wat hy nooit kan vervul nie.

Twee reëls met verskillende lewensiklusse

IPv4 NAT hou toestand. Wanneer ’n binne-gasheer ’n pakkie uitstuur, skep die roeteerder ’n kartering sodat antwoorde hulle pad terug kan vind; ’n inkomende pakkie wat by geen kartering pas nie, word laat vaar, en dit is die gedrag wat ’n onopgedateerde rekenaar van die internet af hou. Aanstuur is ’n permanente vertaalinskrywing wat met die hand bygevoeg word. Triggering is ’n tydelike gat wat deur ’n verkeerspatroon beskerm word.

Die praktiese verskil is tyd. ’n Aanstuur bestaan vanaf die oomblik dat dit gestoor word totdat iemand dit verwyder. ’n Getriggerde kartering bestaan nadat die sneller afgevuur het en sluit op ’n ledige tydhouer, gemeet in minute op verbruikershardeware, of onmiddellik by herstart.

Nie een is in die abstrakte veiliger nie. ’n Aanstuur stel een poort voortdurend bloot; ’n trigger stel dit eers ná spesifieke uitgaande verkeer bloot. Vir ’n diens wat die eerste pakkie van ’n vreemdeling moet aanvaar, pas net een van dié twee by die taak.

Waarom triggering ’n bediener nie sal publiseer nie

’n VPN-bediener is per ontwerp passief. Die eweknie, of dit ’n skootrekenaar in ’n kafee of ’n selfoon op mobiele data is, stuur die eerste pakkie, en die roeteerder het geen kartering daarvoor nie. Niks binne het verkeer na die trigger-poort begin nie, so die reël vuur nooit af nie en die verbinding sterf voordat die handdruk begin.

Waar triggering wel te werk lyk, genereer iets anders verkeer op die trigger-poort: ’n kliënt op die LAN, ’n moniteringspeiling, of die bediener se eie uitgaande kontroles. Die kartering gaan dan vir daardie een gasheer oop en sluit wanneer die verkeer stop, so die volgende eksterne eweknie misluk weer terwyl die eerste sukses in die logboek sit en soos bewys lyk.

Triggering is ook gewoonlik enkel-gasheer. Baie implementasies laat net een binne-toestel op ’n slag die kartering hou, wat heeltemal verkeerd is vir ’n bediener wat verskeie eweknieë moet antwoord. Die funksie is gebou vir toepassings wat ’n beheerverbinding uitgaande oopmaak en inkomende data op ’n tweede poort verwag, en dit pas steeds by daardie vorm.

Wat ’n aanstuur werklik karteer

’n Aanstuur is een vertaalinskrywing: WAN-poort en protokol na binne-adres en poort. Dit het ’n luisteraar nodig wat reeds aan die ander kant loop, en dit het nodig dat die binne-adres bly waar dit is. ’n DHCP-huurkontrak wat na ’n ander masjien skuif, stuur elke tonnel stilweg na die verkeerde gasheer, so skep die reservering voor die reël.

Protokol maak meer saak as wat die vorm laat vermoed. OpenVPN oor UDP het ’n UDP-aanstuur nodig, WireGuard het UDP nodig, en IPsec-data kom as ESP, IP-protokol 50, wat glad geen poorte het nie. ’n Aanstuurvorm wat net TCP of UDP aanvaar, kan dit nie uitdruk nie, so IPsec het deurvoer of ’n statiese een-tot-een-kartering nodig in plaas van ’n poortreël.

Die laag bo jou roeteerder

’n Aanstuur beheer net die vertaling wat jy besit. As die WAN-adres nie joune is nie, wat die geval is agter draer-graad NAT waar intekenare 100.64.0.0/10 deel soos in RFC 6598 beskryf, bereik die inkomende verbinding nooit jou roeteerder nie, want die verskaffer het eerste vertaal. Geen reël op jou toestel kan daardie volgorde regstel nie.

Dubbele NAT is dieselfde probleem in miniatuur. Jou roeteerder stuur aan na die ISP-roeteerder, wat geen passende reël het nie en die pakkie laat vaar. Voeg die reël óf op die buitenste toestel by, óf plaas die buitenste toestel in brugmodus en laat joune die openbare adres hou.

Daarom moet die toets van buite kom. ’n Toets binne dieselfde LAN deur die openbare adres hang van haarspeld-NAT-ondersteuning af en kan slaag of misluk om redes wat niks met die reël te doen het nie; ’n selfoon op mobiele data, of ’n vriend op ’n ander netwerk, is die skoner kontrole.

Beperk die reël, en verifieer dan albei helftes

Stuur een poort na een adres aan. ’n Reeks wat bygevoeg is omdat die eerste pogings misluk het, is hoe bestuurskoppelvlakke op die internet beland, en die VPN-luisteraar het nie die roeteerder se admin-blad langs hom gepubliseer nodig nie.

Hou alles wat daardie luisteraar reeds beskerm het: sertifikaat- of sleutelidentiteit, gasheer-firewall, huidige pakketweergawes. ’n Aanstuur laat ’n pakkie in; outentisering bepaal of die pakkie ’n tonnel word, en dit is twee afsonderlike foute wanneer iets verkeerd loop.

Verifikasie het twee helftes. Die handdruk moet van ’n eksterne netwerk voltooi, en dan moet ’n private hulpbron agter die bediener deur die tonnel antwoord. Aanstuur laat die tonnelverbinding in en niks meer nie; roetering en magtiging vir 10.8.0.0/24 is ’n ander instelling op ’n ander skerm.

Besluit met drie vrae

Drie vrae besleg die keuse vinniger as enige vergelykingstabel:

• Verbind iets van buite in, as die eerste pakkie? Gebruik dan aanstuur, of ’n aflos. Triggering kan nie oopgaan sonder uitgaande verkeer wat nooit sal bestaan nie.
• Moet die gat ledige tyd oorleef? Gebruik dan aanstuur, want ’n getriggerde kartering sluit op sy eie skedule.
• Is die WAN-adres joune om te publiseer? As dit nie is nie, regstel die laag hierbo voordat jy enige reël wysig.

As die antwoord op al drie nee is, wat die geval is vir ’n skootrekenaar wat na ’n kommersiële verskaffer uitbel, is geen van die reëls nodig nie. ’n Kliënt agter NAT werk omdat hy die toestandhoudende kartering self skep, en dit dek die meeste van die mense wat om middernag ’n poortaanstuur-bladsy lees.