Takmarka OpenVPN-hlið við eitt staðarnet með UFW-reglum

Ákveddu leyfið áður en þú opnar eldveggjarskrá: auðkenndir þjónar mega opna tengingar við eitt tiltekið undirnet, og hliðið verður að hafna sérhverri annarri gegnumferðarleið, jafnvel þegar þjónn setur upp fleiri slóðir. Þessi setning er hönnunin, og hver regla hér fyrir neðan er til að framfylgja henni. Eitthvað víðtækara, eins og allt einkaskrársvæðið, útgangur á netið gegnum skotgöngin eða jafningjauppstreymi, er önnur hönnun sem þarf sína eigin ákvörðun. Reglurnar eru líka viljandi leiðinlegar, því snjall eldveggur er sá sem enginn getur endurskoðað síðar.

Skrifaðu topólógíuna og leyfið niður fyrst

Dæmið notar Community OpenVPN þjón með TUN-tæki í notendarými sem heitir tun0, þjónahóp 10.77.0.0/24, og eitt tengt undirnet 192.168.60.0/24 á lan0. IPv4-framsending virkar þegar og staðarnetið er þegar með bakleið að hópnum, svo ekkert hér fer eftir þýðingu milli þeirra.

UFW á eldvegginn á þessum vélarhýsli, og ekkert gámarreglusett eða sérstök nftables-tafla má setja upp fyrri samþykkisleið. Flýtileið fyrir afhleðslu flæðis sem sleppir síunni myndi gera vörðukeðjurnar að skrauti, svo staðfestu að engin sé virk. Láttu eigin client-to-client framsendingu OpenVPN vera óvirka, því jafningjauppstreymi sem fer aldrei í gegnum síu stýrikerfisins er ekki hægt að takmarka með henni. Ytri hlustandinn og stjórnunarreglurnar halda sér eins og þær eru, þar sem þessi breyting stýrir afkóðuðu skotgönguuphaldi frekar en að skipta um eldvegginn.

Setjið vörðurnar fyrir fyrstu samþykki UFW

Slóðarleyfi og síðan höfnun er ekki nóg fyrir ströng mörk. Sjálfgefnar before-reglur samþykkja uppsett uppstreymi og valin ICMP áður en nokkur notendaregla er skoðuð, svo flæði sem var leyft í síðustu viku getur verið utan nýju ákvörðunarstaðartakmörkunarinnar einfaldlega vegna þess að það hefur enn stöðu. Taktu öryggisafrit af UFW-skránum og hafðu bandlausa stjórnborðið opið áður en þú breytir.

Í hlutanum *filter í skránni /etc/ufw/before.rules skaltu lýsa yfir tveimur keðjum við hlið núverandi yfirlýsinga og fyrir hvaða reglulínu sem er.

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

Straxt eftir yfirlýsingarnar, og fyrir leyfin fyrir inntak og framsendingu, stökktu inn í þær og skilgreindu hvað þær hleypa í gegn.

-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

Haltu restinni af hlutanum og COMMIT línu hans. Að líma aðra síutöflu eða eyða ótengdum reglum er leiðin sem eldveggjabreyting verður að niðurfalli, og skráin er eina endurræsing frá því að vera eina eintakið sem skiptir máli.

Lestu hvað hver vörð hleypir í gegn og hafnar

Fyrsta keðjan heldur áfram vinnslu aðeins þegar uppruninn er í hópnum, áfangastaðurinn er eina undirnetið, útgangsviðmótið er staðarnetið og pakkinn fer í upprunalega stefnu flæðis síns. Öllu öðru sem kemur úr skotgöngunum er kastað, þar á meðal uppruna utan hópsins og hvaða áfangastað sem er handan leyfða undirnetsins.

Jafningjapakki fer inn og út tun0, svo hann fellur á viðmótsprófi staðarnetsins jafnvel áður en áfangastaðaprófun er náð. Nýjar tengingar frá staðarnetinu til þjónanna falla líka á stefnuprófi svarsins, sem lokar afturköllunarleiðinni sjálfgefið.

Markið RETURN heldur venjulegri UFW-stefnu í gildi. Þessar keðjur sía, og slóðarleyfið sem þú bætir við næst ákveður enn hvort pakki sem lifir verði samþykktur. Þessi aðskilnaður er það sem gerir þér kleift að breyta leyfða undirnetinu á einum stað síðar. Ef vörðurnar samþykktu pakka beint þyrfti að bæta hverri framtíðarreglu við tvisvar.

Leyfðu undirnetið og lokaðu hliðardyrunum

Forskoðaðu slóðarleyfið fyrst og fjarlægðu svo forskoðunarflaggið til að beita því: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Eftir það skaltu fara yfir röð notendareglnanna, því fyrri höfnun vinnur enn gegn síðara leyfi. Leyfi fyrir allt undirnetið er líka rangt form þegar aðeins HTTPS-gátt einnar vélarhýsis á að vera aðgengileg.

Taktu eftir hvað inntakskastið gerir: skotgönguþjónar komast ekki í neina þjónustu á hliðinu sjálfu, þar á meðal DNS-hlustanda sem er bundinn við staðarnetsheimilisfang þess. Að hýsa DNS þar krefst viljandi undantekningar fyrir kastið og endurskoðaðs leyfissamnings. Ef UFW stýrir IPv6 skaltu bæta samsvarandi köstum fyrir tun0 í before6.rules líka, því listi yfir IPv4-áfangastaði segir ekkert um IPv6-pakka.

Staðfestu hlaðna stefnu, ekki forskoðunina

Forskoðaðu endurhleðsluna, beittu henni í viðhaldsglugga og lestu lifandi reglusettið.

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

Staðfestu að skotgönguvörðurnar birtist fyrir sjálfgefnu stöðu- og ICMP-leyfunum. Venjulegt ufw status sýnir ekki handbreyttar before-reglur, og þess vegna álykta rekstraraðilar að regla vanti þegar hún er í raun hlaðin. Lestu hráa listann frá toppi til botns í stað þess að leita að broti. Ef vörðurnar birtast eftir stöðuleyfi er mörkin ekki að gera það sem skráin gefur í skyn.

Prófaðu svo hegðun frekar en texta. Opnaðu nýja tengingu við leyfða vélhýsi og fylgstu með svarinu, beindu meinlausri beiðni að áfangastað utan undirnetsins og staðfestu að hún deyi, prófaðu jafningjatengingu, prófaðu þjónustu sem er staðbundin á hliðinu og prófaðu óumbeðna staðarnet-til-þjóns tengingu. Láttu eitt flæði utan sviðs sem var til fyrir breytinguna fylgja með, og hreinsaðu aðeins það flæði í stað þess að tæma alla rekstrartöflu vélarinnar.

Skráðu takmarkanirnar við hlið reglnanna: þetta takmarkar gegnumferð og ekkert annað. Það kemur í veg fyrir að þjónn noti eigin nettengingu, kemur í veg fyrir að leyft staðarnetshýsil sendi uppstreymi áfram, og kemur ekki í stað auðkenningar innan leyfðu þjónustanna.