Nå en enhet hjemme over en fjernaksess-VPN: fem porter

En kommersiell internettutgangs-VPN skjuler adressen din; den kobler deg ikke til ditt eget hus. Å nå NAS-en eller skriveren på et hjemmenettverk krever en gateway som sitter på det nettverket, og en klient som bygger en tunnel til den. Pakken må deretter gjennom fem kontroller, og enhver av dem som feiler ser lik ut utenfra.

Port 1: klienten må velge tunnelen

Kontroller at destinasjonsprefikset faktisk rutes inn i tunnelen på klienten. En split-tunnel-profil som bare sender VPN-ens eget subnett, sender 192.168.x.x rett ut av det lokale grensesnittet, hvor det ikke fører noe sted. Se på klientens rutingtabell, ikke på profilnavnet.

Dette er den vanligste feilen med telefonklienter, som ofte som standard bare sender DNS eller bare ett prefiks. Mangler ruten, kan håndtrykket være perfekt og enheten likevel utilgjengelig.

Bekreft at klientens puljeadresse og hjemmesubnettet ikke overlapper før du går videre.

Port 2: gatewayen må videresende

VPN-en terminerer på en vert som må videresende den dekrypterte pakken til LAN-et. Det krever IP-videresending aktivert og en brannmurpolicy som tillater strømmen fra VPN-grensesnittet til LAN-grensesnittet. På en ruter-enhet er dette vanligvis innebygd; på en Linux-boks med strongSwan eller WireGuard er det to innstillinger folk glemmer. Kontroller begge før du tester tjenesten, siden hver for seg gir samme tidsavbrudd.

Test med en opptak på LAN-grensesnittet, fordi en pakke som aldri dukker opp der ble droppet eller aldri videresendt.

Det er en annen feil enn en tjeneste som avviser tilkoblingen, og forskjellen sparer mye tid. Hold tillatelsen smal, begrenset til tjenesten og VPN-puljen i stedet for hele subnettet.

Port 3: svarveien avgjør alt

Målet svarer til kildeadressen det så, som enten er klientens puljeadresse eller gatewayen, avhengig av om du oversetter. Hvis målets standardgateway er hjemmeruteren og den ruteren ikke har noen rute til VPN-puljen, forlater svaret via internett og dør. Det er den klassiske enveisforbindelsen.

Det finnes to legitime løsninger: legg til en rute for puljen på LAN-gatewayen, eller gjør source-NAT på VPN-gatewayen slik at målet bare ser gatewayadressen. Den andre er enklere og mister den opprinnelige kildeidentiteten.

Velg en bevisst, og skriv ned hvilken, fordi brannmurregler og logger avhenger av det. strongSwan-veiledningen om videresending går gjennom Linux-siden av den beslutningen.

Port 4: navn og prefiks-overlapp

Lokale oppdagelsesnavn krysser ikke en rutet grense, så en enhet som vises som et vennlig navn inne i huset kan være usynlig over tunnelen. Sørg for DNS for den private sonen, eller dokumenter adressen. Uansett hvilket navn du bruker, må det løses til noe den eksterne klienten kan rute. Derfor kan en enhet være tilgjengelig via adresse og usynlig via navn samtidig.

Overlappende prefikser er den andre fellen: hvis klientens pulje er 192.168.1.0/24 og hjemmenettverket også, behandler klienten destinasjonen som lokal og sender den aldri gjennom tunnelen.

Omnummerer den ene siden, eller bruk en pulje fra et område du aldri møter hjemme.

Port 5: test utenfra huset

En test fra kjøkkenet beviser ingenting, fordi trafikken kanskje aldri forlater LAN-et. Koble til fra et mobilt hotspot eller et annet nettverk, og gå deretter gjennom portene i rekkefølge: rute på klienten, opptak på LAN-grensesnittet, tjenestens svar, opptak av svaret og navneoppslag. Den første porten som ikke gir bevis, er der arbeidet ligger.

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

Ta vare på den fungerende konfigurasjonen i et notat med puljen, ruten og NAT-valget, fordi neste ruterutskifting nullstiller alle tre.