Kiel OpenVPN-kliento malantaŭ NAT fariĝas la interreta elirejo

Tri Linux-gastigantoj, unu dezajno: publike atingebla OpenVPN-centro, konsuma tekkomputilo kaj elireja maŝino malantaŭ ordinara hejma enkursigilo, kiu plusendas nenion enen. La elirejo mem alvokas la centron. Poste la interreta trafiko de la konsumanto eniras la tunelon ĉe la tekkomputilo kaj eliras tra la propra suprenligo de la elirejo. Ĉio surpriza en ĉi tiu aranĝo sekvas el unu detalo: la elirejo iniciatis la konekton, do la vojo enen jam ekzistas kaj neniu pordoadapto necesas por krei ĝin.

La sekvaĵo spuras la vojon de la paketo anstataŭ la ordon de la agordo, ĉar la agordo havas sencon nur kiam vi scias, kiu komponanto posedas kiun decidon. Ĉiu tavolo posedas precize unu decidon, kaj la eraroj amasiĝas tie, kie du tavoloj estas supozataj unu.

Du transportaj sesioj, unu interna vojo

Ĉiu gastiganto tenas sian propran eksteran konekton al la centro, kaj neniu el tiuj konektoj scias pri la alia. La trafiko de la konsumanto al la interreto estas aparta interna fluo, kiu hazarde portiĝas ene de la tunelo de la konsumanto kaj poste ree elsendiĝas el la tunelo de la elirejo. Tiun internan fluon la centro devas enkursigi, kaj ĝin la elirejo devas plusendi.

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

Ĉar ambaŭ eksteraj konektoj estas elirantaj de la klienta flanko, la enkursigilo de la elirejo neniam vidas envenan SYN kaj neniam bezonas regulon pri celNAT. Ĝi nur devas teni la establitan transporton viva, kion ĝi jam faras por ĉiu longdaŭra konekto. Nenio en la publika interreto devas unue atingi la elirejon, tial dinamika adreso sur tiu suprenligo ne estas problemo. La enkursigilo ankoraŭ devas permesi la elirantan sesion, sed tio estas la sama permeso, kiun retumilo jam uzas.

Kion iroute efektive instalas ene de la servilo

La centro estas la sola aparato, kiu decidas, kiu samtavolano posedas kiun celon, kaj ĝi faras tiun decidon en sia propra uzantspaca enkursiga tabelo, ne en tiu de la kerno. client-config-dir-rikmdato por la elirejo nomata exit-node povas postuli la defaŭltan prefikson tie:

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

Tiu linio diras al la servila procezo "internaj paketoj kun iu ajn celo apartenas al ĉi tiu kliento". Ĝi ne aldonas defaŭltan vojon al la operaciumo de la centro kaj ne faras la centron interreta pordego. OpenVPN 2.6-referenco tenas klient-specifan internan enkursigadon kaj kernan enkursigadon kiel apartajn mekanismojn, kaj tiu apartigo estas la kialo, ke la dezajno funkcias sen tuŝi la defaŭltan vojon de la centro.

La konsumanto bezonas la spegulan instrukciojn, liveritan kiel push, por ke ĝia propra trafiko eniru la tunelon anstataŭ eliri tra ĝia loka pordego. Kun subreta topologio la naĝejo estas konektita vojo sur la tun-aparato de la elirejo, do la revena direkto bezonas neniun plian push; kion la elirejo ne rajtas ricevi estas la alidirektado sube, kiu resendus ĝian propran suprenligan trafikon reen en la tunelon, kiun ĝi provas uzi. Sendu ĝin nur al la konsumanto kaj legu la aplikitajn vojojn sur la kliento anstataŭ fidi, ke la CCD-dosiero estis elektita.

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

La kerno de la elirejo faras la plusendadon

