Ein VPN-brukar treng éin skrivar, ikkje heile LAN-et

Regelen ser rett ut, og skrivaren nektar framleis. Eller skrivaren verkar, og same brukar når også filtenaren, noko som er verre. Begge utfalla kjem vanlegvis frå same stad: den smale regelen vart lagd til eit regelsett som alt tillét noko breiare. Å lese den effektive rekkjefølgja forklarer resultatet før nokon ny regel vert skriven.

Symptomet: den smale regelen endra ingenting

Ein dedikert VPN-pool, éin skrivaradresse og ein løyveregel på TCP 631 er eit rimeleg design. Når det ikkje gir noka endring i det heile, bør den første mistanken vere at trafikken aldri nådde den regelen. Ein regel avgjer berre trafikk som når plassen sin i vurderingsrekkjefølgja. Felta er enkle å kontrollere og er sjeldan årsaka til feilen.

Det motsette symptomet er lettare å oversjå. Utskriftsjobben lukkast, og det gjer også ei tilkopling til ei fildeling som brukaren aldri skulle nå. Det tyder at noko tidlegare alt tillét LAN-et.

Begge symptoma peikar på rekkjefølgja og ikkje på felta i den nye regelen. Det eine er ein regel som aldri samsvara, og det andre er ein regel som samsvara for tidleg.

Kva regelsett trafikken faktisk treff

pfSense vurderer reglar per grensesnitt, og OpenVPN har sin eigen fane der reglane gjeld for kvar tenar- og klientinstans. Desse reglane vert handsama før reglane som er tildelte eit bestemt OpenVPN-grensesnitt. Ei brei løyve som vert liggjande på OpenVPN-fanen, gjeld derfor også for denne brukaren, kva grensesnittfanen enn seier. Kopier denne rekkjefølgja inn i endringsnotatet, slik at gjennomgangen kan kontrollere henne utan å opne GUI-et.

Derfor kan eit nytt smalt løyve ikkje ta bort tilgang. Brannmurreglar legg til løyve og tek det ikkje frå eit tidlegare samsvar.

Les den effektive lista frå toppen og stopp ved den første regelen som samsvarar med trafikken. Det første samsvaret er avgjerda, og alt nedanfor er uoppnåeleg for den straumen.

Skriv løyveregelen ut frå utskriftsjobben

Start med jobben i staden for med skrivaren. Brukaren treng utskriftstenesta på skrivaradressa, så regelen namngjev den adressa, den protokollen og den porten. Eit alias for VPN-poolen og eit alias for skrivaren held regelen lesbar.

Stå imot freistinga til å leggje til oppdagings- eller administrasjonsportar for å gjere ein vegvisar gladare. Ein regel som slepp inn heile skrivaren, er ein annan politikk enn ein som slepp inn ein utskriftskø.

Behald skrivaren si eiga autentisering. Eit nettverksløyve erstattar henne ikkje. Ein konto på kø-nivå er den rette kontrollen for kven som kan skrive ut kva.

Seks verdiar ber heile hensikta: løyve som handling, IPv4 som familie, TCP som protokoll, poolaliaset som kjelde, skrivaraliaset som mål og 631 som port. Alt utover dei seks er ein annan politikk enn den førespurde.

Gi klienten ein veg utan LAN-løyve

Klienten treng ei rute til skrivaradressa, og kontorsida treng ein svarveg til VPN-poolen. Å pushe éin enkelt /32 held klientkonfigurasjonen smal, noko som hjelper feilsøking. Det er ikkje autorisasjonsgrensa, fordi ein klient sjølv kan leggje til ruter.

Vert køen adressert ved namn, må resolveravhengnaden definerast separat. Å tillate heile LAN-et for at eitt namn skal slåast opp, er ei langt større endring enn jobben krev.

Vel medvite mellom å rute attende til poolen og å omsetje kjelda. Begge verkar, og kvar av dei løyner noko ulikt frå loggane.

Test både avvisinga og jobben

Send inn ein liten, ikkje-sensitiv jobb frå VPN-brukaren, og prøv deretter ein LAN-ressurs som skal avvisast, og administrasjonssida til brannmuren sjølv. Alle tre testane høyrer til same økt, fordi det er den einaste måten å sjå politikken som heilskap. Ein vellukka utskriftsjobb åleine beviser nesten ingenting om grensa.

Gå gjennom IPv6 og kvar annan aktiv VPN-veg før du kallar utrullinga berre-skrivar. Eit regelsett som er smalt i éin adressefamilie, kan vere heilt ope i den andre.