VPN-klientar og LAN-et: når du bør bruke ei eiga sone

Å leggje tunnelgrensesnittet i LAN-sona er den kortaste vegen til ein fungerande VPN, og det er vanlegvis feil standardval. Det gir fjernklienten same tillit som det kabelbundne LAN-et, noko oppgåva sjeldan krev. Ei eiga sone kostar nokre reglar og gjer grensa synleg. Avgjerda handlar ikkje om soner er betre; ho handlar om kva tre vilkår som gjeld for nettverket ditt.

Namnet på sona krypterer ingenting og autentiserer ingen brukar. Det grupperer berre grensesnitt for policymodellen til brannmuren.

Kva sonemedlemskap faktisk styrer

Ei sone grupperer grensesnitt eller trafikk i modellen til brannmuren. Innstillingane for input, output og vidaresending styrer deretter ulike rollar. Input er trafikk til rutaren sjølv; vidaresending er trafikk gjennom han til ein annan vert. Sonedokumentasjonen til OpenWrt handsamar input, output og vidaresending som separate innstillingar nettopp av denne grunn.

Ei løyve frå VPN-sona til LAN-sona er ikkje automatisk eit omvendt løyve. Vidaresendingsreglar er retningsbestemte, og ein regel som tillèt trafikk frå klient til tenar, tillèt ikkje økter frå tenar til klient. Ein klient som kan opne ei sambinding til ein tenar, er ikkje ein klient tenaren kan opne ei sambinding tilbake til.

Den skilnaden er grunnen til at ei eiga sone er nyttig: du kan oppgi kvar retning og kvar rolle eksplisitt. Skriv retninga ved sida av kvar regel.

Avgjerd éin: input, vidaresending eller begge

Viss fjernklientar treng DNS frå rutaren, tillèt input berre for den tenesta. Viss dei må nå ein filtenar, tillèt vidaresending til den destinasjonen. Dei fleste VPN-design treng begge, men for ulike tenester.

Brei input-tilgang til alle lokale tenester er nesten aldri naudsynt. Handsam rutaradministrasjon som ei eiga avgjerd frå applikasjonstilgang. Viss rutaren berre treng å svare på DNS, skriv den eine løyva og lat resten vere lukka.

Avgjerd to: kva ressursar fjernklientar treng

List opp klientområda, destinasjonane og tenestene VPN-et skal levere før du skriv reglar. Ei destinasjonsliste er nyttigare enn ein tillitsetikett, fordi ho overlever ein brannmurmigrasjon.

Hald administrasjonsgrensesnitt skilde frå vanleg applikasjonstilgang. Ein fjernklient som når ein wiki, treng ikkje av den grunn admin-sida til rutaren eller hypervisor-konsollen.

Viss ein tillaten destinasjon kan vidaresende vidare, stoppar sonegrensa ved brannmuren, ikkje ved det destinasjonen gjer etterpå.

Avgjerd tre: korleis du provar grensa

Test ein tillaten flyt og ein medvite avvist etter kvar endring. Å prove at éi nettside lastar, avdekkjer ikkje ei utilsikta brei løyve. Test frå adresseområdet til VPN-klienten, ikkje frå LAN-et, og ta med retninga du ventar skal feile. Noter både resultata ved sida av regelen.

Ta vare på gjenopprettingstilgangen til gatewayen før du endrar politikken for fjernsone. Bruk den vedvarande administrerte konfigurasjonen i staden for endringar under køyring, elles vil neste omstart gjenopprette den gamle tilliten. Ein kopi av førre konfigurasjon, lagra utanfor eininga, er den billegaste tilbakerulleringa du nokon gong får.

Når nettverket veks, dokumenter medlemskap og føremålet med reglane. Eit nyleg tilkopla grensesnitt bør ikkje arve privilegium berre fordi nokon gav det eit hendig sonenamn.