Nå ein teneste på ein VPN-klient: omvendt tunnel eller DNAT

Endå ein berbar PC bak NAT-en til leverandøren kan tene ein kollega, så lenge VPN-serveren er møteplassen. To mekanismar fører dit: klienten ringjer ut og ber serveren halde ein lyttande port, eller serveren publiserer ein port og omset han inn i tunnelen. Begge løyser det same tilgjengeproblemet og oppfører seg ulikt ved feil, overvaking og logging. Tre vilkår avgjer kva som høyrer heime i oppsettet ditt.

To former, éin møteplass

I den første forma opnar klienten ei SSH-økt utover og ber serveren lytte på ein vald port, og sender kvar tilkopling tilbake gjennom den økta. Ingenting vert vidaresend på serveren og inga pakkeomsetjing skjer, så dei einaste krava er ein SSH-konto, ei tillaten vidaresending og ein brannmurregel for porten. Tenesta vert verande bunden til loopback på klienten, som vanlegvis er det ein ønskjer.

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

I den andre forma eig serveren den offentlege porten og skriv om kvar tilkopling mot tunneladressa til klienten. Det krev IP-vidaresending slått på, ei omsetjing av mål på veg inn og ei omsetjing av kjelde på veg ut, og det held fram med å verke når det ikkje finst noka SSH-økt. Porten høyrer til serveren og ikkje til ei økt, og det er denne eigenskapen som avgjer dei fleste verkelege tilfella.

Ingen av formene er tryggare av natur. Begge endar med å leggje ein tenesteport open for alle som kan nå den offentlege adressa til serveren, og begge er framleis avhengige av autentiseringa til tenesta sjølv.

Vilkår éin: må porten leve lenger enn økta

Ei omvendt vidaresending lever nøyaktig så lenge som SSH-økta som oppretta ho. Når sambandet fell, forsvinn lyttaren og kollegaen ser ei avvist tilkopling i staden for ein treg veg. Overvaking av kommandoen med ei systemd-eining og ein omstartspolicy løyser det, og ExitOnForwardFailure=yes gjer ei mislukka binding synleg med ein gong i staden for å late att ei økt utan vidaresending.

Ein omsett port overlever omstartar om reglane vert lagra, men han er avhengig av at klienten held på den same tunneladressa. Ein dynamisk pool som gjev den berbare PC-en ei anna adresse etter attkopling, peikar regelen lydlaust mot ingenting. Reserver tunneladressa først, skriv så regelen, og handsam dei to som éi endring.

Viss tenesta må svare klokka tre om natta utan at nokon ser på, er forma med porten som serveren publiserer den med færrast bevegelege delar, fordi den einaste prosessen som må haldast i gang er sjølve tunnelen.

Vilkår to: kven eig brannmuren og loggarna

Den omvende forma held all politikk på to stader. sshd avgjer gjennom AllowTcpForwarding om fjernvidaresendingar i det heile er tillatne, og GatewayPorts avgjer om lyttaren bind til loopback eller til kvar adresse. Med standardverdien no kan ein kollega utanfor serveren ikkje nå porten sjølv om vidaresendinga lukkast, og det ser ut som ein øydelagd tunnel når det eigentleg er ei bindingsadresse.

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

Den omsette forma krev vidaresending slått på og to reglar, og den andre regelen er der dei fleste oppskriftene gjer feil. Å avgrense kjeldeomsetjinga til conntrack-tilstanden DNAT tyder at berre tilkoplingane som målregelen oppretta vert skrivne om, i staden for kvar pakke serveren sender inn i tunnelen.

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

Den omskrivinga øydelegg òg tilskrivinga. Etterpå ser klienten kvar anropar som tunneladressa til serveren, noko som klappar saman kvar hastigheitsgrense per adresse i éi bøtte og gøymer kven som sende kva. Viss tilskrivinga har noko å seie, avslutt tilkoplinga på serveren eller hald tillatingsavgjerda der og send ein identitet i ein header tenesta stolar på. Valet mellom desse to rettingane er avhengig av om tenesta i det heile les ein proxy-header.

Vilkår tre: éin port eller mange, og kven eig namnet

Éi teneste på éin port er tilfellet der omvend vidaresending vinn på innsats. Du treng éin kommando, éin konto og éin brannmurregel, og oppryddinga er å drepe økta. Fleire tenester på same offentlege adresse dyttar deg mot forma med porten serveren publiserer, fordi kvar omvend vidaresending treng sin eigen serverport og settet veks med kvar teneste.

Namn gjer det meir komplisert. Ei omvend vidaresending kan sitje bak ein TCP-proxy som rutar etter SNI, medan ein omsett port vanlegvis er éin port per teneste. Viss tenesta avsluttar TLS sjølv og treng det opphavlege vertsnamnet, bevarer proxy-tilnærminga det, og DNAT-tilnærminga bevarer det berre viss tenesta godtek det namnet på den porten.

Skriv ned kva av dei tre vilkåra som avgjorde forma. Elles vil den neste personen som legg til ei andre teneste opne same samanlikninga med mindre kontekst.

Bestem, og test så utanfrå

Test vegen frå eit nettverk som ikkje har noka rute til den berbare PC-en, og følg med på teljarane på serveren medan førespurnaden køyrer. Testing frå serveren mot hans eigen offentlege adresse beviser ingenting her, fordi pakken vert oppretta lokalt og aldri når inngangsomsetjingskroken, så testen kan gå gjennom medan den verkelege vegen er øydelagd.

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

Teljarar som står stille tyder at pakken aldri nådde regelen, noko som peikar på leverandøren eller brannmuren til verten. Teljarar som flyttar seg medan tenesta avviser, peikar på brannmuren til klienten sjølv eller adressa tenesta lyttar på. Ein tunnel som ber pakken men ikkje returnerer noko, er eit rute- eller returvegproblem, og ingen av desse tre utfalla bør feilsøkjast ved å redigere klientadapteren. Skriv ned kva teljar som flytta seg før du endrar noko, fordi den neste testen treng den grunnlinja.

Når forma verkar, før opp porten, eigaren og overvakingsmetoden ved sida av tunnelkonfigurasjonen. Ei tilgjengelegretting som berre finst i skallhistoria til nokon, er éin omstart unna ein gjenteke hending.