Hoe't in OpenVPN-klant efter NAT de internetútgong wurdt

Trije Linux-hosts, ien ûntwerp: in iepenbier berikbere OpenVPN-hub, in ferbrûkerslaptop en in útgongmasine efter in gewoane thúsrouter dy't neat nei binnen trochstjoert. De útgong skillet sels de hub. Dan komt it internetferkear fan de ferbrûker by de laptop de tunnel yn en giet der troch de eigen uplink fan de útgong wer út. Alles fernuverjend oan dizze opset folget út ien detail: de útgong begûn de ferbining, dat it paad nei binnen bestiet al en der is gjin poartetrochstjoering nedich om it te meitsjen.

Wat folget, folget it paad fan it pakket ynstee fan de folchoarder fan de konfiguraasje, want de konfiguraasje hat pas sin as jo witte hokker komponint hokker beslút nimt. Eltse laach nimt krekt ien beslút, en de flaters sammelje har dêr't twa lagen as ien beskôge wurde.

Twa transportssesjes, ien ynterne paad

Elke host hâldt syn eigen bûtenste ferbining nei de hub, en gjinien fan dy ferbinings wit fan de oare. It ferkear fan de ferbrûker nei it internet is in aparte ynterne stream dy't tafallich yn 'e tunnel fan de ferbrûker droegen wurdt en dan wer út 'e tunnel fan de útgong útstjoerd wurdt. Dy ynterne stream moat de hub rûtele en dy moat de útgong trochstjoere.

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

Om't beide bûtenste ferbinings fan 'e kliïntkant út geane, sjocht de router fan de útgong nea in ynkommende SYN en hat er nea in bestimming-NAT-regel nedich. Hy moat allinnich it fêstige transport libben hâlde, wat er al docht foar elke langduorjende ferbining. Neat op it iepenbiere internet hoecht earst de útgong te berikken, dêrom is in dynamysk adres op dy uplink gjin probleem. De router moat noch altyd de útgeande sesje tastean, mar dat is deselde tastimming dy't in browser al brûkt.

Wat iroute eins yn 'e tsjinner ynstallearret

De hub is it ienige apparaat dat beslút hokker peer hokker bestimming hat, en hy nimt dat beslút yn syn eigen brûkersromte-rûtelearstabel, net yn dy fan 'e kernel. In client-config-dir-ynskriuwing foar de útgong mei de namme exit-node kin dêr it standertfoarheaksel opeaskje:

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

Dy rigel seit tsjin it tsjinnerproses "ynterne pakketten mei hokker bestimming dan ek hearre by dizze kliïnt". Hy foeget gjin standertrûte ta oan it bestjoeringssysteem fan 'e hub en makket de hub gjin internetpoarte. OpenVPN 2.6-referinsje hâldt kliïntspesifike ynterne rûtelearring en kernel-rûtelearring as aparte meganismen, en dy skieding is de reden dat dit ûntwerp wurket sûnder de standertrûte fan 'e hub oan te reitsjen.

De ferbrûker hat de spegelbyld-ynstruksje nedich, levere as push, sadat syn eigen ferkear de tunnel yngiet ynstee fan troch syn lokale poarte fuort te gean. By subnet-topology is de pool in ferbûne rûte op it tun-apparaat fan 'e útgong, dat de weromrjochting hat gjin ekstra push nedich; wat de útgong net krije mei is de omlieding hjirûnder, dy't syn eigen uplinkferkear weromstjoere soe nei de tunnel dy't er besiket te brûken. Stjoer it allinnich nei de ferbrûker en lês de tapaste rûtes op 'e kliïnt ynstee fan te fertrouwen dat it CCD-bestân keazen is.

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

De kernel fan 'e útgong docht it trochstjoeren

