Bakit hindi kailanman umaabot sa FORWARD ang block rule ng OpenVPN client

Dalawang client sa parehong OpenVPN server ay maaaring mag-abot sa isa't isa kahit nagdagdag ka ng DROP rule para sa kanilang pool. Ang rule ay nasa FORWARD chain, malinaw na dumadaloy ang trapiko, at nananatiling zero ang counter ng rule na iyon. Ang natural na konklusyon ay sira ang firewall. Mas madalas, hindi man lang pumasok ang packet sa chain.

May dalawang landas na maaaring tahakin ng peer packet sa OpenVPN server, at ang configuration ang nagpapasya, hindi ang firewall. Ang pag-alam kung aling landas ang ginagamit ay nagsasabi kung ang rule ng host ay nasa tamang lugar.

Dalawang landas na maaaring tahakin ng peer packet

Kapag naka-off ang opsyon ng internal forwarding, dumarating ang packet mula sa client A sa tunnel interface na may destinasyong nasa loob ng inilaang address ng client B. Ipinapadala ito ng routing table ng server pabalik sa parehong tunnel interface, dahil pag-aari ng server ang ruta patungo sa address ng B. Ito ay pagdaloy papasok at palabas sa host, at sinusuri ito ng IPv4 forwarding path.

Kapag naka-on ang opsyon ng internal forwarding, itinatambal ng proseso ng server ang packet sa isang connected client at isinusulat ito pabalik nang direkta sa client na iyon. Hinahawakan ang packet sa loob ng daemon at hindi na kailanman pumapasok muli sa tunnel device, kaya buong nilalaktawan ang forwarding path ng host. Inilalarawan ng OpenVPN 2.6 manual ang opsyong ito bilang internal na forwarding mula client hanggang client, at iyon mismo ang dahilan kung bakit hindi ito nakikita ng firewall rule sa host.

May ikatlong variant sa mga deployment na naglilipat ng data channel sa isang kernel module. Ang desisyon sa forwarding at ang encryption ay lumalabas sa userspace, at kung nakikita ng netfilter ang daloy ay nakasalalay sa kung paano itinayo ang offload path. Huwag kailanman ipagpalagay na kumikilos ang lumang ruleset sa isang offloaded server nang katulad sa isang server sa userspace. Tiyakin ang mode mula sa tumatakbong configuration, hindi sa bersyon ng package.

Kapag hindi gumagalaw ang counter

Ang zero na counter ay nangangahulugang hindi tumugma ang packet sa rule na iyon sa puntong iyon, at maraming dahilan. Ang una ay ang bypass sa itaas: hindi naabot ng trapiko ang chain. Ang pangalawa ay hindi pagtugma sa interface, direksyon, source o destinasyon, na karaniwan kapag muling binilang ang pool at tinutukoy pa rin ng rule ang lumang prefix.

Ang pangatlo ay posisyon. Maaaring tanggapin ng rule na mas maaga sa chain ang daloy bago suriin ang iyong DROP, at ang rule na mas huli ang siyang tunay na nagpapasya sa resulta. Basahin ang chain nang sunod-sunod na may nakikitang counter, pagkatapos tingnan kung aling rule ang tumataas ang bilang kapag inulit mo ang test.

Gumawa ng isang kontroladong pagpapalitan sa pagitan ng dalawang client na ang tunay na address ay natukoy mo mula sa sariling estado ng server, hindi mula sa lease na natatandaan mo. Kung hindi pa rin gumagalaw ang kaugnay na counter, hinala ang landas bago muling isulat ang pagtutugma. Kung gumagalaw ito pero nagtatagumpay pa rin ang koneksyon, nao-override ang drop sa ibang pagkakataon at ang problema ay ang pagkakasunod-sunod. Ang sagot na iyon ang nagpapasya kung ang pag-aayos ay pagbabago ng rule o pagbabago ng topology, kaya kunin ito bago mag-edit ng kahit ano.

Ang pagpili ng hangganan na makakapag-filter

Kung kailangang manatili ang patakaran sa firewall ng host, ilagay ang trapiko kung saan ito nakikita ng firewall. Ang pag-off ng internal forwarding ang sinusuportahang paraan para madaanan ng trapiko ng peer ang tunnel interface at ang forwarding path, kapalit ng pagdaan ng bawat peer packet sa stack ng host.

Pagkatapos, itugma ang daloy nang tumpak. Dumarating ang trapiko sa tunnel interface at lumalabas sa tunnel interface, sa magkabilang direksyon, kaya hindi magtutugma ang mga rule na tanging pisikal na interface ang isinasaalang-alang. Kailangan ng mga address-based na rule ang kasalukuyang pool, at kailangan nilang isaalang-alang ang pabalik na direksyon gayundin ang pasulong.

Maraming deployment ang mas napaglilingkuran ng pag-filter sa antas ng client o grupo, kung saan kilala ang pagkakakilanlan at sinusundan ng patakaran ang user sa halip na isang address na nagbabago kapag muling kumonekta. Iba itong mekanismo kaysa sa chain sa host, at hindi dapat pagsamahin ang dalawa nang walang malinaw na dahilan.

Huwag dalhin nang walang pagbabago ang ruleset ng lumang topology sa isang migration. Ang mga address pool, pangalan ng interface at mode ng forwarding ay nakakaapekto sa kung tumutugma ang isang rule, at ang kinopyang rule na dating gumagana ang pinakapanlinlang na uri ng ebidensya. Magsimula sa daloy na gusto mong payagan at isulat ang rule na tumutugma rito.

Ang pagsubok ng isolation sa halip na magtiwala sa isang rule

Subukan ang ipinagbabawal na kaso at ang pinapayagang kaso sa parehong pagtakbo. Magsimula ng bagong koneksyon mula sa isang client patungo sa isa at tiyaking nabigo ito, pagkatapos ay tiyaking gumagana pa rin ang koneksyong dapat payagan. Kung ang una lang ang sinusubok, mukhang tagumpay ang firewall na humaharang sa lahat.

Ulitin pagkatapos i-reload ang configuration ng server at pagkatapos muling kumonekta ang isang client, dahil ang internal forwarding at mga paglalaan ng pool ay estado sa oras ng pagtakbo. Suriin ang mga counter sa magkabilang direksyon, dahil ang rule na tumutugma sa isang direksyon at hindi sa tugon ay gumagawa ng bahagyang isolation na mahirap mapansin sa mabilis na test.

Ang isolation ay ang naobserbahang resulta sa hangganang tunay na nagdadala ng daloy. Ang DROP rule saanman sa host ay hindi ebidensya; ang isang nabigong koneksyon kasama ang gumalaw na counter sa rule na naging dahilan nito ay ebidensya.