Harangan ang Isang Saklaw ng Destinasyon para sa Bawat Pool ng Kliyente ng VPN
Kaya ng isang tuntunin ng nftables na tanggihan ang isang prefix ng destinasyon para sa pinapayagang pool ng VPN nang hindi hinahawakan ang sariling trapiko ng gateway. Itugma ang hook at ang posisyon.
Kaya ng isang tuntunin na ilayo ang pinapayagang pool ng VPN mula sa isang saklaw ng destinasyon nang hindi ginagambala ang iba pang ginagawa ng gateway. Ang tuntunin mismo ay maikli; ang mga bahaging nagpapasya kung gumagana ito ay ang hook kung saan ito nakatira at ang posisyon nito sa kadena. Kung magkamali sa dalawang ito, makakakuha ka ng firewall na mukhang tama at kumikilos nang hindi pare-pareho. Magsimula sa ginagawa ng packet kapag nakikita ito ng tuntunin.
Ano ang talagang itinatapat ng tuntunin
Itinatapat ng tuntunin ang tatlong bagay nang sabay: isang interface ng input, isang prefix ng pinagmulan at isang prefix ng destinasyon. Dapat totoo ang tatlo bago ilapat ang drop, at iyon ang nagpapanatili nitong makitid. Mas madaling basahin ito bilang isang ekspresyon kaysa bilang tatlong hiwalay na patakaran.
Ang pagtutugma ng interface ang nagtatangi sa naipasa na trapiko ng kliyente mula sa sariling koneksyon ng gateway. Kung wala ito, ang tuntuning nagbabanggit lamang ng pool ng pinagmulan ay makakaapekto rin sa mga packet na sariling nililikha ng gateway mula sa address na iyon, kung mangyari man ito. Nililimitahan ng prefix ng pinagmulan ang patakaran sa mga pinapayagang kliyente, at ng prefix ng destinasyon sa isang saklaw. Basahin ang tuntunin bilang interseksyon at hindi bilang listahan.
Isulat ang tatlong halaga bago baguhin ang anuman: ang pangalan ng interface ng tunnel, ang pool na ipinamimigay ng server, at ang prefix na balak mong tanggihan. Ang isang typo sa alinman sa mga ito ay lumilikha ng tuntuning malinis na na-parse at walang pinoprotektahan. Itago ang tatlong halagang iyon sa talaan ng pagbabago sa tabi ng tuntunin.
Ang hook ang nagpapasya kung sino ang sinasaklaw ng tuntunin
Ang isang kadena ng netfilter ay nakakabit sa isang hook, at ang hook ang nagpapasya kung aling mga packet ang nakikita ng kadena. Ang hook na forward ay nakakakita ng trapikong niruruta sa gateway, at iyon mismo ang trapiko mula sa kliyente patungo sa destinasyon. Ang lahat ng iba pa sa kadena ay nakatuon sa ibang madla.
Ang hook na input ay nakakakita ng trapikong naka-address sa gateway mismo, kaya ang tuntuning inilagay doon ay namamahala sa pag-access sa sarili nitong mga serbisyo at hindi sa transit. Ang hook na output ay nakakakita ng trapikong pinagmumulan ng gateway mismo, na kabaligtaran ng kailangan ng patakaran ng pool ng kliyente. Ang mga pangalan ng kadena ay arbitraryong label na pinili ng sumulat ng set ng tuntunin, kaya huwag hulaan ang hook mula sa pangalan. Tingnan kung saan nakakabit ang kadena bago ipalagay kung ano ang maaari nitong itapat.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
Ang pagbasa ng pagkakakabit ay isang linyang pagsusuri na pumipigil sa tuntunin na mapunta sa kadenang hindi kailanman nakakakita ng packet.
Ilagay ang tuntunin bago ang malawak na accept
Ang mga tuntunin ay sinusuri ayon sa pagkakasunod-sunod, at ang unang hatol ang nananalo. Ang malawak na accept na mas maaga sa kadena ay nagtatapos sa pagsusuri para sa mga packet na itinatapat nito, kaya ang drop na idinagdag pagkatapos ay hindi kailanman tumatakbo para sa mga iyon. Ang tuntunin sa pagkakasunod-sunod na iyon ang buong dahilan kung bakit ang tuntuning mukhang tama ay maaaring walang epekto.
Ipasok ang tuntunin bago ang accept sa halip na idagdag ito sa dulo. Kung mayroon nang pangkalahatang accept ang kadena para sa interface ng tunnel, dapat mauna ang bagong tuntunin doon, kung hindi ay palamuti lamang ito. Suriin ang nagresultang pagkakasunod-sunod at hindi ang file na inedit mo, dahil ang set ng tuntuning binuo mula sa ilang file ay maaaring hindi tumugma sa alinman sa mga ito. Pagkatapos ay kumpirmahin gamit ang test packet mula sa pool.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf
Ang ikatlong utos ay nag-parse ng file nang hindi ito inilalapat, na humuhuli sa mga syntax error bago pa ito maging outage. Ilapat ito nang may planong rollback, dahil ang maling tuntunin sa kadena ng forward ay maaaring pumutol sa tunnel na ginagamit mo.
Walang pakialam ang mga umiiral na flow sa bago mong tuntunin
Ang entry ng conntrack na nilikha bago pa umiral ang tuntunin ay patuloy na tumutugma sa dating accept. Iyon ang dahilan kung bakit ang bagong drop ay minsang mukhang gumagana para sa mga bagong koneksyon at walang ginagawa para sa sinusuri.
Basahin ang pagtutugma ng state sa tuktok ng kadena. Kung tinatanggap nito ang trapikong established at related bago ang iyong tuntunin, ang bawat flow na nasa daloy na ay patuloy na dadaloy hanggang sa magsara ito. Karaniwan iyon ang pag-uugaling gusto mo para sa emergency na tuntunin, at nakakalito kapag umaasa ka ng agad na pagputol. Magpasya kung aling epekto ang gusto mo bago i-deploy. Ang test na gumagamit muli ng bukas na koneksyon ay magsasabi sa iyo ng maling kuwento.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'
Ipinapakita ng unang utos kung may flow, at ng pangalawa kung tinatanggap pa ito ng maagang tuntunin ng state. Pareho silang read-only at ligtas na patakbuhin habang may insidente.
Ano ang hindi ng tuntuning ito
Ang tuntunin ay hindi blacklist ng domain, patakaran ng IPv6, o paghihigpit sa isang indibidwal na account ng application.
Ang bawat isa sa mga iyon ay nangangailangan ng sariling mekanismo. Ang pagharang ng domain ay kailangang mag-resolve ng mga pangalan, na hindi ginagawa ng filter ng packet. Ang trapikong IPv6 ay nangangailangan ng sariling pagtutugma, dahil walang sinasabi ang ekspresyong ip tungkol sa mga packet na ip6. Ang paghihigpit sa antas ng application ay pag-aari ng serbisyo o ng authenticated na proxy, hindi ng pagtutugma ng prefix. Ang paghihiwalay ng mga pangangailangang iyon ang pumipigil sa isang makitid na tuntunin na utusan ng apat na trabaho.
Ang kontratang ibinibigay ng tuntuning ito ay tumpak: ang trapikong mula sa pinapayagang pool patungo sa isang prefix ng destinasyon ay tinatanggihan, habang ang walang kaugnayang trapiko ng gateway ay nagpapanatili ng umiiral na patakaran nito. Isulat ang pangungusap na iyon sa tabi ng tuntunin, at malalaman ng susunod na tao kung para saan ito.