Piirake OpenVPN-i lüüs ühe LAN-iga UFW reeglitega

Otsustage luba enne tulemüüri faili avamist: autenditud kliendid tohivad avada ühendusi ühte kindlasse alamvõrku ja lüüs peab keelduma igast teisest läbimineku teest ka siis, kui klient paigaldab lisamarsruute. See lause on disain ja iga allolev reegel on olemas selle jõustamiseks. Midagi laiemat, näiteks kogu privaatne aadressiruum, internetiväljund läbi tunneli või võrdõiguslik liiklus, on teine disain, mis vajab oma otsust. Reeglid on ka meelega igavad, sest nutikas tulemüür on see, mida keegi hiljem auditeerida ei suuda.

Kirjutage kõigepealt üles topoloogia ja luba

Näide kasutab Community OpenVPN serverit kasutajaruumi TUN-seadmega nimega tun0, kliendikogumiga 10.77.0.0/24, ja ühe kinnitatud alamvõrguga 192.168.60.0/24 lan0 peal. IPv4 edastamine töötab juba ja LAN-il on juba tagasitee kogumi juurde, seega ei sõltu siin miski nendevahelisest tõlkimisest.

Selle hosti tulemüür kuulub UFW-le ja ükski konteineri reeglistik ega eraldi nftables-tabel ei tohi paigaldada varasemat vastuvõtu teed. Filtrilt vahele jätmise voo mahalaadimise otsetee muudaks valveketyd puhtalt kaunistuseks, seega kinnitage, et ükski pole aktiivne. Jätke OpenVPN-i enda client-to-client edastamine välja lülitatuks, sest võrdõiguslik liiklus, mis ei läbi kunagi operatsioonisüsteemi filtrit ei ole sellega piiratav. Väline kuulaja ja haldusreeglid jäävad nii nagu on, sest see muudatus juhib dekrüpteeritud tunnelliiklust, mitte ei asenda tulemüüri.

Paigutage valvurid enne UFW varaseid vastuvõtte

Marsruudiluba, millele järgneb keeld, ei ole range piiri jaoks piisav. Standardbefore'id võtavad vastu juba loodud liiklust ja valitud ICMP-d enne, kui üldse mõnda kasutajareeglit vaadatakse, seega eelmisel nädalal lubatud voog võib jääda uuest sihtkoha piirangust välja ainult sellepärast, et sellel on veel olek. Tehke UFW failidest varukoopia ja hoidke enne redigeerimist ribavälist konsooli avatuna.

Sektsioonis *filter failis /etc/ufw/before.rules kuulutage välja kaks ketti olemasolevate deklaratsioonide kõrval ja enne ükskõik millist reeglirida.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Vahetult pärast deklaratsioone ja enne sisendi ning edastamise lubasid hüpake nendesse sisse ja määratlege, mida need lubavad.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Jätke ülejäänud sektsioon ja selle COMMIT rida alles. Teise filtriteabeli kleepimine või seotud reeglite kustutamine on viis, kuidas tulemüüri muudatus muutub katkestuseks, ja fail on ühe taaskäivituse kaugusel sellest, et olla ainus oluline koopia.

Lugege, mida iga valvur lubab ja keelab

Esimene kett jätkab töötlemist ainult siis, kui allikas on kogumis, sihtkohaks on see üks alamvõrk, väljundliides on LAN ja pakett liigub oma voo algses suunas. Kõik muu tunnelist saabuv jäetakse kõrvale, sealhulgas kogumist väljaspool olev allikas ja iga sihtkoht, mis on lubatud alamvõrgust kaugemal.

Võrdõiguslik pakett siseneb tun0-i ja väljub sealt, seega ebaõnnestub see LAN-liidese testis juba enne, kui sihtkoha kontrollini jõutakse. Uued ühendused LAN-ist klientide poole ebaõnnestuvad ka vastuse suuna testis, mis sulgeb vaikimisi vastupidise tagasikutse tee.

Sihtmärk RETURN hoiab tavalise UFW poliitika mängus. Need ketid filtreerivad ja järgmisena lisatav marsruudiluba otsustab endiselt, kas ellujäänud pakett vastu võetakse. Just see eraldatus võimaldab teil hiljem lubatud alamvõrku ühes kohas muuta. Kui valvurid võtaksid paketid otse vastu, tuleks iga tulevane reegel lisada kaks korda.

Volitage alamvõrk ja sulgege kõrvaluksed

Eelvaadake kõigepealt marsruudiluba, seejärel eemaldage eelvaate lipp, et see rakendada: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Seejärel vaadake üle kasutajareeglite järjekord, sest varasem keeld võidab endiselt hilisema loa. Kogu alamvõrgu luba on ka vale kuju, kui peaks kättesaadav olema ainult ühe hosti HTTPS-port.

Pange tähele, mida sisendi kõrvalejätmine teeb: tunnelikliendid ei pääse ühelegi teenusele lüüsi enda peal, sealhulgas DNS-kuulajale, mis on seotud selle LAN-aadressiga. DNS-i seal majutamine nõuab teadlikku erandit enne kõrvalejätmist ja ülevaadatud loalepingut. Kui UFW haldab IPv6-t, lisage vastavad kõrvalejätmised tun0 jaoks failis before6.rules samuti, sest IPv4 sihtkohtade loend ei ütle IPv6 pakettide kohta midagi.

Kontrollige laaditud poliitikat, mitte eelvaadet

Eelvaadake uuestilaadimist, rakendage see hooldusaknas ja lugege elavat reeglistikku.

sudo ufw --dry-run reload
sudo ufw show raw

Kinnitage, et tunneli valvurid ilmuvad enne vaikimisi oleku- ja ICMP-lubasid. Tavaline ufw status ei näita käsitsi redigeeritud before-reegleid, mistõttu operaatorid järeldavad, et reegel puudub, kuigi see on tegelikult laaditud. Lugege töötlemata loendit ülalt alla, mitte ärge otsige fragmenti. Kui valvurid ilmuvad pärast olekuluba, ei tee piir seda, mida fail vihjab.

Seejärel testige käitumist, mitte teksti. Avage värske ühendus lubatud hosti juurde ja jälgige vastust, suunake kahjutu päring alamvõrgust väljapoole jäävasse sihtkohta ja kinnitage, et see sureb, proovige võrdõiguslikku ühendust, proovige lüüsil kohalikku teenust ja proovige soovimata LAN-ist-kliendi poole ühendust. Kaasake üks ulatusest väljas voog, mis eksisteeris enne muudatust, ja kustutage ainult see voog, mitte ärge tühjendage masina tervet jälgimistabelit.

Kirjutage piirangud reeglite kõrvale: see piirab läbiminekut ja mitte midagi muud. See ei takista kliendil oma internetiühenduse kasutamist, ei takista lubatud LAN-hosti liikluse edasisaatmist ja ei asenda autentimist lubatud teenuste sees.