Dostop do storitve na odjemalcu VPN: obrnjen tunel ali DNAT

Tudi prenosnik za NAT operaterja lahko streže sodelavcu, če je strežnik VPN stičišče. Tja vodita dva mehanizma: odjemalec se poveže navzven in prosi strežnik, naj drži poslušalna vrata, ali strežnik objavi vrata in jih prevede v tunel. Oba rešujeta isto težavo dosegljivosti in se ob napaki, nadzoru in beleženju obnašata različno. Trije pogoji odločijo, kateri sodi v vašo nastavitev.

Dve obliki, eno stičišče

V prvi obliki odjemalec odpre sejo SSH navzven in prosi strežnik, naj posluša na izbranih vratih, pri čemer vsako povezavo pošlje nazaj po tej seji. Na strežniku se nič ne posreduje in ne poteka prevajanje paketov, zato so edine zahteve račun SSH, dovoljeno posredovanje in pravilo požarnega zidu za vrata. Storitev ostane vezana na loopback na odjemalcu, kar je običajno tisto, kar želite.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

V drugi obliki ima javna vrata strežnik in prepiše vsako povezavo proti naslovu tunela odjemalca. To zahteva omogočeno posredovanje IP, prevajanje cilja na vhodu in prevajanje vira na izhodu, in deluje naprej, ko ni nobene seje SSH. Vrata pripadajo strežniku in ne seji, in prav ta lastnost odloči večino resničnih primerov.

Nobena oblika ni sama po sebi varnejša. Obe na koncu izpostavita ena vrata storitve vsakomur, ki doseže javni naslov strežnika, in obe sta še vedno odvisni od lastnega preverjanja pristnosti storitve.

Prvi pogoj: morajo vrata preživeti sejo

Obrnjeno posredovanje živi natanko toliko, kolikor traja seja SSH, ki ga je ustvarila. Ko povezava pade, poslušalec izgine in sodelavec vidi zavrnjeno povezavo namesto počasne poti. Nadzor nad ukazom z enoto systemd in politiko ponovnega zagona to reši, ExitOnForwardFailure=yes pa naredi neuspešno vezavo takoj vidno, namesto da bi pustil sejo brez posredovanja.

Prevedena vrata preživijo ponovne zagone, če so pravila trajno shranjena, vendar so odvisna od tega, ali odjemalec obdrži isti naslov tunela. Dinamični nabor, ki prenosniku po ponovni povezavi dodeli drug naslov, tiho usmeri pravilo v prazno. Najprej rezervirajte naslov tunela, nato napišite pravilo, in obravnavajte oboje kot eno spremembo.

Če mora storitev odgovarjati ob treh zjutraj brez nikogar, ki bi gledal, ima oblika z vrati, ki jih objavi strežnik, manj gibljivih delov, ker je edini proces, ki mora ostati v teku, sam tunel.

Drugi pogoj: komu pripadajo požarni zid in dnevniki

Obrnjena oblika drži vso politiko na dveh mestih. sshd prek AllowTcpForwarding odloči, ali so oddaljena posredovanja sploh dovoljena, GatewayPorts pa odloči, ali se poslušalec veže na loopback ali na vsak naslov. S privzeto vrednostjo no sodelavec zunaj strežnika ne doseže vrat, čeprav je posredovanje uspelo, in to je videti kot pokvarjen tunel, v resnici pa je naslov vezave.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

Prevedena oblika potrebuje omogočeno posredovanje in dve pravili, in drugo pravilo je tisto, kjer se večina receptov zmoti. Omejitev prevajanja vira na stanje conntrack DNAT pomeni, da se prepišejo le povezave, ki jih je ustvarilo pravilo cilja, namesto vsakega paketa, ki ga strežnik pošlje v tunel.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

To prepisovanje uniči tudi pripisovanje. Po njem odjemalec vidi vsakega klicatelja kot naslov tunela strežnika, kar stisne vsako omejitev hitrosti na naslov v eno vedro in skrije, kdo je kaj poslal. Če je pripisovanje pomembno, končajte povezavo na strežniku ali tam obdržite odločitev o dovoljenju in posredujte identiteto v glavi, ki ji storitev zaupa. Izbira med tema dvema popravkoma je odvisna od tega, ali storitev sploh bere glavo proxyja.

Tretji pogoj: ena vrata ali mnogo, in komu pripada ime

Ena storitev na enih vratih je primer, ko obrnjeno posredovanje zmaga pri trudu. Potrebujete en ukaz, en račun in eno pravilo požarnega zidu, čiščenje pa je ubijanje seje. Več storitev na istem javnem naslovu vas potisne proti obliki, ki jo objavi strežnik, ker vsako obrnjeno posredovanje potrebuje svoja strežniška vrata in nabor raste z vsako storitvijo.

Imena to še zapletejo. Obrnjeno posredovanje je lahko za proxyjem TCP, ki usmerja po SNI, medtem ko so prevedena vrata običajno ena vrata na storitev. Če storitev sama zaključi TLS in potrebuje izvorno ime gostitelja, ga pristop s proxyjem ohrani, pristop z DNAT pa ga ohrani le, če storitev to ime sprejme na teh vratih.

Zapišite, kateri od treh pogojev je odločil obliko. Sicer bo naslednja oseba, ki bo dodala drugo storitev, znova odprla isto primerjavo z manj konteksta.

Odločite in nato preizkusite od zunaj

Preizkusite pot iz omrežja, ki nima nobene poti do prenosnika, in opazujte števce na strežniku, medtem ko zahteva teče. Preizkušanje s strežnika na njegov lastni javni naslov tu nič ne dokaže, ker paket nastane lokalno in nikoli ne doseže vhodnega kavlja za prevajanje, zato lahko test uspe, medtem ko je resnična pot pokvarjena.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Števci, ki ostanejo ravni, pomenijo, da paket nikoli ni dosegel pravila, kar kaže na ponudnika ali požarni zid gostitelja. Števci, ki se premikajo, medtem ko storitev zavrača, kažejo na lastni požarni zid odjemalca ali naslov, na katerem storitev posluša. Tunel, ki prenaša paket, a ne vrne ničesar, je težava poti ali povratne poti, in nobenega od teh treh izidov ne bi smeli razhroščevati z urejanjem vmesnika odjemalca. Zapišite, kateri števec se je premaknil, preden karkoli spremenite, ker naslednji test potrebuje to izhodišče.

Ko oblika deluje, zabeležite vrata, lastnika in metodo nadzora ob konfiguraciji tunela. Popravek dosegljivosti, ki obstaja le v nečiji zgodovini lupine, je en ponovni zagon stran od ponovljenega dogodka.