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

Klienten pinger tunneladressen på OpenVPN-serveren og får svar, prøver derefter en vært på serverens LAN og får intet. Den opdeling indsnævrer fejlen betydeligt: tunnelen er oppe, videresendelse virker sandsynligvis, og svaret forlader netværket ad en dør, der ikke fører tilbage. Der findes tre løsninger, og den rigtige afhænger af, hvad du styrer, og hvad du er villig til at give afkald på. Besvar de tre spørgsmål nedenfor i rækkefølge, og valget er ikke længere en smagssag.

Bekræft først, hvilken retning der er brudt

Anmodningen ankommer på tunnelinterfacet med en kildeadresse fra VPN-puljen. Serveren videresender den til LAN-værten, og den vært svarer den gateway, som dens egen tabel peger på, normalt LAN-routeren. Har routeren ingen rute til puljen, dør svaret der eller vandrer mod internettet.

Test begge maskiner, før du ændrer nogen af dem. Spørg på serveren rutetabellen, hvordan den ville nå en klient; spørg på LAN-værten, hvordan den ville nå den samme adresse. Det første opslag peger normalt på tunnelen og det andet på LAN-routeren, og forskellen er fejlen på én linje. To opslag er billigere end en firewallrevision og de fastslår problemets retning.

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

Hvis LAN-værten allerede peger på VPN-serveren, er dit problem en firewallregel eller en MTU-grænse og ikke en manglende returvej. Tilføj ikke en rute for at rette et filter.

Spørgsmål et: kan du ændre det fjerne LAN's router?

Når LAN-routeren er din, er en statisk rute til VPN-puljen med VPN-serverens LAN-adresse som næste hop det rene svar. Den holder klienternes kildeadresser intakte, hvilket betyder noget, når LAN-værter logger, filtrerer eller hastighedsbegrænser efter adresse. Den kræver heller ingen oversættelse på serveren, så tunnelen forbliver en ren rutestil. Den forpligtelse, den skaber, er dokumentation, fordi pulje, rute og serverkonfiguration skal stemme overens.

Den svigter stille den dag, nogen ændrer puljen. Skriv værdien ned én gang, og betragt en ændring på et af de tre steder som en ændring af alle tre.

En NAS eller en Layer 3-switch, der hoster tjenesten, har brug for den samme rute, medmindre den sender alt gennem en router, der har en. Kontroller den enhed, der afslutter subnettet, ikke kun den, der vender mod internettet. Små netværk har ofte tre enheder med en mening om routing.

Spørgsmål to: kan LAN'et holde op med at se klientadresser?

Når routeren tilhører en anden, kræver oversættelse på VPN-serveren intet samarbejde. LAN-værten ser serverens LAN-adresse, svarer den, og serveren oversætter tilbage. Derfor opfører apparater og NAT-baserede fjernadgangsroller sig sådan.

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

Prisen er tilskrivning: adresser pr. klient forsvinder fra LAN-logfiler. Enhver allowlist på LAN-værten skal så navngive serveren i stedet for puljen.

Vælg oversættelse, når samarbejde ikke er tilgængeligt, ikke når det blot er ubelejligt. Det skjuler klienten for enhver fremtidig undersøgelse, også dem, hvor du skal vide, hvilken bærbar computer der åbnede en forbindelse. Det kan også bryde protokoller, der indlejrer adresser i payloads, fordi oversættelsen ligger i headeren. Ingen af mulighederne er mere avancerede; de besvarer forskellige spørgsmål om ejerskab.

Spørgsmål tre: er serveren selv klient hos en anden tunnel?

Forestil dig den anden topologi: VPN-serveren ringer også til en kommerciel udbyder, så den har to tunneler og to sæt adresser. Trafik, som den videresender for sine egne klienter, forlader netværket gennem udbyderen, og den ruter ikke svar tilbage til puljeadresser. Derfor forsvinder svarene, selvom begge tunneler er sunde.

Løsningen er også at maskere den udgående tunnel, så udbyderen kun ser serverens tunneladresse. Den modsatte retning har brug for sin egen regel, fordi serveren, der starter en forbindelse til en af sine egne klienter, er et andet flow. Uden den regel svarer klienten på en adresse, den ikke kan route. Sæt den snævre regel før enhver bred masquerade, så den specifikke oversættelse vinder.

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-værter tilføjer en beslægtet fejl, der ser identisk ud fra klienten. Svaret forlader systemet via interfacet med den lavere metrik, fordi kildeadressen blev valgt fra en anden tabel. Kontroller returvejen med et opslag i stedet for at antage, at fremvejen indebærer den.

Bekræft derefter begge retninger og begge størrelser

Efter ændringen, ping fra klienten til en LAN-vært og derefter fra LAN-værten til klienten. Den anden retning er den, folk springer over, og det er den, der afslører en ufuldstændig oversættelsesregel. Registrer begge resultater med tidsstempler, så en senere regression er sammenlignelig.

Flyt derefter rigtige data, fordi en lille ping, der lykkes, mens en stor overførsel går i stå, er et MTU-symptom. Den fejl viser sig lige efter, du har lykønsket dig selv med at rette ruten.

Test til sidst igen efter en genstart. Runtime-rute- og firewallkommandoer overlever ikke en, og en løsning, der forsvinder ved næste genstart, bliver diagnosticeret igen af nogen med mindre kontekst. Gør ændringen permanent på den måde, dit system allerede gør det, og genstart så én gang med vilje.