Hvorfor dit LAN ikke kan nå en tjeneste på en VPN-klient

En VPN-klient kan være vært for en tjeneste, som LAN'et ikke kan åbne. Det, der mangler, er som regel returvejen: én rute, et DNAT-par eller den SNAT-linje, som ingen tilføjer.

Din tunnel er oppe, tjenesten lytter, og kontorets LAN får stadig intet tilbage. Ingen har ødelagt VPN'en. Fra LAN-siden findes laptopens tunneladresse ikke, før noget fortæller LAN'et, hvordan det kan nå den, og svaret skal komme tilbage den samme vej, som anmodningen gik ud. Jeg har set folk genopbygge en fuldstændig funktionsdygtig tunnel tre gange, før nogen kiggede på returvejen.

Det er ikke tunnelen, der gik i stykker

Begge ender sidder på private områder, hvilket er det normale tilfælde og ikke en fejlkonfiguration. En adresse som 10.8.0.6 er reel inde i tunnelen og findes ingen andre steder, så LAN'et har ingen grund til at sende noget derhen. Før du rører ved routing, så bekræft, at tjenesten overhovedet er tilgængelig inde i tunnelen: på klienten viser ss -ltn, om lytteren binder til 127.0.0.1, LAN-interfacet eller tunneladressen. En daemon, der kun er bundet til loopback, svarer ingen andre end sig selv, og ingen rute, DNAT eller portforwarding ændrer det.

En proxy på port 80 eller 443 er et andet værktøj med en anden synlighed. Den flytter anmodninger, ikke pakker, så den er det forkerte lag til en rå databaseforbindelse, og at gribe efter den er, hvordan dette problem ender tre værktøjer dybt, før nogen måler noget.

Ruteform: fortæl LAN'et, hvor puljen er

En statisk rute på LAN-gatewayen er det reneste svar, når LAN'et og tunnelpuljen ikke overlapper. Peg puljen mod maskinen, der afslutter 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 løser kun én retning, og derfor ser halvfærdige versioner af denne ændring ud som fremskridt. Tunnelsiden har brug for den matchende halvdel, ellers forlader svaret klienten ad dens egen standardrute og dør på vejen:

push "route 192.168.1.0 255.255.255.0"

Til et undernet, der ligger bag én klient i stedet for bag serveren, har serveren brug for både en systemrute og en iroute-post i den klients fil under client-config-dir. Uden iroute ved OpenVPN, at præfikset findes, og aner ikke, hvilken klient der ejer det: pakker ankommer, og daemonen har intet at matche dem med.

Her er myten, der er værd at navngive. En rute gør en adresse tilgængelig; den gør ikke den anden side villig til at svare. Site-to-site-peers tilføjer endnu et lag ovenpå, fordi den fjernede gateway kun accepterer kilder inde i de præfikser, der står i dens politik, og en laptop, der kommer fra en hjemmepulje, er ikke inde i dem.

NAT-form: DNAT ind, og den SNAT-linje alle springer over

Når du ikke kan røre LAN-gatewayen, eller du vil udgive præcis én port, virker oversættelse på VPN-værten uden nogen rute på LAN'et overhovedet. Udgiv porten, videresend den, og oversæt kilden på vejen ind 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 linje er den, der forsvinder. Spring den over, og klienten ser den oprindelige LAN-adresse som kilde, svarer via sin egen standardrute, og det svar går ind i tunnelen i stedet for tilbage mod LAN'et. Om forbindelsen overlever, afhænger så af routing, du aldrig havde planlagt. Med SNAT ser klienten serverens tunneladresse, så svaret følger tunnelen tilbage til den eneste vært, der kan fortryde oversættelsen.

Forbrugerfirmware bruger sine egne kædenavne og genererer ikke den oversættelse for dig. På Tomato lander en indgående regel i WANPREROUTING og derefter i en filterkæde som wanin, og et regelsæt, der ser komplet ud, har stadig brug for en manuel POSTROUTING-linje. Det er ikke en firmwarefejl; det er et regelsæt skrevet kun til indgående trafik.

Hvorfor en regel, der ser korrekt ud, stadig dropper pakken

De fleste af disse fejl sidder ikke i den regel, du stirrer på. Tjek fire ting i denne rækkefølge, og stop ved den første, der ikke holder:

  • Kæderækkefølge. iptables -I indsætter i toppen, og -A tilføjer i bunden, så en tidligere tilladende eller blokerende regel afgør først.
  • Forkert kæde. Trafik adresseret til routeren selv går gennem INPUT, og videresendt trafik rører den aldrig. Udgivelse af én tjeneste kan kræve regler i begge.
  • Retningsflag. -i tun0 matcher trafik, der ankommer fra klienter, og -o tun0 matcher trafik, der går mod dem. En REJECT med det forkerte flag blokerer noget, du ikke havde tænkt dig.
  • Kildebegrænsning. En videresendelse, der accepterer én klientadresse, virker fra den klient og dropper enhver anden kilde uden et ord.

En regel med en pakketæller på nul er slet ikke på vejen, og at læse tællerne er den hurtigste måde at skelne et forkert-kæde-problem fra et forkert-regel-problem.

Den lokale videresendelse, når intet på LAN'et kan ændres

En lokal SSH-videresendelse omgår hele spørgsmålet. Den kræver ingen rute på LAN'et, intet samarbejde fra klientens firewall og ingen port udgivet noget sted:

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

Tjenesten dukker så op på localhost:3000 på maskinen, der kører tunnelen, og ingen andre steder. Det er grænsen: én arbejdsstation, én port, og videresendelsen dør med sessionen, medmindre noget genstarter den. For en administrator, der tjekker en staging-database, er det det rigtige værktøj. For et kamera eller en scanner, som andre mennesker skal kunne nå, er det ikke, fordi hver bruger ville have brug for sin egen videresendelse.

Bekræft begge retninger, før du tilføjer endnu en regel

Oversættelse efterlader spor, og at læse dem slår at gætte. På VPN-værten viser conntrack -L, om oversættelsen overhovedet skete, iptables -t nat -L -n -v viser, om tællerne flyttede sig, og tcpdump -ni any port 3000 viser, hvilken kildeadresse der faktisk ankom. På klienten bekræfter ss -ltn, at lytteren er på en adresse, som tunnelen kan nå.

Vælg så den form, du beholder. Én udgivet port, en rute for hele puljen og en videresendelse til én administrator er tre forskellige forpligtelser, og at blande dem er, hvordan en fungerende opsætning bliver en, som ingen kan forklare seks måneder senere. Skriv ned, hvilken adresse der kan nås hvorfra, og den næste person, der skal fejlfinde dette, starter ved svaret i stedet for ved tunnelen.

Relaterede artikler