Yn 'e útgong komt in pakket fan 'e ferbrûker op 'e tun-ynterface oan, adressearre oan ien of oare internethost. De kernel rieplachtet syn rûtelearstabel, fynt de echte uplink as de bêste oerienkomst en past dan twa ûnôfhinklike beliedsregels ta: mei dit pakket hielendal trochstjoerd wurde, en mei it dy ynterface mei dat boarneadres ferlitte. Trochstjoeren is in sysctl, en it stiet by in protte distribúsjes standert út.

Dat hat de útgong IPv4-trochstjoeren nedich dat oanhâldend oan stiet, in trochstjoerregel dy't de tunnelboarnen fan 'e ferbrûker nei de uplink talit, en it antwurdpaad werom troch de tun. Trochstjoeren foar de hiele host oansette feroaret ek it gedrach fan al it oare dat der troch rûtelet, dêrom moat de regel de boarnen en ynterfaces neame ynstee fan alles te akseptearjen.

Boarne-oersetting is wat it werompaad keapet

In internethost hat gjin rûte nei in 10.90.0.x-adres, dat antwurden soene fuortgoaid wurde foar't se ea de útgong berikten. De boarne oerskriuwe wylst it pakket de uplink ferlit, lost dat op, en ferbiningsfolging draait de oerskriuwing op 'e weromweis 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

De regel hjirboppe is in begjinpunt foar ien uplink-ynterface, gjin firewallbelied. Behein de boarne ta de tawizings dy't jo echt autorisearre hawwe, en hâld it eigen ynfierbelied fan 'e útgong apart, sadat maskeraasje foar tunnelferkear lokale tsjinsten net stilwei bleatleit. Op in host mei in dynamysk uplinkadres besparret maskeraasje jo ek it adres mei de hân te folgjen.

Wêr't de hub hanthavenje kin en wêr't net

Mei client-to-client en it tradisjonele brûkersromte-datapaad jout de hub ynterne pakketten tusken peers binnen it tsjinnerproses oer. Se geane nea troch de kernel-FORWARD-ketting fan 'e hub, dat in kernelregel dêr kin it ferkear tusken peers net beheine, hoe soarchfâldich oft er ek skreaun is. Hanthavening moat yn it eigen belied fan 'e tsjinner libje: wa't ferbine mei, hokker CCD-bestân se krije en oft it standertbesit fan 'e útgong hielendal jûn wurdt.

Dêrom is in standert-iroute in breed fertrouwensbeslút. De útgong moat wetlik weromferkear fan willekeurige internetadressen akseptearje, en it moat in masine wêze dy't jo kontrolearje, bywurkje en monitorje. Deselde eigendom jaan oan in peer oan wa't jo gjin router jaan soene is de flater dêr't dit ûntwerp ta útnûget.

Lidmaatskip is de echte kontrôle. Eltse kliïnt dy't syn eigen rûtes konfigurearje kin, kin besykje de útgong te brûken, dat beheine wa't ferbine mei, of hokker peers de útgong tsjinje sil, is part fan it ûntwerp en gjin neitins.

Feilich mislearje as de útgong ferdwynt

Set de útgong offline en it ynterne standertbesit ferdwynt mei syn sesje. Wat net barre mei, is dat de hub stilwei de ferfangende útgong wurdt: gjin standertrûte fan 'e VPN-pool nei de uplink fan 'e hub, en gjin brede maskeraasjeregel op 'e hub dy't itselde ferkear grif trochstjoere soe. Test dy mislearring bewust, en test dan it werstel mei in frisse stream ynstee fan in side dy't al iepen wie.

# 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 it ferkear fan 'e ferbrûker nei it ferdwinen fan 'e útgong noch it internet berikt, dan draacht wat oars it en bestiet de grins dy't jo bedoelden net. Behannelje DNS en IPv6 ek as aparte besluten: in IPv4-rûte plus maskeraasje seit neat oer AAAA-ferkear, en in resolver dy't de hub treaun, sil antwurdzje fan wêr't de fraach eins fuortgiet.