VPN-klienter når serveren, men ikke LAN-et: hvilken løsning?

Klienten pinger tunneladressen til OpenVPN-serveren og får svar, prøver deretter en vert på serverens LAN og får ingenting. Den delingen snevrer feilen betydelig inn: tunnelen er oppe, videresending virker sannsynligvis, og svaret forlater nettverket gjennom en dør som ikke fører tilbake. Det finnes tre løsninger, og den riktige avhenger av hva du styrer og hva du er villig til å gi opp. Svar på de tre spørsmålene nedenfor i rekkefølge, så er valget ikke lenger en smakssak.

Bekreft først hvilken retning som er brutt

Forespørselen kommer inn på tunnelgrensesnittet med en kildeadresse fra VPN-poolen. Serveren videresender den til LAN-verten, og den verten svarer den gatewayen dens egen tabell peker på, vanligvis LAN-ruteren. Har ruteren ingen rute til poolen, dør svaret der eller vandrer mot internettet.

Test begge maskinene før du endrer noen av dem. Spør serveren om rutetabellen hvordan den ville nå en klient; spør LAN-verten hvordan den ville nå samme adresse. Det første oppslaget peker vanligvis på tunnelen og det andre på LAN-ruteren, og forskjellen er feilen på én linje. To oppslag er billigere enn en brannmurrevisjon, og de avgjør problemets retning.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Hvis LAN-verten allerede peker på VPN-serveren, er problemet en brannmurregel eller en MTU-grense og ikke en manglende returvei. Ikke legg til en rute for å fikse et filter.

Spørsmål én: kan du endre ruteren på det fjerne LAN-et?

Når LAN-ruteren er din, er en statisk rute for VPN-poolen med VPN-serverens LAN-adresse som neste hopp det rene svaret. Den holder klientenes kildeadresser intakte, noe som betyr noe når LAN-verter logger, filtrerer eller hastighetsbegrenser etter adresse. Den krever heller ingen oversettelse på serveren, så tunnelen forblir en ren rutevei. Forpliktelsen den skaper, er dokumentasjon, fordi pool, rute og serverkonfigurasjon må stemme overens.

Den svikter stille den dagen noen endrer poolen. Skriv verdien ned én gang, og behandle en endring på ett av de tre stedene som en endring av alle tre.

En NAS eller en Layer 3-svitsj som er vert for tjenesten trenger samme rute, med mindre den sender alt gjennom en ruter som har en. Kontroller enheten som avslutter subnettet, ikke bare den som vender mot internettet. Små nettverk har ofte tre enheter med en mening om ruting.

Spørsmål to: kan LAN-et slutte å se klientadresser?

Når ruteren tilhører noen andre, krever oversettelse på VPN-serveren ingen samarbeid. LAN-verten ser serverens LAN-adresse, svarer den, og serveren oversetter tilbake. Derfor oppfører apparater og NAT-baserte fjernaksessroller seg slik.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Prisen er tilskrivning: adresser per klient forsvinner fra LAN-loggene. Enhver allowlist på LAN-verten må da navngi serveren i stedet for poolen.

Velg oversettelse når samarbeid ikke er tilgjengelig, ikke når det bare er upraktisk. Det skjuler klienten for enhver framtidig undersøkelse, også dem der du må vite hvilken bærbar PC som åpnet en tilkobling. Det kan også bryte protokoller som bygger adresser inn i nyttelasten, fordi oversettelsen ligger i headeren. Ingen av valgene er mer avanserte; de svarer på forskjellige spørsmål om eierskap.

Spørsmål tre: er serveren selv klient hos en annen tunnel?

Se for deg den andre topologien: VPN-serveren ringer også opp en kommersiell leverandør, så den har to tunneler og to sett adresser. Trafikk den videresender for sine egne klienter, forlater gjennom leverandøren, og den ruter ikke svar tilbake til pooladresser. Derfor forsvinner svar selv om begge tunnelene er friske.

Løsningen er å maskere den utgående tunnelen også, så leverandøren bare ser serverens tunneladresse. Den motsatte retningen trenger sin egen regel, fordi serveren som starter en tilkobling til en av sine egne klienter, er en annen flyt. Uten den regelen svarer klienten på en adresse den ikke kan rute. Sett den smale regelen før enhver bred masquerade, så den spesifikke oversettelsen vinner.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Multihomed-verter legger til en beslektet feil som ser identisk ut fra klienten. Svaret forlater via grensesnittet med lavere metrikk fordi kildeadressen ble valgt fra en annen tabell. Kontroller returveien med et oppslag i stedet for å anta at framveien innebærer den.

Bekreft deretter begge retninger og begge størrelser

Etter endringen, ping fra klienten til en LAN-vert og deretter fra LAN-verten til klienten. Den andre retningen er den folk hopper over, og det er den som avslører en ufullstendig oversettelsesregel. Registrer begge resultatene med tidsstempler, så en senere regresjon er sammenlignbar.

Flytt deretter ekte data, fordi en liten ping som lykkes mens en stor overføring stopper, er et MTU-symptom. Den feilen dukker opp rett etter at du har gratulert deg selv med å fikse ruten.

Test til slutt på nytt etter en omstart. Runtime-rute- og brannmurkommandoer overlever ikke en, og en løsning som forsvinner ved neste oppstart, blir diagnostisert på nytt av noen med mindre kontekst. Gjør endringen varig slik systemet ditt allerede gjør det, og start deretter på nytt én gang med vilje.