Nå en enhet hemma via en fjärråtkomst-VPN: fem portar

En kommersiell internetutgångs-VPN döljer din adress; den ansluter dig inte till ditt eget hus. Att nå NAS:en eller skrivaren på ett hemnätverk kräver en gateway som sitter på det nätverket och en klient som bygger en tunnel till den. Paketet måste sedan passera fem kontroller, och varje sådan som misslyckas ser likadan ut utifrån.

Port 1: klienten måste välja tunneln

Kontrollera att destinationsprefixet faktiskt routas in i tunneln på klienten. En split-tunnel-profil som bara skickar VPN:ens eget subnät skickar 192.168.x.x rakt ut ur det lokala gränssnittet, där det inte kommer någonstans. Titta på klientens routingtabell, inte på profilnamnet.

Det här är det vanligaste felet med telefonklienter, som ofta som standard bara skickar DNS eller bara ett prefix. Saknas vägen kan handskakningen vara perfekt och enheten ändå oåtkomlig.

Bekräfta att klientens pooladress och hemsubnätet inte överlappar innan du går vidare.

Port 2: gatewayen måste vidarebefordra

VPN:en avslutas på en värd som måste vidarebefordra det dekrypterade paketet till LAN:et. Det kräver IP-vidarebefordran aktiverad och en brandväggspolicy som tillåter flödet från VPN-gränssnittet till LAN-gränssnittet. På en routerenhet är detta vanligtvis inbyggt; på en Linux-burk med strongSwan eller WireGuard är det två inställningar som folk glömmer. Kontrollera båda innan du testar tjänsten, eftersom var och en för sig ger samma timeout.

Testa med en inspelning på LAN-gränssnittet, eftersom ett paket som aldrig dyker upp där antingen släpptes eller aldrig vidarebefordrades.

Det är ett annat fel än en tjänst som nekar anslutningen, och den skillnaden sparar mycket tid. Håll tillståndet snävt, begränsat till tjänsten och VPN-poolen i stället för hela subnätet.

Port 3: svarsvägen avgör allt

Målet svarar till den källadress det såg, vilket antingen är klientens pooladress eller gatewayen, beroende på om du översätter. Om målets standardgateway är hemroutern och den routern inte har någon väg till VPN-poolen lämnar svaret via internet och dör. Det är den klassiska enkelriktade anslutningen.

Det finns två legitima lösningar: lägg till en väg för poolen på LAN-gatewayen, eller gör source-NAT på VPN-gatewayen så att målet alltid bara ser gatewayadressen. Den andra är enklare och förlorar den ursprungliga källidentiteten.

Välj en medvetet och skriv ner vilken, eftersom brandväggsregler och loggar beror på det. strongSwan-vägledningen för vidarebefordran går igenom Linux-sidan av det beslutet.

Port 4: namn och prefixöverlapp

Lokala upptäcktsnamn korsar inte en routad gräns, så en enhet som inom huset visas med ett vänligt namn kan vara osynlig via tunneln. Tillhandahåll DNS för den privata zonen, eller dokumentera adressen. Vilket namn du än använder måste det lösas till något som fjärrklienten kan routa. Därför kan en enhet vara nåbar via adress och osynlig via namn samtidigt.

Överlappande prefix är den andra fällan: om klientens pool är 192.168.1.0/24 och hemnätverket också, behandlar klienten destinationen som lokal och skickar den aldrig genom tunneln.

Numrera om ena sidan, eller använd en pool från ett intervall du aldrig möter hemma.

Port 5: testa utifrån huset

Ett test från köket bevisar ingenting, eftersom trafiken kanske aldrig lämnar LAN:et. Anslut från en mobil hotspot eller ett annat nätverk och gå sedan igenom portarna i ordning: väg på klienten, inspelning på LAN-gränssnittet, tjänstens svar, inspelning av svaret och namnmatchning. Den första port som inte ger bevis är där arbetet ligger.

Om tjänsten svarar men namnet inte, har du ett DNS-problem snarare än ett tunnelproblem.

Spara den fungerande konfigurationen i en anteckning med poolen, vägen och NAT-valet, eftersom nästa routerbyte återställer alla tre.