VPN-klienter och LAN: när du bör använda en egen zon

Att lägga tunnelgränssnittet i LAN-zonen är den kortaste vägen till en fungerande VPN, och det är oftast fel standardval. Det ger fjärrklienten samma förtroende som det kabelanslutna LAN:et, vilket uppgiften sällan kräver. En egen zon kostar några regler och gör gränsen synlig. Beslutet handlar inte om zoner är bättre; det handlar om vilka tre villkor som gäller för ditt nät.

Zonens namn krypterar ingenting och autentiserar ingen användare. Det grupperar bara gränssnitt för brandväggens policymodell.

Vad zonmedlemskap faktiskt styr

En zon grupperar gränssnitt eller trafik i brandväggens modell. Dess inställningar för input, output och vidarebefordran styr sedan olika roller. Input är trafik till själva routern; vidarebefordran är trafik genom den till en annan värd. OpenWrts zondokumentation behandlar input, output och vidarebefordran som separata inställningar just av den anledningen.

Ett tillstånd från VPN-zonen till LAN-zonen är inte automatiskt ett omvänt tillstånd. Vidarebefordringsregler är riktade, och en regel som tillåter trafik från klient till server tillåter inte sessioner från server till klient. En klient som kan öppna en anslutning till en server är inte en klient som servern kan öppna en anslutning tillbaka till.

Den skillnaden är anledningen till att en egen zon är användbar: du kan ange varje riktning och varje roll uttryckligen. Skriv riktningen bredvid varje regel.

Beslut ett: input, vidarebefordran eller båda

Om fjärrklienter behöver DNS från routern, tillåt input bara för den tjänsten. Om de måste nå en filserver, tillåt vidarebefordran till den destinationen. De flesta VPN-designer behöver båda, men för olika tjänster.

Bred input-åtkomst till alla lokala tjänster är nästan aldrig nödvändig. Behandla routeradministration som ett eget beslut skilt från applikationsåtkomst. Om routern bara behöver svara på DNS, skriv det enda tillståndet och låt resten vara stängt.

Beslut två: vilka resurser fjärrklienter behöver

Lista klientintervallen, destinationerna och tjänsterna som VPN:et ska leverera innan du skriver regler. En destinationslista är användbarare än en förtroendeetikett, eftersom den överlever en brandväggsmigrering.

Håll administrationsgränssnitt åtskilda från vanlig applikationsåtkomst. En fjärrklient som når en wiki behöver inte därför routerns adminsida eller hypervisorns konsol.

Om en tillåten destination kan vidarebefordra vidare, stannar zongränsen vid brandväggen, inte vid vad destinationen gör sedan.

Beslut tre: hur du bevisar gränsen

Testa ett tillåtet flöde och ett avsiktligt nekat efter varje ändring. Att bevisa att en webbplats laddas avslöjar inte ett oavsiktligt brett tillstånd. Testa från VPN-klientens adressintervall, inte från LAN:et, och ta med riktningen du förväntar dig ska misslyckas. Anteckna båda resultaten bredvid regeln.

Bevara gatewayens återställningsåtkomst innan du ändrar policyn för fjärrzonen. Använd den beständiga hanterade konfigurationen i stället för ändringar under drift, annars kommer nästa omstart att återställa det gamla förtroendet. En kopia av den tidigare konfigurationen, lagrad utanför enheten, är den billigaste återrullningen du någonsin får.

När nätet växer, dokumentera medlemskap och reglernas syfte. Ett nyligen anslutet gränssnitt bör inte ärva privilegier bara för att någon gav det ett bekvämt zonnamn.