VPN-klienter og LAN'et: hvornår en separat zone er nødvendig

At placere tunnelgrænsefladen i LAN-zonen er den korteste vej til en fungerende VPN, og det er normalt den forkerte standard. Det giver fjernklienten samme tillid som det kablede LAN, hvilket opgaven sjældent kræver. En separat zone koster et par regler og gør grænsen synlig. Beslutningen handler ikke om, hvorvidt zoner er bedre; den handler om, hvilke tre betingelser der gælder for dit netværk.

Zonens navn krypterer intet og godkender ikke en bruger. Det grupperer kun grænseflader til firewallens policymodel.

Hvad zonemedlemskab egentlig styrer

En zone grupperer grænseflader eller trafik under firewallens model. Dens input-, output- og videresendelsesindstillinger styrer derefter forskellige roller. Input er trafik til routeren selv; videresendelse er trafik gennem den til en anden vært. OpenWrts zonelitteratur behandler netop af den grund input, output og videresendelse som separate indstillinger.

En tilladelse fra VPN-zonen til LAN-zonen er ikke automatisk en omvendt tilladelse. Videresendelsesregler er retningsbestemte, og en regel, der tillader trafik fra klient til server, tillader ikke sessioner fra server til klient. En klient, der kan åbne en forbindelse til en server, er ikke en klient, som serveren kan åbne en forbindelse tilbage til.

Den forskel er grunden til, at en separat zone er nyttig: du kan angive hver retning og hver rolle eksplicit. Skriv retningen ved siden af hver regel.

Beslutning et: input, videresendelse eller begge

Hvis fjernklienter har brug for DNS fra routeren, så tillad kun input for den tjeneste. Hvis de skal nå en filserver, så tillad videresendelse til den destination. De fleste VPN-design har brug for begge, men til forskellige tjenester.

Bred inputadgang til alle lokale tjenester er næsten aldrig påkrævet. Behandl routeradministration som en beslutning adskilt fra applikationsadgang. Hvis routeren kun skal svare på DNS, så skriv den ene tilladelse og lad resten være lukket.

Beslutning to: hvilke ressourcer fjernklienter har brug for

List klientintervallerne, destinationerne og de tjenester, VPN'en skal levere, før du skriver regler. En destinationsliste er mere brugbar end et tillidsmærke, fordi den overlever en firewallmigrering.

Hold administrationsgrænseflader adskilt fra almindelig applikationsadgang. En fjernklient, der kan nå en wiki, har ikke dermed brug for routerens admin-side eller hypervisor-konsollen.

Hvis en tilladt destination kan videresende videre, stopper zonegrænsen ved firewallen, ikke ved hvad destinationen gør derefter.

Beslutning tre: hvordan du beviser grænsen

Test et tilladt flow og et bevidst afvist flow efter hver ændring. At bevise, at ét websted indlæses, afslører ikke en utilsigtet bred tilladelse. Test fra VPN-klientens adresseinterval, ikke fra LAN'et, og medtag den retning, du forventer fejler. Noter begge resultater ved siden af reglen.

Bevar gatewayens adgang til gendannelse, før du ændrer politikken for fjernzonen. Brug den vedvarende administrerede konfiguration i stedet for ændringer under kørsel, ellers vil den næste genstart gendanne den gamle tillid. En kopi af den forrige konfiguration, opbevaret uden for enheden, er den billigste tilbagerulning, du nogensinde får.

Når netværket vokser, så dokumentér medlemskab og reglernes formål. En nyligt tilsluttet grænseflade bør ikke arve privilegier, blot fordi nogen gav den et bekvemt zonenavn.