En VPN-bruker trenger én skriver, ikke hele LAN-et

Regelen ser riktig ut, og skriveren avviser fortsatt. Eller skriveren virker, og samme bruker når også filserveren, noe som er verre. Begge utfall kommer vanligvis fra samme sted: den smale regelen ble lagt til et regelsett som allerede tillot noe bredere. Å lese den effektive rekkefølgen forklarer resultatet før noen ny regel skrives.

Symptomet: den smale regelen endret ingenting

En dedikert VPN-pool, én skriveradresse og en tillatelsesregel på TCP 631 er et rimelig design. Når det ikke gir noen endring i det hele tatt, bør den første mistanken være at trafikken aldri nådde den regelen. En regel avgjør bare trafikk som når plassen sin i evalueringsrekkefølgen. Feltene er enkle å kontrollere og er sjelden årsaken til feilen.

Det motsatte symptomet er lettere å overse. Utskriftsjobben lykkes, og det gjør også en forbindelse til en fildeling som brukeren aldri skulle nå. Det betyr at noe tidligere allerede tillot LAN-et.

Begge symptomene peker på rekkefølgen og ikke på feltene i den nye regelen. Det ene er en regel som aldri samsvarte, og det andre er en regel som samsvarte for tidlig.

Hvilket regelsett trafikken faktisk treffer

pfSense evaluerer regler per grensesnitt, og OpenVPN har sin egen fane der reglene gjelder for hver server- og klientinstans. Disse reglene behandles før reglene som er tildelt et bestemt OpenVPN-grensesnitt. En bred tillatelse som blir liggende på OpenVPN-fanen, gjelder derfor også for denne brukeren, uansett hva grensesnittfanen sier. Kopier denne rekkefølgen inn i endringsnotatet, slik at gjennomgangen kan kontrollere den uten å åpne GUI-et.

Derfor kan en ny smal tillatelse ikke fjerne tilgang. Brannmurregler legger til tillatelse og tar den ikke fra et tidligere samsvar.

Les den effektive listen fra toppen og stopp ved den første regelen som samsvarer med trafikken. Det første samsvaret er avgjørelsen, og alt nedenfor er uoppnåelig for den strømmen.

Skriv tillatelsesregelen ut fra utskriftsjobben

Begynn med jobben i stedet for med skriveren. Brukeren trenger utskriftstjenesten på skriveradressen, så regelen navngir den adressen, den protokollen og den porten. Et alias for VPN-poolen og et alias for skriveren holder regelen lesbar.

Motstå fristelsen til å legge til oppdagelses- eller administrasjonsporter for å gjøre en veiviser gladere. En regel som slipper inn hele skriveren, er en annen policy enn en som slipper inn en utskriftskø.

Behold skriverens egen autentisering. En nettverkstillatelse erstatter den ikke. En konto på kø-nivå er den riktige kontrollen for hvem som kan skrive ut hva.

Seks verdier bærer hele hensikten: tillatelse som handling, IPv4 som familie, TCP som protokoll, poolaliaset som kilde, skriveraliaset som mål og 631 som port. Alt utover de seks er en annen policy enn den forespurte.

Gi klienten en vei uten LAN-tillatelse

Klienten trenger en rute til skriveradressen, og kontorsiden trenger en svarvei til VPN-poolen. Å pushe én enkelt /32 holder klientkonfigurasjonen smal, noe som hjelper feilsøking. Det er ikke autorisasjonsgrensen, fordi en klient selv kan legge til ruter.

Hvis køen adresseres ved navn, må resolveravhengigheten defineres separat. Å tillate hele LAN-et for at ett navn skal slås opp, er en langt større endring enn jobben krever.

Velg bevisst mellom å rute tilbake til poolen og å oversette kilden. Begge virker, og hver av dem skjuler noe forskjellig fra loggene.

Test både avvisningen og jobben

Send inn en liten, ikke-sensitiv jobb fra VPN-brukeren, og prøv deretter en LAN-ressurs som skal avvises, og brannmurens egen administrasjonsside. Alle tre testene hører til samme økt, fordi det er den eneste måten å se policyen som helhet. En vellykket utskriftsjobb alene beviser nesten ingenting om grensen.

Gå gjennom IPv6 og enhver annen aktiv VPN-vei før du kaller utrullingen kun-skriver. Et regelsett som er smalt i én adressefamilie, kan være helt åpent i den andre.