Ene de la elirejo paketo de la konsumanto alvenas sur la tun-interfaco adresita al iu interreta gastiganto. La kerno konsultas sian enkursigan tabelon, trovas la veran suprenligon kiel la plej bonan kongruon kaj poste aplikas du sendependajn politikojn: ĉu tiu paketo entute rajtas esti plusendata, kaj ĉu ĝi rajtas eliri tra tiu interfaco kun tiu fonta adreso. Plusendado estas sysctl, kaj ĝi estas defaŭlte malŝaltita en multaj distribuaĵoj.

Do la elirejo bezonas daŭre ŝaltitan IPv4-plusendadon, plusendan regulon, kiu enlasas la tunelajn fontojn de la konsumanto al la suprenligo, kaj la respondan vojon reen tra la tun. Ŝalti plusendadon por la tuta gastiganto ankaŭ ŝanĝas la konduton de ĉio alia, kio enkursiĝas tra ĝi, tial la regulo nomu la fontojn kaj interfacojn anstataŭ akcepti ĉion.

Fonta tradukado estas tio, kio aĉetas la revenan vojon

Interreta gastiganto havas neniun vojon al adreso 10.90.0.x, do respondoj estus forĵetitaj antaŭ ol ili iam atingus la elirejon. Reskribi la fonton dum la paketo forlasas la suprenligon solvas tion, kaj konekta spurmo maligas la reskribon sur la revena vojo.

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

La regulo supre estas komencpunkto por unu suprenliga interfaco, ne fajroŝirma politiko. Mallarĝigu la fonton al la taskoj, kiujn vi efektive rajtigis, kaj tenu la propran envenan politikon de la elirejo aparte, por ke maskado de tunela trafiko ne mallaŭte elmontru lokajn servojn. Sur gastiganto kun dinamika suprenliga adreso, maskado ankaŭ ŝparas al vi la manan spuradon de la adreso.

Kie la centro povas devigi kaj kie ne

Kun client-to-client kaj la tradicia uzantspaca datenvojo, la centro transdonas internajn paketojn inter samtavolanoj ene de la servila procezo. Ili neniam trapasas la FORWARD-ĉenon de la centro-kerno, do kerna regulo tie ne povas limigi samtavolan transiton, kiel ajn zorge ĝi estas skribita. Devigo devas vivi en la propra politiko de la servilo: kiu rajtas konekti, kiun CCD-dosieron li ricevas, kaj ĉu la defaŭlta posedo de la elirejo entute estas donata.

Tial ankaŭ defaŭlta iroute estas larĝa fido-decidaĵo. La elirejo devas laŭleĝe akcepti revenan trafikon de arbitraj interretaj adresoj, kaj ĝi devas esti maŝino, kiun vi kontrolas, flikas kaj observas. Diri la saman posedon al samtavolano, al kiu vi ne donus enkursigilon estas la eraro, al kiu ĉi tiu dezajno invitas.

Membreco estas la vera regado. Ĉiu kliento, kiu povas agordi siajn proprajn vojojn, povas provi uzi la elirejon, do limigi, kiu rajtas konekti, aŭ kiujn samtavolanojn la elirejo servos, estas parto de la dezajno, ne postpenso.

Sekure malsukcesi, kiam la elirejo malaperas

Malŝaltu la elirejon kaj la interna defaŭlta posedo malaperas kun ĝia sesio. Kio ne rajtas okazi estas, ke la centro silento fariĝu la anstataŭa elirejo: nenia defaŭlta vojo de la VPN-naĝejo al la suprenligo de la centro kaj nenia larĝa maskada regulo sur la centro, kiu volonte plusendus la saman trafikon. Testu tiun malsukceson intence, poste testu reakiron per freŝa fluo anstataŭ per paĝo, kiu jam estis malfermita.

# 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

Se la trafiko de la konsumanto ankoraŭ atingas la interreton post kiam la elirejo foriris, io alia portas ĝin kaj la limo, kiun vi intencis, ne ekzistas. Traktu DNS kaj IPv6 ankaŭ kiel apartajn decidojn: IPv4-vojo plus maskado diras nenion pri AAAA-trafiko, kaj solvilo puŝita de la centro respondos de kie la demando efektive eliras.