Nå en tjeneste på en VPN-klient: omvendt tunnel eller DNAT

Selv en bærbar computer bag udbyderens NAT kan betjene en kollega, så længe VPN-serveren fungerer som mødested. To mekanismer fører dertil: klienten ringer ud og beder serveren holde en lyttende port, eller serveren offentliggør en port og oversætter den ind i tunnelen. Begge løser det samme tilgængelighedsproblem og opfører sig forskelligt ved fejl, overvågning og logning. Tre betingelser afgør, hvilken der hører til din opsætning.

To former, ét mødested

I den første form åbner klienten en SSH-session udad og beder serveren lytte på en valgt port, mens hver forbindelse sendes tilbage gennem den session. På serveren videresendes intet, og der sker ingen pakkeoversættelse, så de eneste krav er en SSH-konto, en tillad videresendelse og en firewallregel for porten. Tjenesten forbliver bundet til loopback på klienten, hvilket normalt er det, du ønsker.

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

I den anden form ejer serveren den offentlige port og omskriver hver forbindelse mod klientens tunneladresse. Det kræver IP-videresendelse slået til, en destinationsoversættelse på vej ind og en kildeoversættelse på vej ud, og det bliver ved med at virke, når der ikke findes nogen SSH-session. Porten tilhører serveren og ikke en session, og det er den egenskab, der afgør de fleste virkelige tilfælde.

Ingen af formerne er mere sikker af natur. Begge ender med at udsætte én tjenesteport for alle, der kan nå serverens offentlige adresse, og begge afhænger stadig af tjenestens egen godkendelse.

Betingelse et: skal porten leve længere end sessionen

En omvendt videresendelse lever præcis så længe som den SSH-session, der oprettede den. Når forbindelsen falder, forsvinder lytteren, og kollegaen ser en afvist forbindelse i stedet for en langsom vej. Overvågning af kommandoen med en systemd-enhed og en genstartspolitik løser det, og ExitOnForwardFailure=yes gør en mislykket binding synlig med det samme i stedet for at efterlade en session uden videresendelse.

En oversat port overlever genstarter, hvis reglerne gemmes, men den afhænger af, at klienten beholder samme tunneladresse. En dynamisk pulje, der giver den bærbare en anden adresse efter en genopkobling, peger lydløst reglen på ingenting. Reserver tunneladressen først, skriv derefter reglen, og behandl de to som én ændring.

Hvis tjenesten skal svare klokken tre om natten uden nogen til at kigge, er formen med serverens offentliggjorte port den med færrest bevægelige dele, fordi den eneste proces, der skal køre, er selve tunnelen.

Betingelse to: hvem ejer firewallen og logfilerne

Den omvendte form holder hele politikken på to steder. sshd afgør, om fjernvideresendelser overhovedet er tilladt gennem AllowTcpForwarding, og GatewayPorts afgør, om lytteren binder til loopback eller til hver adresse. Med standardværdien no kan en kollega uden for serveren ikke nå porten, selv om videresendelsen lykkedes, og det ligner en brudt tunnel, når det i virkeligheden er en bindingsadresse.

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

Den oversatte form kræver videresendelse slået til og to regler, og den anden regel er der, hvor de fleste opskrifter går galt. At begrænse kildeoversættelsen til conntrack-tilstanden DNAT betyder, at kun de forbindelser, som destinationsreglen oprettede, bliver omskrevet, i stedet for hver pakke, serveren sender ind 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 omskrivning ødelægger også tilskrivningen. Derefter ser klienten enhver opkalder som serverens tunneladresse, hvilket kollapser enhver hastighedsgrænse pr. adresse i én spand og skjuler, hvem der sendte hvad. Hvis tilskrivning betyder noget, afslut forbindelsen på serveren eller behold tilladelsesbeslutningen der og send en identitet i et header, som tjenesten stoler på. Valget mellem de to rettelser afhænger af, om tjenesten overhovedet læser et proxy-header.

Betingelse tre: én port eller mange, og hvem ejer navnet

Én tjeneste på én port er det tilfælde, hvor den omvendte videresendelse vinder på arbejdsindsats. Du har brug for én kommando, én konto og én firewallregel, og oprydningen er at dræbe sessionen. Flere tjenester på samme offentlige adresse skubber dig mod formen med serverens offentliggjorte port, fordi hver omvendt videresendelse har brug for sin egen serverport, og sættet vokser med hver tjeneste.

Navne gør det mere kompliceret. En omvendt videresendelse kan sidde bag en TCP-proxy, der ruter efter SNI, mens en oversat port normalt er én port pr. tjeneste. Hvis tjenesten selv afslutter TLS og har brug for det oprindelige værtsnavn, bevarer proxy-tilgangen det, og DNAT-tilgangen bevarer det kun, hvis tjenesten accepterer det navn på den port.

Skriv ned, hvilken af de tre betingelser der afgjorde formen. Ellers vil den næste person, der tilføjer en anden tjeneste, genåbne den samme sammenligning med mindre kontekst.

Beslut, og test derefter udefra

Test vejen fra et netværk, der ikke har nogen rute til den bærbare, og hold øje med tællerne på serveren, mens anmodningen kører. Test fra serveren mod dens egen offentlige adresse beviser intet her, fordi pakken oprettes lokalt og aldrig når indgangsoversættelseskrogen, så testen kan bestå, mens den virkelige vej er brudt.

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

Tællere, der står stille, betyder, at pakken aldrig nåede reglen, hvilket peger på udbyderen eller værtens firewall. Tællere, der bevæger sig, mens tjenesten afviser, peger på klientens egen firewall eller den adresse, tjenesten lytter på. En tunnel, der bærer pakken men intet returnerer, er et rute- eller returvejsproblem, og ingen af disse tre udfald bør fejlfindes ved at redigere klientadapteren. Skriv ned, hvilken tæller der flyttede sig, før du ændrer noget, fordi den næste test har brug for den baseline.

Når formen virker, skal du registrere porten, ejeren og overvågningsmetoden ved siden af tunnelkonfigurationen. En tilgængelighedsrettelse, der kun findes i nogens shell-historik, er en genstart væk fra en gentagen hændelse.