En VPN-bruger har brug for én printer, ikke hele LAN’et

Reglen ser rigtig ud, og printeren afviser stadig. Eller printeren virker, og samme bruger kan også nå filserveren, hvilket er værre. Begge udfald kommer normalt samme sted fra: den smalle regel blev føjet til et regelsæt, der allerede tillod noget bredere. At læse den effektive rækkefølge forklarer resultatet, før nogen ny regel skrives.

Symptomet: den smalle regel ændrede intet

En dedikeret VPN-pulje, én printeradresse og en tilladelsesregel på TCP 631 er et rimeligt design. Når det slet ikke giver nogen ændring, bør den første mistanke være, at trafikken aldrig nåede den regel. En regel afgør kun trafik, der når dens plads i evalueringsrækkefølgen. Felterne er nemme at kontrollere og er sjældent årsagen til fejlen.

Det modsatte symptom er lettere at overse. Udskriftsjobbet lykkes, og det gør en forbindelse til en fildeling, som brugeren aldrig skulle nå, også. Det betyder, at noget tidligere allerede tillod LAN’et.

Begge symptomer peger på rækkefølgen og ikke på felterne i den nye regel. Det ene er en regel, der aldrig matchede, og det andet er en regel, der matchede for tidligt.

Hvilket regelsæt trafikken faktisk rammer

pfSense evaluerer regler for hvert interface, og OpenVPN har sin egen fane, hvis regler gælder for hver server- og klientinstans. Disse regler behandles før de regler, der er tildelt et bestemt OpenVPN-interface. En bred tilladelse, der efterlades på OpenVPN-fanen, gælder derfor også for denne bruger, uanset hvad interfacefanen siger. Kopiér den rækkefølge ind i ændringsnotatet, så gennemgangen kan kontrollere den uden at åbne GUI’en.

Derfor kan en ny smal tilladelse ikke fjerne adgang. Firewallregler tilføjer tilladelse og tager den ikke fra et tidligere match.

Læs den effektive liste fra toppen, og stop ved den første regel, der matcher trafikken. Det første match er afgørelsen, og alt nedenunder er uopnåeligt for den strøm.

Skriv tilladelsesreglen ud fra udskriftsjobbet

Begynd med jobbet i stedet for med printeren. Brugeren har brug for udskriftstjenesten på printeradressen, så reglen navngiver den adresse, den protokol og den port. Et alias for VPN-puljen og et alias for printeren holder reglen læsbar.

Modstå at tilføje opdagelses- eller administrationsporte for at gøre en guide gladere. En regel, der tillader hele printeren, er en anden politik end en, der tillader en udskriftskø.

Behold printerens egen godkendelse. En netværkstilladelse erstatter den ikke. En konto på kø-niveau er den rigtige kontrol for, hvem der må udskrive hvad.

Seks værdier bærer hele hensigten: tilladelse som handling, IPv4 som familie, TCP som protokol, puljealiaset som kilde, printeraliaset som destination og 631 som port. Alt ud over de seks er en anden politik end den ønskede.

Giv klienten en vej uden LAN-tilladelse

Klienten har brug for en rute til printeradressen, og kontorsiden har brug for en svarvej til VPN-puljen. At pushe en enkelt /32 holder klientkonfigurationen smal, hvilket hjælper fejlsøgning. Det er ikke autorisationsgrænsen, fordi en klient selv kan tilføje ruter.

Hvis køen adresseres ved navn, skal resolverafhængigheden defineres separat. At tillade hele LAN’et, for at ét navn kan slås op, er en langt større ændring, end jobbet kræver.

Vælg bevidst mellem at route tilbage til puljen og at oversætte kilden. Begge virker, og hver skjuler noget forskelligt i loggene.

Test afvisningen såvel som jobbet

Indsend et lille, ikke-følsomt job fra VPN-brugeren, prøv derefter en LAN-ressource, der bør afvises, og firewallens egen administrationsside. Alle tre tests hører til samme session, fordi det er den eneste måde at se politikken som helhed. Et vellykket udskriftsjob alene beviser næsten intet om grænsen.

Gennemgå IPv6 og enhver anden aktiv VPN-vej, før du kalder udrulningen kun-printer. Et regelsæt, der er smalt i én adressefamilie, kan være helt åbent i den anden.