Pravilo slušaoca u firewalld-u nasuprot politici prosljeđivanja: šta svako radi

VPN koji se poveže ali do ničega ne dođe obično se opisuje kao problem zaštitnog zida, a rješenje koje ljudi posežu je stavljanje sučelja tunela u pouzdanu zonu. To funkcionira u smislu da promet počne teći, ali i propušta mnogo više od predviđene usluge. Dvije uključene politike su različite: jedna propušta vanjski transport do utičnice koja sluša, a druga ovlašćuje dešifrirani promet da dosegne određeni resurs. Upravo tretiranje njih kao jedne postavke pretvara usku dozvolu u široku. O njima se odlučuje na različitim mjestima, i zato je grešku tako lako napraviti.

Dvije politike, jedan tunel

Vanjska politika odgovara na jednostavno pitanje: može li paket s ovog izvora dosegnuti UDP 1194 na ovom hostu? Unutrašnja politika odgovara na drugo: može li autentificirani klijent iza tog tunela dosegnuti ovo odredište, ovim protokolom, na ovom portu? Prvo se tiče utičnice, drugo putanje, a firewalld ih modelira različitim objektima jer se odlučuje na različitim mjestima. Jedno je svojstvo utičnice na ovom hostu, drugo svojstvo putanje kroz njega.

Praktična posljedica je da funkcionalan tunel ne govori ništa o drugoj politici, a ispravna druga politika ne čini prvu nepotrebnom.

Propusnite stvarnog vanjskog slušaoca

Započnite pregledom onoga što je već dodijeljeno, umjesto pretpostavljanja. Pročitajte aktivne zone, izlistajte zonu koja stvarno nosi dolazni promet i provjerite instaliranu definiciju usluge, jer naziv usluge opisuje skup portova i ne govori ništa o tome odgovara li mu slušalac ovog servera.

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

Ako je slušalac zaista UDP 1194 u toj zoni, otvorite upravo taj port i transport, a zatim isto konkretno pravilo učinite trajnim nakon što ga testirate. Provjerite i dodjele po izvoru, jer zona vezana za raspon izvora može uhvatiti promet prije nego što ga zona sučelja uopće vidi.

Ovlastite dešifrirano odredište odvojeno

Veza prema usluzi koja radi na samom VPN serveru je politika lokalnog ulaza. Veza koja se prosljeđuje drugom hostu na LAN-u zahtijeva politiku prosljeđivanja, prosljeđivanje omogućeno u jezgru i povratnu rutu — to su tri odvojena zahtjeva koja ljudi često sažimaju u jedan. Moderni objekti politika u firewalld-u opisuju usmjereni promet između ulazne i izlazne zone, i to je pravo mjesto za izraziti koji VPN izvori smiju dosegnuti koje privatne usluge.

Eksplicitno definirajte dopuštene izvore i pustite da sve ostalo padne u odbijanje. Dozvola za vanjsku uslugu nije ta politika, kako god raspored zona izgledao.

Zašto je povjerenje u sučelje pogrešan prečac

Stavljanje sučelja tunela u zonu čiji cilj prihvaća sve propušta sav dešifrirani promet prema svakoj usluzi koju host izlaže, uključujući one koje niste pregledali. Preusmjeravanje pouzdane zone na restriktivnu na živom stroju još je gore, jer druga sučelja i rasponi izvora možda već ovise o njezinu značenju i promijenit će ponašanje kad je uredite. Ako vam treba uska politika, stvorite je; nemojte prenamijeniti dijeljenu zonu.

Također održavajte dodjelu zone tunela stabilnom kroz koju god komponentu posjeduje tu konfiguraciju. Gubitak dodjele pri ponovnom pokretanju stvara kvar koji izgleda kao problem pravila zaštitnog zida, a zapravo je problem trajnosti.

Provjerite tri stvari, uključujući jedno odbijanje

Testirajte vanjsku vezu izvana, testirajte jednu ovlaštenu unutrašnju uslugu s povezanog klijenta i testirajte jednu uslugu koja bi trebala ostati nedostupna. Treći test je onaj koji razlikuje politiku od nuspojave, i upravo ga ljudi preskaču jer sve izgleda kao da radi. Ako odbijena usluga odgovori, propustili ste zonu, a ne uslugu.

Zapišite zonu, port, transport i objekt politike u bilješke servera. Inače će sljedeća promjena na ovom hostu početi od iste pretpostavke.