Hoe 'n OpenVPN-kliënt agter NAT die internet-uitgang word

Drie Linux-gashere, een ontwerp: 'n publiek bereikbare OpenVPN-hub, 'n verbruikerskootrekenaar en 'n uitgangsmasjien agter 'n gewone tuisrouter wat niks inkomend deurstuur nie. Die uitgang skakel self na die hub uit. Verbruikers se internetverkeer kom dan by die skootrekenaar die tonnel binne en verlaat dit deur die uitgang se eie opstroom. Alles verrassend aan hierdie opstelling volg uit een besonderheid: die uitgang het die verbinding begin, so die pad na binne bestaan reeds en geen poortdeurstuur is nodig om dit te skep nie.

Wat volg, volg die pakketpad eerder as die konfigurasievolgorde, want die konfigurasie maak eers sin sodra jy weet watter komponent watter besluit neem. Elke laag neem presies een besluit, en die foute klomp saam waar twee lae as dieselfde een beskou word.

Twee vervoersessies, een binnepad

Elke gasheer hou sy eie buitenste verbinding na die hub, en nie een van daardie verbindings weet van die ander nie. Die verbruiker se verkeer na die internet is 'n aparte binneste vloei wat toevallig binne die verbruiker se tonnel gedra en dan weer uit die uitgang se tonnel uitgestuur word. Daardie binneste vloei is wat die hub moet routeer, en dit is wat die uitgang moet deurstuur.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Omdat albei buitenste verbindings van die kliëntkant uitgaan, sien die uitgang se router nooit 'n inkomende SYN nie en het dit nooit 'n bestemming-NAT-reël nodig nie. Dit moet net die gevestigde vervoer lewendig hou, wat dit reeds vir enige langdurige verbinding doen. Niks op die publieke internet hoef eerste die uitgang te bereik nie, en daarom is 'n dinamiese adres op daardie opstroom geen probleem nie. Die router moet steeds die uitgaande sessie toelaat, maar dit is dieselfde toestemming wat 'n blaaier reeds gebruik.

Wat iroute werklik binne die bediener installeer

Die hub is die enigste toestel wat besluit watter eweknie watter bestemming besit, en hy neem daardie besluit in sy eie gebruikersruimte-roetingtabel, nie in die kern s'n nie. 'n client-config-dir-inskrywing vir die uitgang met die naam exit-node kan die verstekvoorvoegsel daar opeis:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Daardie reël sê vir die bedienerproses "binnerste pakkette met enige bestemming behoort aan hierdie kliënt". Dit voeg nie 'n verstekroete by die hub se bedryfstelsel nie, en dit maak nie die hub 'n internetpoort nie. Die OpenVPN 2.6-verwysing hou kliëntspesifieke interne roetering en kernroetering as aparte meganismes, en daardie skeiding is die rede waarom hierdie ontwerp werk sonder om die hub se verstekroete aan te raak.

Die verbruiker het die spieëlbeeld-instruksie nodig, as 'n push gelewer, sodat sy eie verkeer die tonnel binnegaan eerder as om deur sy plaaslike poort weg te gaan. Met subnet-topologie is die poel 'n gekoppelde roete op die uitgang se tun-toestel, so die terugrigting het geen ekstra push nodig nie; wat die uitgang nie mag ontvang nie, is die herleiding hieronder, wat sy eie opstroomverkeer terug in die tonnel sou stuur wat hy probeer gebruik. Stuur dit net na die verbruiker, en lees die toegepaste roetes op die kliënt in plaas daarvan om te vertrou dat die CCD-lêer gekies is.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

Die uitgang se kern doen die deurstuur

Binne die uitgang kom 'n pakket van die verbruiker op die tun-koppelvlak aan, geadresseer aan een of ander internetgasheer. Die kern raadpleeg sy roetingtabel, vind die werklike opstroom as die beste passing, en pas dan twee onafhanklike beleide toe: mag hierdie pakket hoegenaamd deurgestuur word, en mag dit deur daardie koppelvlak met daardie bronadres vertrek. Deurstuur is 'n sysctl, en dit is by verstek af op baie verspreidings.

Dus het die uitgang IPv4-deurstuur nodig wat aanhoudend geaktiveer is, 'n deurstuurreël wat die verbruiker se tonnelbronne na die opstroom toelaat, en die antwoordpad terug deur die tun. Om deurstuur vir die hele gasheer te aktiveer verander ook die gedrag van enigiets anders wat daardeur routeer, en daarom moet die reël die bronne en koppelvlakke noem eerder as om alles te aanvaar.

Bronvertaling is wat die terugpad koop

'n Internetgasheer het geen roete na 'n 10.90.0.x-adres nie, so antwoorde sou laat val word voordat hulle ooit die uitgang bereik. Om die bron te herskryf terwyl die pakket die opstroom verlaat, los dit op, en verbindingsnasporing draai die herskrywing op die terugpad om.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

Die reël hierbo is 'n beginpunt vir een opstroomkoppelvlak, nie 'n brandmuurbeleid nie. Vernou die bron tot die toekennings wat jy werklik gemagtig het, en hou die uitgang se eie insetbeleid apart sodat masquerading vir tonnelverkeer nie stilweg plaaslike dienste blootlê nie. Op 'n gasheer met 'n dinamiese opstroomadres spaar masquerade jou ook daarvan om die adres met die hand na te spoor.

Waar die hub kan en nie kan afdwing nie

Met client-to-client en die tradisionele gebruikersruimte-datapad gee die hub binnerste pakkette tussen eweknieë binne die bedienerproses oor. Hulle gaan nooit deur die hub se kern-FORWARD-ketting nie, so 'n kernreël daar kan nie eweknie-tot-eweknie-deurgang beperk nie, hoe sorgvuldig dit ook geskryf is. Afdwinging moet in die bediener se eie beleid woon: wie mag koppel, watter CCD-lêer hulle kry, en of die uitgang se verstek-eienaarskap hoegenaamd toegestaan word.

Dit is ook waarom 'n verstek-iroute 'n breë vertrouensbesluit is. Die uitgang moet wettiglik terugverkeer van willekeurige internetadresse aanvaar, en dit moet 'n masjien wees wat jy beheer, wat opgedateer en gemonitor word. Om dieselfde eienaarskap aan 'n eweknie aan wie jy nie 'n router sou toevertrou nie te gee, is die fout waartoe hierdie ontwerp uitnooi.

Lidmaatskap is die werklike beheer. Enige kliënt wat sy eie roetes kan konfigureer, kan probeer om die uitgang te gebruik, so om te beperk wie mag koppel, of watter eweknieë die uitgang sal bedien, is deel van die ontwerp eerder as 'n nagedagte.

Veilig misluk wanneer die uitgang verdwyn

Haal die uitgang vanlyn en die interne verstek-eienaarskap verdwyn saam met sy sessie. Wat nie mag gebeur nie, is dat die hub stilweg die vervangingsuitgang word: geen verstekroete van die VPN-poel na die hub se opstroom nie, en geen breë masquerade-reël op die hub wat dieselfde verkeer met graagte sou deurstuur nie. Toets daardie mislukking doelbewus, en toets dan herstel met 'n vars vloei eerder as 'n bladsy wat reeds oop was.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

As die verbruiker se verkeer steeds die internet bereik nadat die uitgang weg is, dra iets anders dit en bestaan die grens wat jy bedoel het nie. Hanteer DNS en IPv6 ook as aparte besluite: 'n IPv4-roete plus masquerade sê niks oor AAAA-verkeer nie, en 'n oplosser wat deur die hub gestuur word, sal antwoord van waar die navraag werklik vertrek.