Nå ein eining heime over ein fjernaksess-VPN: fem portar

Ein kommersiell internettutgangs-VPN skjuler adressa di; han knyter deg ikkje til ditt eige hus. Å nå NAS-en eller skrivaren på eit heimenettverk krev ein gateway som sit på det nettverket, og ein klient som byggjer ein tunnel til han. Pakken må deretter gjennom fem kontrollar, og kvar av dei som feilar ser lik ut utanfrå.

Port 1: klienten må velje tunnelen

Kontroller at destinasjonsprefikset faktisk blir ruta inn i tunnelen på klienten. Ein split-tunnel-profil som berre sender VPN-en sitt eige subnett, sender 192.168.x.x rett ut av det lokale grensesnittet, der det ikkje fører nokon stad. Sjå på rutetabellen til klienten, ikkje på profilnamnet.

Dette er den vanlegaste feilen med telefonklientar, som ofte som standard berre sender DNS eller berre eitt prefiks. Manglar ruta, kan handtrykket vere perfekt og eininga likevel utilgjengeleg.

Stadfest at puljeadressa til klienten og heimesubnettet ikkje overlappar før du går vidare.

Port 2: gatewayen må vidaresende

VPN-en terminerer på ein vert som må vidaresende den dekrypterte pakken til LAN-et. Det krev IP-vidaresending slått på og ein brannmurpolicy som tillèt straumen frå VPN-grensesnittet til LAN-grensesnittet. På ein rutar-eining er dette vanlegvis innebygd; på ein Linux-boks med strongSwan eller WireGuard er det to innstillingar folk gløymer. Kontroller begge før du testar tenesta, sidan kvar for seg gir same tidsavbrot.

Test med eit opptak på LAN-grensesnittet, fordi ein pakke som aldri dukkar opp der vart droppa eller aldri vidaresend.

Det er ein annan feil enn ei teneste som avviser tilkoblinga, og skilnaden sparer mykje tid. Hald løyvet smalt, avgrensa til tenesta og VPN-puljen i staden for heile subnettet.

Port 3: svarvegen avgjer alt

Målet svarar til kjeldeadressa det såg, som anten er puljeadressa til klienten eller gatewayen, avhengig av om du omset. Viss standardgatewayen til målet er heimerutaren og den rutaren ikkje har noka rute til VPN-puljen, forlèt svaret via internett og døyr. Det er den klassiske einvegsforbindinga.

Det finst to legitime løysingar: legg til ei rute for puljen på LAN-gatewayen, eller gjer source-NAT på VPN-gatewayen slik at målet berre ser gatewayadressa. Den andre er enklare og mistar den opphavlege kjeldeidentiteten.

Vel ein medvite, og skriv ned kva for ein, fordi brannmurreglar og loggar er avhengige av det. strongSwan-rettleiinga om vidaresending går gjennom Linux-sida av den avgjerda.

Port 4: namn og prefiks-overlapp

Lokale oppdagingsnamn kryssar ikkje ei ruta grense, så ei eining som viser seg som eit venleg namn inne i huset kan vere usynleg over tunnelen. Sørg for DNS for den private sona, eller dokumenter adressa. Kva namn du enn brukar, må det løysast til noko den eksterne klienten kan rute. Derfor kan ei eining vere tilgjengeleg via adresse og usynleg via namn samstundes.

Overlappande prefiks er den andre fella: viss puljen til klienten er 192.168.1.0/24 og heimenettverket òg, handsamar klienten destinasjonen som lokal og sender han aldri gjennom tunnelen.

Omnummerer den eine sida, eller bruk ein pulje frå eit område du aldri møter heime.

Port 5: test utanfrå huset

Ein test frå kjøkenet beviser ingenting, fordi trafikken kanskje aldri forlèt LAN-et. Kopla til frå eit mobilt hotspot eller eit anna nettverk, og gå deretter gjennom portane i rekkjefølgje: rute på klienten, opptak på LAN-grensesnittet, svaret frå tenesta, opptak av svaret og namneoppslag. Den første porten som ikkje gir bevis, er der arbeidet ligg.

Viss tenesta svarar, men namnet ikkje, har du eit DNS-problem snarare enn eit tunnelproblem.

Ta vare på den fungerande konfigurasjonen i eit notat med puljen, ruta og NAT-valet, fordi neste rutarutskifting nullstiller alle tre.