Pravidlo počúvajúceho portu vo firewalld verzus politika presmerovania: čo robí ktoré

VPN, ktoré sa pripojí, ale nikam sa nedostane, sa zvyčajne opisuje ako problém brány firewall a riešenie, ku ktorému ľudia siahajú, je umiestniť rozhranie tunela do dôveryhodnej zóny. To funguje v tom zmysle, že premávka začne prúdiť, ale prepustí aj oveľa viac než zamýšľanú službu. Obe zúčastnené politiky sú odlišné: jedna prepúšťa vonkajší transport k počúvajúcemu socketu, druhá oprávňuje dešifrovanú premávku dosiahnuť konkrétny zdroj. Práve to, že sa s nimi zaobchádza ako s jedným nastavením, mení úzke povolenie na široké. Obe sa rozhodujú na rôznych miestach, a preto je tá chyba taká ľahká.

Dve politiky, jeden tunel

Vonkajšia politika odpovedá na jednoduchú otázku: smie paket z tohto zdroja dosiahnuť UDP 1194 na tomto hostiteľovi? Vnútorná politika odpovedá na inú: smie overený klient za týmto tunelom dosiahnuť tento cieľ, týmto protokolom, na tomto porte? Prvá je o sockete, druhá o ceste, a firewalld ich modeluje rôznymi objektmi, pretože sa rozhodujú v rôznych bodoch. Jedna je vlastnosť socketu na tomto hostiteľovi, druhá vlastnosť cesty cezeň.

Praktickým dôsledkom je, že funkčný tunel o druhej politike nič nehovorí a správna druhá politika nerobí prvú zbytočnou.

Prepustite skutočný vonkajší počúvajúci port

Začnite tým, že preskúmate, čo je už pridelené, namiesto predpokladania. Prečítajte si aktívne zóny, vypíšte zónu, ktorá skutočne nesie prichádzajúcu premávku, a skontrolujte nainštalovanú definíciu služby, pretože názov služby opisuje množinu portov a nič nehovorí o tom, či s ním počúvajúci port tohto servera súhlasí.

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

Ak je počúvajúci port skutočne UDP 1194 v tejto zóne, otvorte konkrétne tento port a transport a potom po otestovaní nastavte to isté konkrétne pravidlo natrvalo. Skontrolujte aj priradenia podľa zdroja, pretože zóna viazaná na rozsah zdrojov môže premávku zachytiť skôr, než ju zóna rozhrania vôbec uvidí.

Autorizujte dešifrovaný cieľ oddelene

Spojenie so službou bežiacou priamo na serveri VPN je politika miestneho vstupu. Spojenie presmerované na iného hostiteľa v LAN potrebuje politiku presmerovania, presmerovanie povolené v jadre a spätnú trasu — tri oddelené požiadavky, ktoré ľudia často zlievajú do jednej. Moderné objekty politík firewalld opisujú smerovanú premávku medzi vstupnou a výstupnou zónou a práve tam je správne miesto vyjadriť, ktoré zdroje VPN smú dosiahnuť ktoré súkromné služby.

Povolené zdroje definujte výslovne a všetko ostatné nechajte padnúť do zamietnutia. Povolenie pre vonkajšiu službu nie je tou politikou, akokoľvek rozloženie zón vyzerá.

Prečo je dôvera v rozhranie nesprávna skratka

Umiestnenie rozhrania tunela do zóny, ktorej cieľ prijíma všetko, prepustí všetku dešifrovanú premávku ku každej službe, ktorú hostiteľ vystavuje, vrátane tých, ktoré ste neprešli. Precielenie dôveryhodnej zóny na obmedzujúcu na bežiacom stroji je horšie, pretože iné rozhrania a rozsahy zdrojov už môžu závisieť od jej významu a pri úprave zmenia správanie. Ak potrebujete úzku politiku, vytvorte ju; neprepoužívajte zdieľanú zónu.

Udržujte tiež priradenie zóny tunela stabilné cez akýkoľvek komponent, ktorý tú konfiguráciu vlastní. Strata priradenia pri reštarte vytvára zlyhanie, ktoré vyzerá ako problém pravidla firewallu a v skutočnosti je problémom perzistencie.

Overte tri veci, vrátane jedného zamietnutia

Otestujte vonkajšie spojenie zvonku, otestujte jednu autorizovanú vnútornú službu z pripojeného klienta a otestujte jednu službu, ktorá má zostať nedostupná. Tretí test je ten, ktorý odlišuje politiku od vedľajšieho efektu, a práve ten ľudia vynechávajú, pretože všetko vyzerá, že funguje. Ak zamietnutá služba odpovedá, prepustili ste zónu, nie službu.

Zapíšte zónu, port, transport a objekt politiky do poznámok servera. Inak ďalšia zmena na tomto hostiteľovi začne od rovnakého predpokladu.