Hvorfor LAN-et ditt ikke når en tjeneste på en VPN-klient

Tunnelen din er oppe, tjenesten lytter, og kontorets LAN får fortsatt ingenting tilbake. Ingen har ødelagt VPN-en. Fra LAN-siden finnes ikke tunneladressen til laptopen før noe forteller LAN-et hvordan det skal nå den, og svaret må komme tilbake samme vei som forespørselen gikk ut. Jeg har sett folk bygge opp igjen en helt frisk tunnel tre ganger før noen så på returveien.

Det er ikke tunnelen som er ødelagt

Begge ender sitter på private områder, som er det normale tilfellet og ikke en feilkonfigurasjon. En adresse som 10.8.0.6 er ekte inne i tunnelen og finnes ingen andre steder, så LAN-et har ingen grunn til å sende noe dit. Før du rører rutingen, bekreft at tjenesten i det hele tatt er tilgjengelig inne i tunnelen: på klienten viser ss -ltn om lytteren binder til 127.0.0.1, LAN-grensesnittet eller tunneladressen. En daemon som bare er bundet til loopback svarer ingen andre enn seg selv, og ingen rute, DNAT eller portvideresending endrer det.

En proxy på port 80 eller 443 er et annet verktøy med en annen synlighet. Den flytter forespørsler, ikke pakker, så den er feil lag for en rå databaseforbindelse, og å gripe etter den er hvordan dette problemet ender tre verktøy dypt før noen måler noe.

Ruteform: fortell LAN-et hvor puljen ligger

En statisk rute på LAN-gatewayen er det reneste svaret når LAN-et og tunnelpuljen ikke overlapper. Pek puljen mot maskinen som avslutter tunnelen:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Det reparerer bare én retning, og derfor ser halvferdige versjoner av denne endringen ut som fremgang. Tunnelsiden trenger den tilsvarende halvdelen, ellers forlater svaret klienten via sin egen standardrute og dør underveis:

push "route 192.168.1.0 255.255.255.0"

For et subnett som ligger bak én klient i stedet for bak serveren, trenger serveren både en systemrute og en iroute-oppføring i filen til den klienten under client-config-dir. Uten iroute vet OpenVPN at prefikset finnes, og har ingen anelse om hvilken klient som eier det: pakkene kommer inn, og daemonen har ingenting å matche dem mot.

Her er myten som fortjener et navn. En rute gjør en adresse tilgjengelig; den gjør ikke den andre siden villig til å svare. Site-til-site-partnere legger på et lag til, fordi den eksterne gatewayen bare godtar kilder innenfor prefiksene i policyen sin, og en laptop som kommer fra en hjemmepulje er ikke innenfor dem.

NAT-form: DNAT inn, og SNAT-linjen alle hopper over

Når du ikke kan røre LAN-gatewayen, eller du vil publisere nøyaktig én port, fungerer oversetting på VPN-verten uten noen rute på LAN-et i det hele tatt. Publiser porten, videresend den, og oversett kilden på veien inn i tunnelen:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Den tredje linjen er den som forsvinner. Hopp over den, og klienten ser den opprinnelige LAN-adressen som kilde, svarer via sin egen standardrute, og det svaret går inn i tunnelen i stedet for tilbake mot LAN-et. Om forbindelsen overlever avhenger da av ruting du aldri planla. Med SNAT ser klienten tunneladressen til serveren, så svaret følger tunnelen tilbake til den eneste verten som kan oppheve oversettingen.

Forbrukerfastvare bruker sine egne kjedenavn og genererer ikke den oversettingen for deg. På Tomato lander en innkommende regel i WANPREROUTING og deretter i en filterkjede som wanin, og et regelsett som ser komplett ut trenger fortsatt en manuell POSTROUTING-linje. Det er ikke en fastvarefeil; det er et regelsett skrevet bare for innkommende trafikk.

Hvorfor en regel som ser riktig ut likevel slipper pakken

De fleste av disse feilene sitter ikke i regelen du stirrer på. Sjekk fire ting i denne rekkefølgen, og stopp ved den første som ikke holder:

• Kjedeordenen. iptables -I setter inn øverst og -A legger til nederst, så en tidligere tillatende eller blokkerende regel avgjør først.
• Feil kjede. Trafikk adressert til ruteren selv går gjennom INPUT, og videresendt trafikk berører den aldri. Å publisere én tjeneste kan kreve regler i begge.
• Retningsflagg. -i tun0 matcher trafikk som kommer fra klienter, og -o tun0 trafikk som går mot dem. En REJECT med feil flagg blokkerer noe du ikke mente.
• Kildebegrensning. En videresending som godtar én klientadresse virker fra den klienten og slipper enhver annen kilde uten et ord.

En regel med en pakketeller på null er ikke på veien i det hele tatt, og å lese tellerne er den raskeste måten å skille et feil-kjede-problem fra et feil-regel-problem.

Den lokale videresendingen, når ingenting på LAN-et kan endres

En lokal SSH-videresending omgår hele spørsmålet. Den trenger ingen rute på LAN-et, ingen samarbeid fra klientens brannmur og ingen port publisert noe sted:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Tjenesten dukker da opp på localhost:3000 på maskinen som holder tunnelen, og ingen andre steder. Det er grensen: én arbeidsstasjon, én port, og videresendingen dør med økten med mindre noe starter den på nytt. For en administrator som sjekker en staging-database er det riktig verktøy. For et kamera eller en skanner som andre må nå, er det ikke, fordi hver bruker ville trengt sin egen videresending.

Bekreft begge retninger før du legger til en ny regel

Oversetting etterlater spor, og å lese dem slår å gjette. På VPN-verten viser conntrack -L om oversettingen skjedde i det hele tatt, iptables -t nat -L -n -v viser om tellerne flyttet seg, og tcpdump -ni any port 3000 viser hvilken kildeadresse som faktisk kom inn. På klienten bekrefter ss -ltn at lytteren er på en adresse tunnelen kan nå.

Velg så formen du beholder. Én publisert port, en rute for hele puljen og en videresending for én administrator er tre forskjellige forpliktelser, og å blande dem er hvordan et oppsett som virker blir ett ingen kan forklare seks måneder senere. Skriv ned hvilken adresse som er tilgjengelig hvorfra, og neste person som feilsøker dette starter ved svaret i stedet for ved tunnelen.