firewalld-lyttarregel kontra vidaresendingspolicy: kva kvar gjer

Ein VPN som koplar til men ikkje når noko, vert vanlegvis skildra som eit brannmurproblem, og løysinga folk grip til er å setje tunnelgrensesnittet i ei klarert sone. Det verkar i den forstand at trafikken byrjar å flyte, men det slepp òg inn langt meir enn den tiltenkte tenesta. Dei to policyane som er involverte, er ulike: den eine slepp den ytre transporten til ein lyttande socket, og den andre autoriserer dekryptert trafikk til å nå ein bestemd ressurs. Det er å handsame dei som éi innstilling som gjer ei smal tillating til ei brei. Dei to vert avgjorde på ulike stader, og difor er feilen så lett å gjere.

To policyar, éin tunnel

Den ytre policyen svarar på eit enkelt spørsmål: kan ein pakke frå denne kjelda nå UDP 1194 på denne verten? Den indre policyen svarar på eit anna: kan den autentiserte klienten bak den tunnelen nå denne destinasjonen, med denne protokollen, på denne porten? Den fyrste handlar om ein socket, den andre om ein sti, og firewalld modellerer dei med ulike objekt fordi dei vert avgjorde på ulike punkt. Den eine er ein eigenskap ved ein socket på denne verten, den andre ved ein sti gjennom han.

Den praktiske konsekvensen er at ein fungerande tunnel ikkje seier noko om den andre policyen, og ein korrekt andre policy gjer ikkje den fyrste overflødig.

Tillat den faktiske ytre lyttaren

Byrja med å undersøkje kva som allereie er tildelt i staden for å anta. Les dei aktive sonene, list opp sona som faktisk ber inngåande trafikk, og kontroller den installerte tenestedefinisjonen, fordi eit tenestenamn skildrar eit sett med portar og seier ingenting om kvar denne tenaren sin lyttar samsvarar med han.

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

Viss lyttaren faktisk er UDP 1194 i den sona, opne nettopp den porten og transporten, og gjer deretter den same spesifikke regelen permanent etter at du har testa han. Kontroller òg tildelingar baserte på kjelde, fordi ei sone bunden til eit kjeldeområde kan fange trafikken før grensesnittsona i det heile ser han.

Autoriser den dekrypterte destinasjonen separat

Ei tilkopling til ei teneste som køyrer på VPN-tenaren sjølv, er lokal inngangs-policy. Ei tilkopling som vert vidaresend til ein annan vert på LAN-et, treng vidaresendingspolicy, vidaresending slått på i kjernen og ein returrute — tre skilde krav som folk ofte slår saman til eitt. Moderne firewalld-policyobjekt skildrar retta trafikk mellom ei inngåande og ei utgåande sone, og det er den rette staden å uttrykkje kva VPN-kjelder som kan nå kva private tenester.

Definer dei tillatne kjeldene eksplisitt og lat alt anna falle i ei avvising. Ei tillating for den ytre tenesta er ikkje den policyen, same korleis soneoppsettet ser ut.

Kvifor tillit til grensesnittet er den feil snarvegen

Å setje tunnelgrensesnittet i ei sone der målet godtar alt, slepp all dekryptert trafikk til kvar teneste verten eksponerer, òg dei du ikkje har gått gjennom. Å rette den klarerte sona mot å vere restriktiv på ein maskin som køyrer, er verre, fordi andre grensesnitt og kjeldeområde kanskje allereie er avhengige av tydinga og vil endre åtferd når du redigerer ho. Treng du ein smal policy, opprett ein; ikkje bruk ei delt sone om att.

Hald òg sonetildelinga til tunnelen stabil gjennom den komponenten som eig den konfigurasjonen. Mistar du tildelinga ved omstart, gjev det ein feil som ser ut som eit brannmurregelproblem og eigenleg er eit persistensproblem.

Stadfest tre ting, inkludert éi avvising

Test den ytre tilkoplinga utanfrå, test éi autorisert indre teneste frå ein tilkopla klient, og test éi teneste som skal halde fram med å vere utilgjengeleg. Den tredje testen er den som skil ein policy frå ein sideverknad, og det er den folk hoppar over fordi alt ser ut til å verke. Svarar den avviste tenesta, har du tillate ei sone i staden for ei teneste.

Noter sone, port, transport og policyobjekt i notata til tenaren. Elles byrjar den neste endringa på denne verten frå den same føresetnaden.