Nå en enhed derhjemme over en fjernadgangs-VPN: fem porte

En kommerciel internetudgangs-VPN skjuler din adresse; den forbinder dig ikke med dit eget hus. At nå NAS’en eller printeren på et hjemmenetværk kræver en gateway, der sidder på det netværk, og en klient, der bygger en tunnel til den. Pakken skal derefter gennem fem kontroller, og enhver af dem, der fejler, ser ens ud udefra.

Port 1: klienten skal vælge tunnelen

Kontroller, at destinationspræfikset faktisk routes ind i tunnelen på klienten. En split-tunnel-profil, der kun sender VPN’ens eget subnet, sender 192.168.x.x direkte ud af den lokale grænseflade, hvor det ikke fører nogen steder. Se på klientens routingtabel, ikke på profilnavnet.

Det er den mest almindelige fejl med telefonklienter, som ofte som standard kun sender DNS eller kun et præfiks. Hvis ruten mangler, kan håndtrykket være perfekt, og enheden stadig være utilgængelig.

Bekræft, at klientens puljeadresse og hjemmesubnettet ikke overlapper, før du går videre.

Port 2: gatewayen skal videresende

VPN’en terminerer på en vært, der skal videresende den dekrypterede pakke til LAN’et. Det kræver IP-videresendelse aktiveret og en firewallpolitik, der tillader strømmen fra VPN-grænsefladen til LAN-grænsefladen. På en router-appliance er det normalt indbygget; på en Linux-boks med strongSwan eller WireGuard er det to indstillinger, folk glemmer. Kontroller begge, før du tester tjenesten, da hver for sig giver den samme timeout.

Test med en optagelse på LAN-grænsefladen, fordi en pakke, der aldrig dukker op der, blev droppet eller aldrig videresendt.

Det er en anden fejl end en tjeneste, der afviser forbindelsen, og den forskel sparer meget tid. Hold tilladelsen snæver, begrænset til tjenesten og VPN-puljen i stedet for hele subnettet.

Port 3: svarvejen afgør alt

Målet svarer til den kildeadresse, det så, som enten er klientens puljeadresse eller gatewayen, afhængigt af om du oversætter. Hvis målets standardgateway er hjemmerruteren, og den router ikke har nogen rute til VPN-puljen, forlader svaret via internettet og dør. Det er den klassiske envejsforbindelse.

Der findes to legitime løsninger: tilføj en rute til puljen på LAN-gatewayen, eller source-NAT på VPN-gatewayen, så målet kun ser gatewayadressen. Den anden er nemmere og mister den oprindelige kildeidentitet.

Vælg en bevidst, og skriv ned hvilken, fordi firewallregler og logfiler afhænger af det. strongSwan-vejledningen om videresendelse gennemgår Linux-siden af den beslutning.

Port 4: navne og præfiks-overlap

Lokale opdagelsesnavne krydser ikke en routet grænse, så en enhed, der vises som et venligt navn inde i huset, kan være usynlig over tunnelen. Sørg for DNS til den private zone, eller dokumentér adressen. Uanset hvilket navn du bruger, skal det kunne opløses til noget, den eksterne klient kan route. Derfor kan en enhed være tilgængelig via adresse og usynlig via navn samtidig.

Overlappende præfikser er den anden fælde: hvis klientens pulje er 192.168.1.0/24 og hjemmenetværket også, behandler klienten destinationen som lokal og sender den aldrig gennem tunnelen.

Omnummerér den ene side, eller brug en pulje fra et område, du aldrig møder derhjemme.

Port 5: test udefra huset

En test fra køkkenet beviser intet, fordi trafikken måske aldrig forlader LAN’et. Forbind fra et mobilt hotspot eller et andet netværk, og gå derefter portene igennem i rækkefølge: rute på klienten, optagelse på LAN-grænsefladen, tjenestens svar, optagelse af svaret og navneopløsning. Den første port, der ikke giver bevis, er der, hvor arbejdet ligger.

Hvis tjenesten svarer, men navnet ikke, har du et DNS-problem snarere end et tunnelproblem.

Gem den fungerende konfiguration i et notat med puljen, ruten og NAT-valget, fordi den næste routerudskiftning nulstiller alle tre.