VPN-klienter og LAN-et: når du bør bruke en egen sone

Å legge tunnelgrensesnittet i LAN-sonen er den korteste veien til en fungerende VPN, og det er vanligvis feil standardvalg. Det gir fjernklienten samme tillit som det kablede LAN-et, noe oppgaven sjelden krever. En egen sone koster noen regler og gjør grensen synlig. Beslutningen handler ikke om soner er bedre; den handler om hvilke tre vilkår som gjelder for nettverket ditt.

Sonens navn krypterer ingenting og autentiserer ingen bruker. Det grupperer bare grensesnitt for brannmurens policymodell.

Hva sonemedlemskap faktisk styrer

En sone grupperer grensesnitt eller trafikk i brannmurens modell. Innstillingene for input, output og videresending styrer deretter ulike roller. Input er trafikk til ruteren selv; videresending er trafikk gjennom den til en annen vert. OpenWrts sonedokumentasjon behandler input, output og videresending som separate innstillinger nettopp av denne grunn.

En tillatelse fra VPN-sonen til LAN-sonen er ikke automatisk en omvendt tillatelse. Videresendingsregler er retningsbestemte, og en regel som tillater trafikk fra klient til server, tillater ikke økter fra server til klient. En klient som kan åpne en forbindelse til en server, er ikke en klient serveren kan åpne en forbindelse tilbake til.

Den forskjellen er grunnen til at en egen sone er nyttig: du kan oppgi hver retning og hver rolle eksplisitt. Skriv retningen ved siden av hver regel.

Beslutning én: input, videresending eller begge

Hvis fjernklienter trenger DNS fra ruteren, tillat input bare for den tjenesten. Hvis de må nå en filserver, tillat videresending til den destinasjonen. De fleste VPN-design trenger begge, men for ulike tjenester.

Bred input-tilgang til alle lokale tjenester er nesten aldri nødvendig. Behandle ruteradministrasjon som en egen beslutning fra applikasjonstilgang. Hvis ruteren bare trenger å svare på DNS, skriv den ene tillatelsen og la resten være lukket.

Beslutning to: hvilke ressurser fjernklienter trenger

List opp klientområdene, destinasjonene og tjenestene VPN-et skal levere før du skriver regler. En destinasjonsliste er nyttigere enn en tillitsetikett, fordi den overlever en brannmurmigrering.

Hold administrasjonsgrensesnitt atskilt fra vanlig applikasjonstilgang. En fjernklient som når en wiki trenger ikke av den grunn ruterens admin-side eller hypervisor-konsollen.

Hvis en tillatt destinasjon kan videresende videre, stopper sonegrensen ved brannmuren, ikke ved det destinasjonen gjør etterpå.

Beslutning tre: hvordan du beviser grensen

Test en tillatt flyt og en bevisst avvist etter hver endring. Å bevise at én nettside lastes, avdekker ikke en utilsiktet bred tillatelse. Test fra VPN-klientens adresseområde, ikke fra LAN-et, og ta med retningen du forventer at skal feile. Noter begge resultatene ved siden av regelen.

Bevar gjenopprettingstilgangen til gatewayen før du endrer policyen for fjernsone. Bruk den vedvarende administrerte konfigurasjonen i stedet for endringer under kjøring, ellers vil neste omstart gjenopprette den gamle tilliten. En kopi av forrige konfigurasjon, lagret utenfor enheten, er den billigste tilbakerullingen du noen gang får.

Når nettverket vokser, dokumenter medlemskap og reglenes formål. Et nylig tilkoblet grensesnitt bør ikke arve privilegier bare fordi noen ga det et beleilig sonenavn.