Panatilihing stable ang patakaran ng nftables habang dumarating ang interface ng VPN

Ang mga tunnel ay pansamantala; ang patakaran ay hindi dapat maging gayon. Sa isang gateway na Linux, ang tuntuning nftables na tumutugma sa interface ng tunnel ayon sa pangalan ay maaaring i-load nang isang beses at patuloy na nalalapat sa tuwing lumilitaw ang interface na iyon. May sariling lifecycle pa rin ang interface: nililikha ito, nawawala, at ang mga ruta at salin sa paligid nito ay sumusunod sa sarili nilang iskedyul. Ang paghihiwalay sa mga may-ari na ito ang nagpapanatili ng stable na pag-access habang nagre-reconnect.

Ang tugma sa pangalan ay mas matagal kaysa sa interface

Naglalaan ang nftables ng numeric na tugma sa index ng interface at ang mga dynamic na tugma sa pangalan iifname at oifname. Ang mga tuntuning gumagamit ng mga pangalang ito ay malinis na naglo-load kahit hindi pa nagagawa ang device ng tunnel, na siyang eksaktong kailangan ng set ng tuntunin sa pag-boot. Humihinto ang tugma kung pinapalitan ng pangalan ang interface at nagpapatuloy kapag kinuha ng bagong interface ang pangalang iyon. Walang ganoong katangian ang numeric na index, kaya ang anyo ng pangalan ang karaniwang pinipili para sa tunnel.

Ang pangalan ay susi ng pagtutugma, hindi ebidensya kung sino ang nasa kabilang dulo. Ang pagpapatotoo ng peer ay nananatiling gawain ng VPN.

Basahin ang chain bago magdagdag ng mga tuntunin

Tingnan kung ano ang nasa set ng tuntunin ngayon at saan ilalagay ang bagong tuntunin, dahil ang pagkakasunod-sunod ang nagtatakda ng resulta.

nft list ruleset
nft -c -f /etc/nftables.conf

Ipinapakita ng listahan ang mga chain, tuntunin at handle, at ang check mode ay nagpapatunay ng kandidatong file nang hindi ito nilo-load. Ang pahintulot para sa tunnel lamang na inilagay pagkatapos ng naunang pagtanggap para sa parehong daloy ay walang binabago, dahil ang unang tumutugmang tuntunin ang nananalo. Kaya ang huling tuntunin ay maaaring magmukhang tama at walang epekto. Basahin ang chain nang sunod-sunod at tiyakin na ang pagbabawal sa trapiko mula sa kliyente patungo sa uplink ay nauuna pa rin sa anumang mas malawak.

Ang mga ruta, salin at daloy ay may ibang may-ari

Ang pagkakaroon ng interface ay hindi gumagawa ng ruta at hindi nagpapatotoo sa peer. Ang mga iyon ay para sa tagapamahala ng VPN, samantalang ang salin ay may ikatlong lifecycle.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

Ipinapakita ng listahan ng conntrack ang umiiral na mga daloy kasama ang kanilang orihinal at isinaling halaga, at ipinapakita ng listahan ng ruta kung ano ang ini-install ng tagapamahala para sa interface. Ang mga tuntunin ng NAT ay nagtatatag ng estado ng pagsubaybay sa koneksyon sa unang packet, kaya ang isang itinatag na daloy ay pinapanatili ang salin nito kahit magbago ang tuntunin. Kaya ang tuntuning ina-update at ang daloy na gumagamit ng bagong landas ay dalawang magkaibang pahayag. Magpasya kung aling mga session ang dapat mag-reconnect at hayaang manatili ang mga walang kaugnayang daloy.

Tanggapin ang cold start, pagkawala at pagbangon

Subukan ang gateway na wala ang tunnel sa pag-boot, pagkatapos mayroon, at pagkatapos ng pagkawala at pagbabalik. Tiyakin na ang ipinagbabawal na pagpapasa ay nananatiling tinatanggihan habang wala ang tunnel, na gumagana ang bagong pinahintulutang daloy kapag napatotohanan na ang peer, at na ang pagbangon ay hindi nangangailangan ng paglilinis ng walang kaugnayang estado. Huwag burahin ang buong chain ng POSTROUTING o bawat entry ng conntrack bilang aksyon ng paghinto ng isang profile, dahil ibinabahagi ito ng ibang serbisyo. Itala kung aling bahagi ang nagbago ng interface, ruta at patakaran, hindi lamang na ang start hook ay natapos nang may zero.

Ang patakarang nakakalampas sa isang reconnect ay ang may mga may-aring pinangalanan at may mga tuntuning nasubok sa tunnel na parehong nakababa at nakaangat. Ang hook na nag-uulat ng tagumpay ay nagpapatunay lamang na tumakbo ang hook.