VPN efter NAT dat jo net ynstelle kinne: wat noch al wurket

Elk tunnel-einpunt hat in adres en in poarte nedich dy't de oare kant berikke kin, en in router dy't jo net beheare is de gewoane reden dat dy eask mislearret. It nijsgjirrige part is net dat trúkjes besteane, mar dat elk ôfhinklik is fan in eigenskip fan in mappingstabel dy't jo net fan 'e klient ôf sjogge. Twa fan dy eigenskippen beslisse hast alles: hoe't in mapping makke wurdt, en oft it pakketten akseptearret fan in adres dêr't de binnenkant noait kontakt mei hân hat. Sortearje de omjouwing op dy eigenskippen en de omwegen hâlde op folkloare te wêzen.

De mappingstabel beslút alles

Netwurkadresomsetting hâldt in tabel by wêryn't in yntern adres en poarte tsjin in iepenbier adres en poarte fêstlein wurde. Antwurden dy't by in record passe wurde werom oerset, en in pakket dat fan bûten komt sûnder passend record hat hielendal gjin bestimming. Dat iene gedrach ferklearret wêrom't in harker efter de router net fan it ynternet berikber is. It ferklearret ek wêrom't it earste pakket yn elke rjochting fan binnen komme moat.

Sjoch nei de tabel fan 'e routerkant en de omwegen wurde fanselssprekkend: of wat makket in permanint record, of wat makket in tydlik ien en hâldt it farsk, of it ferkear nimt dy wei hielendal net. De rest fan dit artikel binne dy trije gefallen op folchoarder. Neat hjir ôfhinget fan in leveransiersfunksje bûten wat de tabel fêstleit.

Wat de moetsjinst wol en net kin

UDP-gatponsjen brûkt it útgeande record as in tydlike iepening ynstee fan it filter te ferslaan. Beide pearen nimme kontakt op mei in moetsjinst, dy't elk iepenbier einpunt leart en it einpunt fan 'e oare kant werom meldt. Dan stjoere beide nei elkoar ta, en elk útgeand pakket makket it record oan of ferfarsket it dat it antwurd binnenlit. De folchoarder is wat it wurkje lit, en de folchoarder is ek wat it kwetsber makket: in pear dat stjoert foardat de oare kant syn record makke hat, wurdt gewoan weilitten, wylst in nije poging in momint letter slagget. De tsjinst sels draacht gjin VPN-ferkear, dus syn iennichste hânfeting is de timing dy't er koördinearret.

Mappinggedrach beslút de rest, en RFC 4787 neamt de trije foarmen: einpuntûnôfhinklik, adresôfhinklik, en adres-en-poarte-ôfhinklik. By de lêste feroaret de poarte dy't in pear rjochtsje moat mei elke bestimming, dus foarsizzing is net mear betrouber. Dêr rint de technyk fêst, want carrier-grade NAT en in strang bedriuwsfirewall helje beide it foarsisberens fuort dat it skema nedich hat, en gjin hoefolle nije pogingen bringe dat werom.

Keepalives, werstarts en it einpunt dat beweecht

In trochstutsen paad is in stream en gjin harker, dus alles wat derop draait moat feroaring oerlibje. It moat de mapping libben hâlde mei periodyk ferkear, fernimme wannear't it iepenbiere einpunt beweecht, en wer opbouwe nei in werstart fan 'e router of it opnij tawizen fan it adres. Mesh-VPN-produkten sette dy logika yn har eigen kontrôleflak, wylst in gewoane server it oan jo oerlitten. Keepalives helpe allinnich salang't deselde mapping oerlibbet, en se kostje batterij op in mobile klient, dêrom is in agressyf ynterval net fergees.

In laptop dy't in oere sliept komt meastentiids werom op in oar iepenbier einpunt. Alles wat it paad wer opbouwt moat wer fan binnen rinne, wat deselde eask wer by de klient lizzen lit.

Trije manieren om in ûntbrekkende trochstjoering hinne

De earste manier freget de router it record sels oan te meitsjen, fia UPnP IGD, NAT-PMP of PCP, as de funksje bestiet en oan stiet. De twadde jout it ferkear oan in relay mei in iepenbier adres, dat altyd wurket en altyd banbreedte plus in oare fertrouwensgrins kostet. De tredde keart de rjochting om: de ynterne host iepenet in útgeande tunnel nei in iepenbiere server en al it oare rydt dêr binnen.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

In relay-einpunt makket dy ruil sichtber yn 'e klientkonfiguraasje, wêr't it einpunt in relay is en net it eigen adres fan in pear. Oanhâldende keepalive hâldt de mapping waarm, en de tastiene foarheaksels beslisse wat de klient deroer stjoere mei. In omkearde tunnel fan 'e ynterne host is itselde idee mei in oare eigner, en it freget hielendal gjin NAT-feroaring. Elk fan 'e trije hellet de ynkommende eask fuort sûnder in firewall te ferslaan dy't ûnfrege ferkear neffens ûntwerp blokkearret, want it ferkear begjint noch altyd binnen.

Pas de omwei oan by wa't de router hat

As jo de router beheare, is in statyske UDP-trochstjoering makliker te auditearjen as hokker gatponsmetoade dan ek en mislearret er op manieren dy't jo sjogge. As jo dat net dogge, sykje dan út oft de leveransier in relay of in hosted kontrôleflak biedt, en oft belied it gebrûk dêrfan tastean soe. As gjin fan beide beskikber is, binne de oerbliuwende karren in omkearde tunnel of akseptearje dat it einpunt net fan bûten berikber is. Fêstlizze hokker jo brûkt hawwe is wichtiger as it klinkt, want de opsjes ferskille yn wa't it ferkear observearje kin en wat der bart as in tredde partij wat feroaret.

Tink derom oft it paad dat jo úteinlik hiene direkt wie of fia in relay, want dat iene feit foarseit sawol fertraging as gedrach by falen. RFC 4787 bliuwt de referinsje foar it mappinggedrach dat dêrûnder sit, en syn mappingseksje lêze is flugger as trije omwegen op folchoarder testen. De tabel kin it neat skele hokker opsje jo keazen hawwe; hy registrearret allinnich wat it folgjende pakket dwaan mei.