En VPN-användare behöver en skrivare, inte hela LAN:et

Regeln ser rätt ut och skrivaren vägrar fortfarande. Eller så fungerar skrivaren och samma användare når även filservern, vilket är värre. Båda resultaten kommer oftast från samma ställe: den smala regeln lades till i en regeluppsättning som redan tillät något bredare. Att läsa den effektiva ordningen förklarar resultatet innan någon ny regel skrivs.

Symptomet: den smala regeln ändrade ingenting

En dedikerad VPN-pool, en skrivaradress och en tillåtelseregel på TCP 631 är en rimlig design. När det inte ger någon ändring alls bör den första misstanken vara att trafiken aldrig nådde den regeln. En regel avgör bara trafik som når dess plats i utvärderingsordningen. Fälten är lätta att kontrollera och är sällan orsaken till felet.

Det motsatta symptomet är lättare att missa. Utskriftsjobbet lyckas, och det gör även en anslutning till en filresurs som användaren aldrig borde nå. Det betyder att något tidigare redan tillät LAN:et.

Båda symptomen pekar på ordningen och inte på fälten i den nya regeln. Det ena är en regel som aldrig matchade, och det andra är en regel som matchade för tidigt.

Vilken regeluppsättning trafiken faktiskt träffar

pfSense utvärderar regler per gränssnitt, och OpenVPN har en egen flik vars regler gäller för varje server- och klientinstans. Dessa regler behandlas före de regler som tilldelats ett visst OpenVPN-gränssnitt. En bred tillåtelse som ligger kvar på OpenVPN-fliken gäller därför även denna användare, vad gränssnittsfliken än säger. Kopiera den ordningen till ändringsprotokollet så att granskningen kan kontrollera den utan att öppna GUI:t.

Därför kan en ny smal tillåtelse inte ta bort åtkomst. Brandväggsregler lägger till tillåtelse och tar inte bort den från en tidigare matchning.

Läs den effektiva listan uppifrån och stanna vid den första regeln som matchar trafiken. Den första matchningen är beslutet, och allt nedanför är ouppnåeligt för det flödet.

Skriv tillåtelseregeln utifrån utskriftsjobbet

Börja med jobbet i stället för med skrivaren. Användaren behöver utskriftstjänsten på skrivaradressen, så regeln namnger den adressen, det protokollet och den porten. Ett alias för VPN-poolen och ett alias för skrivaren håller regeln läsbar.

Stå emot frestelsen att lägga till upptäckts- eller administrationsportar för att göra en guide gladare. En regel som släpper in hela skrivaren är en annan policy än en som släpper in en utskriftskö.

Behåll skrivarens egen autentisering. En nätverkstillåtelse ersätter den inte. Ett konto på könivå är rätt kontroll för vem som får skriva ut vad.

Sex värden bär hela avsikten: tillåtelse som åtgärd, IPv4 som familj, TCP som protokoll, poolaliaset som källa, skrivaraliaset som mål och 631 som port. Allt utöver dessa sex är en annan policy än den efterfrågade.

Ge klienten en väg utan LAN-tillåtelse

Klienten behöver en rutt till skrivaradressen, och kontorssidan behöver en svarsväg till VPN-poolen. Att skicka ut en enda /32 håller klientkonfigurationen smal, vilket hjälper felsökning. Det är inte auktoriseringsgränsen, eftersom en klient själv kan lägga till rutter.

Om kön adresseras med namn ska resolverberoendet definieras separat. Att tillåta hela LAN:et för att ett enda namn ska slås upp är en mycket större ändring än jobbet kräver.

Välj medvetet mellan att routa tillbaka till poolen och att översätta källan. Båda fungerar, och var och en döljer något annat för loggarna.

Testa både avvisningen och jobbet

Skicka in ett litet, icke-känsligt jobb från VPN-användaren och försök sedan med en LAN-resurs som borde avvisas och brandväggens egen administrationssida. Alla tre testerna hör till samma session, eftersom det är det enda sättet att se policyn som helhet. Ett lyckat utskriftsjobb ensamt bevisar nästan ingenting om gränsen.

Gå igenom IPv6 och varje annan aktiv VPN-väg innan du kallar driftsättningen enbart skrivare. En regeluppsättning som är smal i en adressfamilj kan vara helt öppen i den andra.