firewalld-lytteregel kontra videresendingspolicy: hva hver gjør

En VPN som kobler til men ikke når noe, beskrives vanligvis som et brannmurproblem, og løsningen folk griper til er å sette tunnelgrensesnittet i en klarert sone. Det virker i den forstand at trafikken begynner å flyte, men det slipper også inn langt mer enn den tiltenkte tjenesten. De to policyene som er involvert, er forskjellige: den ene slipper den ytre transporten til en lyttende socket, og den andre autoriserer dekryptert trafikk til å nå en bestemt ressurs. Det er å behandle dem som én innstilling som gjør en smal tillatelse til en bred. De to avgjøres på forskjellige steder, og derfor er feilen så lett å gjøre.

To policyer, én tunnel

Den ytre policyen svarer på et enkelt spørsmål: kan en pakke fra denne kilden nå UDP 1194 på denne verten? Den indre policyen svarer på et annet: kan den autentiserte klienten bak den tunnelen nå denne destinasjonen, med denne protokollen, på denne porten? Den første handler om en socket, den andre om en sti, og firewalld modellerer dem med forskjellige objekter fordi de avgjøres på forskjellige punkter. Den ene er en egenskap ved en socket på denne verten, den andre ved en sti gjennom den.

Den praktiske konsekvensen er at en fungerende tunnel ikke sier noe om den andre policyen, og en korrekt andre policy gjør ikke den første overflødig.

Tillat den faktiske ytre lytteren

Begynn med å undersøke hva som allerede er tildelt i stedet for å anta. Les de aktive sonene, list opp sonen som faktisk bærer inngående trafikk, og kontroller den installerte tjenestedefinisjonen, fordi et tjenestenavn beskriver et sett med porter og ikke sier noe om hvorvidt denne serverens lytter samsvarer med den.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Hvis lytteren faktisk er UDP 1194 i den sonen, åpne nettopp den porten og transporten, og gjør deretter den samme spesifikke regelen permanent etter at du har testet den. Kontroller også kildebaserte tildelinger, fordi en sone bundet til et kildeområde kan fange trafikken før grensesnittsonen i det hele tatt ser den.

Autoriser den dekrypterte destinasjonen separat

En tilkobling til en tjeneste som kjører på VPN-serveren selv, er lokal inngangs-policy. En tilkobling som videresendes til en annen vert på LAN-et, trenger videresendingspolicy, videresending aktivert i kjernen og en returrute — tre separate krav som folk ofte slår sammen til ett. Moderne firewalld-policyobjekter beskriver rettet trafikk mellom en inngående og en utgående sone, og det er det riktige stedet å uttrykke hvilke VPN-kilder som kan nå hvilke private tjenester.

Definer de tillatte kildene eksplisitt og la alt annet falle i en avvisning. En tillatelse for den ytre tjenesten er ikke den policyen, uansett hvordan soneoppsettet ser ut.

Hvorfor tillit til grensesnittet er den feil snarveien

Å sette tunnelgrensesnittet i en sone hvis mål godtar alt, slipper all dekryptert trafikk til hver tjeneste verten eksponerer, inkludert dem du ikke har gjennomgått. Å rette den klarerte sonen mot å være restriktiv på en maskin som kjører, er verre, fordi andre grensesnitt og kildeområder kanskje allerede avhenger av betydningen og vil endre atferd når du redigerer den. Hvis du trenger en smal policy, opprett en; ikke gjenbruk en delt sone.

Hold også tunnelens sonetildeling stabil gjennom den komponenten som eier den konfigurasjonen. Mister du tildelingen ved omstart, gir det en feil som ser ut som et brannmurregelproblem og egentlig er et persistensproblem.

Verifiser tre ting, inkludert én avvisning

Test den ytre tilkoblingen utenfra, test én autorisert indre tjeneste fra en tilkoblet klient, og test én tjeneste som skal forbli utilgjengelig. Den tredje testen er den som skiller en policy fra en bivirkning, og det er den folk hopper over fordi alt ser ut til å virke. Hvis den avviste tjenesten svarer, har du tillatt en sone i stedet for en tjeneste.

Noter sone, port, transport og policyobjekt i serverens notater. Ellers begynner den neste endringen på denne verten fra den samme antakelsen.