Atingi servon ĉe VPN-kliento: inversa tunelo aŭ DNAT

Eĉ tekokomputilo malantaŭ la NAT de provizanto povas servi kolegon, kondiĉe ke la VPN-servilo rolas kiel renkontiĝejo. Du mekanismoj kondukas tien: la kliento elvokas kaj petas la servilon teni aŭskultan pordon, aŭ la servilo publikigas pordon kaj tradukas ĝin en la tunelon. Ambaŭ solvas la saman atingeblan problemon kaj kondutas malsame ĉe paneo, prizorgado kaj protokolado. Tri kondiĉoj decidas, kiu apartenas al via agordo.

Du formoj, unu renkontiĝejo

En la unua formo la kliento malfermas SSH-sesion eksteren kaj petas la servilon aŭskulti sur elektita pordo, plusendante ĉiun konekton reen tra tiu sesio. Nenio plusendiĝas ĉe la servilo kaj neniu paketa traduko okazas, do la solaj postuloj estas SSH-konto, permesita plusendo kaj fajroŝirma regulo por la pordo. La servo restas ligita al loopback ĉe la kliento, kio kutime estas tio, kion vi volas.

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

En la dua formo la servilo posedas la publikan pordon kaj reskribas ĉiun konekton al la tunela adreso de la kliento. Tio postulas aktivigitan IP-plusendon, celan tradukon enire kaj fontan tradukon elire, kaj ĝi daŭre funkcias kiam neniu SSH-sesio ekzistas. La pordo apartenas al la servilo kaj ne al sesio, kaj tiu eco decidas la plej multajn realajn kazojn.

Neniu el la du formoj estas pli sekura pro sia konstruo. Ambaŭ finas per elmeti unu servan pordon al kiu ajn povas atingi la publikan adreson de la servilo, kaj ambaŭ ankoraŭ dependas de la propra aŭtentigo de la servo.

Kondiĉo unu: ĉu la pordo devas vivi pli longe ol la sesio

Inversa plusendo vivas ĝuste tiom longe kiom la SSH-sesio, kiu kreis ĝin. Kiam la ligilo falas, la aŭskultanto malaperas kaj la kolego vidas rifuzitan konekton anstataŭ malrapidan vojon. Prizorgi la komandon per systemd-unuo kaj restartiga politiko solvas tion, kaj ExitOnForwardFailure=yes igas malsukcesan ligadon tuj videbla anstataŭ lasi sesion sen plusendo.

Tradukita pordo postvivas restartojn se la reguloj estas konservitaj, sed ĝi dependas de tio, ke la kliento konservu la saman tunelan adreson. Dinamika baseno, kiu donas al la tekokomputilo alian adreson post rekonekto, silente direktas la regulon al nenio. Rezervu unue la tunelan adreson, poste skribu la regulon, kaj traktu la du kiel unu ŝanĝon.

Se la servo devas respondi je la tria nokte sen iu observanta, la formo kun la servile publikigita pordo havas malpli da moviĝantaj partoj, ĉar la sola procezo, kiu devas resti aktiva, estas la tunelo mem.

Kondiĉo du: kiu posedas la fajroŝirmilon kaj la protokolojn

La inversa formo tenas la tutan politikon en du lokoj. sshd decidas, ĉu remotaj plusendoj tute permesatas per AllowTcpForwarding, kaj GatewayPorts decidas, ĉu la aŭskultanto ligiĝas al loopback aŭ al ĉiu adreso. Kun la defaŭlta no kolego ekster la servilo ne povas atingi la pordon eĉ se la plusendo sukcesis, kaj tio aspektas kiel rompita tunelo, kiam ĝi fakte estas liga adreso.

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

La tradukita formo bezonas aktivigitan plusendon kaj du regulojn, kaj la dua regulo estas kie plej multaj receptoj eraras. Limigi la fontan tradukon al la conntrack-stato DNAT signifas, ke nur la konektoj kreitaj de la cela regulo reskribiĝas, anstataŭ ĉiu paketo, kiun la servilo sendas en la tunelon.

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

Tiu reskribo ankaŭ detruas atribuon. Poste la kliento vidas ĉiun alvokanton kiel la tunelan adreson de la servilo, kio kunfalas ĉiun laŭ-adresan tarifan limon en unu korbo kaj kaŝas, kiu sendis kion. Se atribuo gravas, finu la konekton ĉe la servilo aŭ lasu la permesan decidon tie kaj transdonu identecon en kaplinio, kiun la servo fidas. Elekti inter tiuj du riparoj dependas de tio, ĉu la servo entute legas prokuran kaplinion.

Kondiĉo tri: unu pordo aŭ multaj, kaj kiu posedas la nomon

Unu servo sur unu pordo estas la kazo, kie la inversa plusendo venkas laŭ peno. Vi bezonas unu komandon, unu konton kaj unu fajroŝirman regulon, kaj purigado estas mortigi la sesion. Pluraj servoj sur la sama publika adreso puŝas vin al la servile publikigita formo, ĉar ĉiu inversa plusendo bezonas sian propran servilan pordon kaj la aro kreskas kun ĉiu servo.

Nomoj plikomplikigas ĝin. Inversa plusendo povas sidi malantaŭ TCP-prokuro, kiu enkursigas laŭ SNI, dum tradukita pordo kutime estas unu pordo por servo. Se la servo mem finas TLS kaj bezonas la originan gastigantan nomon, la prokura aliro konservas ĝin, kaj la DNAT-alira konservas ĝin nur se la servo akceptas tiun nomon sur tiu pordo.

Notu, kiu el la tri kondiĉoj decidis la formon. Alie la sekva persono, kiu aldonos duan servon, remalfermos la saman komparon kun malpli da kunteksto.

Decidu, poste testu de ekstere

Testu la vojon el reto, kiu havas neniun itineron al la tekokomputilo, kaj observu la nombrilojn ĉe la servilo dum la peto ruliĝas. Testi de la servilo al sia propra publika adreso pruvas nenion ĉi tie, ĉar la paketo kreiĝas loke kaj neniam atingas la envenan tradukan hokon, do la testo povas sukcesi dum la reala vojo estas rompita.

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

Nombriloj, kiuj restas ebenaj, signifas, ke la paketo neniam alvenis al la regulo, kio indikas la provizanton aŭ la gastigan fajroŝirmilon. Nombriloj, kiuj moviĝas dum la servo rifuzas, indikas la propran fajroŝirmilon de la kliento aŭ la adreson, sur kiu la servo aŭskultas. Tunelo, kiu portas la paketon sed redonas nenion, estas itinera aŭ revenvoja problemo, kaj neniu el tiuj tri rezultoj devus esti sencimigata per redaktado de la klienta adaptilo. Notu, kiu nombrilo moviĝis antaŭ ol vi ŝanĝos ion, ĉar la sekva testo bezonas tiun bazlinion.

Kiam la formo funkcias, registru la pordon, la posedanton kaj la prizorgan metodon apud la tunela agordo. Atingebleca riparo, kiu ekzistas nur en ies ŝela historio, estas unu restarto for de ripetiĝanta okazaĵo.