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

Selv en bærbar PC bak leverandørens NAT kan betjene en kollega, så lenge VPN-serveren fungerer som møteplass. To mekanismer fører dit: klienten ringer ut og ber serveren holde en lyttende port, eller serveren publiserer en port og oversetter den inn i tunnelen. Begge løser det samme tilgjengelighetsproblemet og oppfører seg ulikt ved feil, overvåking og logging. Tre betingelser avgjør hvilken som hører hjemme i oppsettet ditt.

To former, én møteplass

I den første formen åpner klienten en SSH-økt utover og ber serveren lytte på en valgt port, og sender hver tilkobling tilbake gjennom den økten. Ingenting videresendes på serveren og ingen pakkeoversettelse skjer, så de eneste kravene er en SSH-konto, en tillatt videresending og en brannmurregel for porten. Tjenesten forblir bundet til loopback på klienten, som vanligvis er det man ønsker.

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

I den andre formen eier serveren den offentlige porten og skriver hver tilkobling om mot klientens tunneladresse. Det krever IP-videresending slått på, en destinasjonsoversettelse på vei inn og en kildeoversettelse på vei ut, og det fortsetter å virke når det ikke finnes noen SSH-økt. Porten tilhører serveren og ikke en økt, og det er denne egenskapen som avgjør de fleste virkelige tilfeller.

Ingen av formene er sikrere av natur. Begge ender med å eksponere én tjenesteport for alle som kan nå serverens offentlige adresse, og begge avhenger fortsatt av tjenestens egen autentisering.

Betingelse én: må porten leve lenger enn økten

En omvendt videresending lever nøyaktig så lenge som SSH-økten som opprettet den. Når forbindelsen faller, forsvinner lytteren og kollegaen ser en avvist tilkobling i stedet for en treg vei. Overvåking av kommandoen med en systemd-enhet og en omstartspolicy løser det, og ExitOnForwardFailure=yes gjør en mislykket binding synlig med en gang i stedet for å etterlate en økt uten videresending.

En oversatt port overlever omstarter hvis reglene lagres, men den avhenger av at klienten beholder samme tunneladresse. En dynamisk pool som gir den bærbare en annen adresse etter gjentilkobling, peker regelen lydløst mot ingenting. Reserver tunneladressen først, skriv deretter regelen, og behandl de to som én endring.

Hvis tjenesten må svare klokken tre om natten uten at noen ser på, er formen med serverens publiserte port den med færrest bevegelige deler, fordi den eneste prosessen som må holdes i gang er selve tunnelen.

Betingelse to: hvem eier brannmuren og loggene

Den omvendte formen holder all policy på to steder. sshd avgjør gjennom AllowTcpForwarding om fjernvideresendinger i det hele tatt er tillatt, og GatewayPorts avgjør om lytteren binder til loopback eller til hver adresse. Med standardverdien no kan en kollega utenfor serveren ikke nå porten selv om videresendingen lyktes, og det ser ut som en ødelagt tunnel når det egentlig er en bindingsadresse.

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

Den oversatte formen krever videresending slått på og to regler, og den andre regelen er der de fleste oppskrifter går galt. Å begrense kildeoversettelsen til conntrack-tilstanden DNAT betyr at bare tilkoblingene som destinasjonsregelen opprettet blir skrevet om, i stedet for hver 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 omskrivingen ødelegger også tilskrivningen. Etterpå ser klienten hver anroper som serverens tunneladresse, noe som kollapser enhver hastighetsgrense per adresse i én bøtte og skjuler hvem som sendte hva. Hvis tilskrivning betyr noe, avslutt tilkoblingen på serveren eller behold tillatelsesbeslutningen der og send en identitet i en header tjenesten stoler på. Valget mellom disse to rettelsene avhenger av om tjenesten i det hele tatt leser en proxy-header.

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

Én tjeneste på én port er tilfellet der omvendt videresending vinner på innsats. Du trenger én kommando, én konto og én brannmurregel, og oppryddingen er å drepe økten. Flere tjenester på samme offentlige adresse skyver deg mot formen med serverens publiserte port, fordi hver omvendt videresending trenger sin egen serverport og settet vokser med hver tjeneste.

Navn gjør det mer komplisert. En omvendt videresending kan sitte bak en TCP-proxy som ruter etter SNI, mens en oversatt port vanligvis er én port per tjeneste. Hvis tjenesten avslutter TLS selv og trenger det opprinnelige vertsnavnet, bevarer proxy-tilnærmingen det, og DNAT-tilnærmingen bevarer det bare hvis tjenesten godtar det navnet på den porten.

Skriv ned hvilken av de tre betingelsene som avgjorde formen. Ellers vil den neste personen som legger til en andre tjeneste gjenåpne samme sammenligning med mindre kontekst.

Bestem, og test deretter utenfra

Test veien fra et nettverk som ikke har noen rute til den bærbare, og følg med på tellerne på serveren mens forespørselen kjører. Testing fra serveren mot dens egen offentlige adresse beviser ingenting her, fordi pakken opprettes lokalt og aldri når inngangsoversettelseskroken, så testen kan bestå mens den virkelige veien er ødelagt.

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

Tellere som står stille betyr at pakken aldri nådde regelen, noe som peker på leverandøren eller vertens brannmur. Tellere som beveger seg mens tjenesten avviser, peker på klientens egen brannmur eller adressen tjenesten lytter på. En tunnel som bærer pakken men ikke returnerer noe, er et rute- eller returveiproblem, og ingen av disse tre utfallene bør feilsøkes ved å redigere klientadapteren. Skriv ned hvilken teller som flyttet seg før du endrer noe, fordi neste test trenger den baseline.

Når formen virker, registrer porten, eieren og overvåkingsmetoden ved siden av tunnelkonfigurasjonen. En tilgjengelighetsrettelse som bare finnes i noens skallhistorikk er én omstart unna en gjentatt hendelse.