Harangan ang isang OpenVPN client mula sa LAN nang hindi hinihinto ang tunnel
I-pin ang tunnel address ng client sa certificate nito, i-drop ang LAN traffic nito sa ulo ng FORWARD, pagkatapos i-verify ang IPv6, mga sinusubaybayang session at pagtayo pagkatapos ng reboot.
Isang client sa iyong OpenVPN server ang dapat mawalan ng LAN access habang ang lahat ng iba pang tunnel ay tumatakbo. Kung hahanapin mo ito, kadalasang sinasabi ng pinakamagandang sagot na hindi kaya ng daemon, na kalahati lang ng totoo: walang firewall bawat client ang OpenVPN, ngunit ang host na nagtatapos ng tunnel ay nag-filter na ng mga packet. Ang dalawang desisyong mahalaga ay ang pagkakakilanlang hinaharangan mo at ang posisyon ng patakaran. Gawin nang tama ang dalawa at ang pagbabago ay magiging isang linyang masusubok at matatanggal mo.
I-pin ang client bago isulat ang patakaran
Nagpapaupa ang OpenVPN ng tunnel address mula sa pool, kaya ang 10.8.0.6 ay isang upuan, hindi isang tao. Kapag natapos ang session, bumabalik ang upa at maaaring ibigay sa susunod na koneksyon, ibig sabihin sinusundan ng patakarang isinulat laban sa address na iyon ang upuan, hindi ang user. Kaya magpasya muna kung ano talaga ang hinaharangan mo: isang address para sa maikling eksperimento, o isang certificate para sa taong gusto mong ilayo.
Para iugnay ang address sa certificate, gumawa ng file sa directory na tinutukoy ng client-config-dir at ibigay sa file ang eksaktong common name ng certificate. Maglagay ng isang direktiba sa loob, ifconfig-push 10.8.0.6 255.255.255.0, at pinananatili ng client na iyon ang parehong tunnel address sa mga muling pagkonekta. Dalawang setting ang dapat umiral para magkabisa ito: dapat ideklara ang client-config-dir sa configuration ng server, at ang ipinapadalang address ay dapat nasa subnet na kayang i-route ng server. Kapag kulang ang isa, binabalewala ang file nang walang error, na nagpapalito sa susunod na pagsubok ng firewall.
Ang pansamantalang pagharang ay maaaring gumamit ng pool address, basta itinatala ng ticket kung aling session ang may hawak nito noon.
Ang pagkakasunod-sunod ang nagpapasya kung tatakbo ang pag-drop
Sa isang Linux gateway na nagpapasa sa pagitan ng tunnel at LAN, dumadaan ang mga packet sa chain na FORWARD. Basahin ang utos sa ibaba bilang isang pangungusap: ipasok sa ulo ng FORWARD, itugma ang traffic na pumapasok mula sa tun0, mula sa nag-iisang host na iyon, na nakatuon sa subnet ng LAN, at i-drop ito.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROPAng -I ang nagpapagana ng patakaran. Kapag idinagdag gamit ang -A, napupunta ito sa ilalim ng anumang malawak na pagtanggap para sa subnet ng tunnel at hindi kailanman nakakakita ng packet. I-verify ang posisyon gamit ang iptables -vnL FORWARD --line-numbers, at basahin din ang mga counter: ang pag-drop sa itaas na walang binibilang ay nangangahulugang dumarating ang traffic sa ibang daan.
Ang sariling LAN address ng gateway ay ibang daan. Ang mga packet na ipinadala sa kahon mismo ay pumupunta sa INPUT, hindi sa FORWARD, kaya maaaring mawalan ng LAN host ang client at makapagbukas pa rin ng admin page ng router. Idagdag ang tumutugmang patakaran na INPUT kapag mahalaga iyon.
Ano ang hindi nakikita ng filter
Nangyayari ang pag-filter kapag sinusuri ang packet, kaya ang naitatag na TCP session ay maaaring magpatuloy hanggang sarado o ma-reset. Kung kailangang kumagat agad ang pagharang, linisin ang mga sinusubaybayang flow para sa source na iyon gamit ang conntrack -D -s 10.8.0.6 pagkatapos maipasok ang patakaran. Kung katanggap-tanggap ang ilang segundong overlap, itala ang pagpipiliang iyon sa halip na iwanan itong implicit. Anuman ang mangyari, kailangang malaman ng susunod na tao kung pinipigilan ng patakaran ang buhay na traffic o ang mga bagong koneksyon lamang.
Hindi kailanman hinahawakan ng traffic sa pagitan ng peers ang firewall ng host. Kapag naka-enable ang client-to-client, ipinapasa ng OpenVPN ang mga packet na iyon sa loob ng daemon, kaya ni FORWARD ni INPUT ay hindi sila nakikita. Ang tanging solusyon ay patayin ang client-to-client o tanggapin na kayang maabot ng mga peer ang isa't isa; hindi makikita ng patakaran ng iptables ang traffic na iyon.
IPv6, firmware at pagtayo pagkatapos ng reboot
Walang sinasabi ang patakaran ng IPv4 tungkol sa IPv6. Kung dinadala ng tunnel at LAN ang dalawang pamilya, dapat umiral ang katumbas na patakaran sa ip6tables, o sa set ng patakaran ng nftables na nagmamay-ari ng patakaran sa host na iyon. Madalas itago ng firmware ng router ang netfilter sa likod ng sarili nitong abstraction, kaya maaaring hindi umubra ang syntax at mga pangalan ng talahanayang kinopya mula sa forum.
Sa OpenWrt, ang dokumentadong daan ay isang entry sa configuration ng firewall at hindi isang linyang iptables na isinulat sa kamay, at ang linyang isinulat sa kamay ay maaaring mawala kapag nag-reload ang firewall. Ibinabalik ng ibang distribusyon ang mga patakaran sa pamamagitan ng netfilter-persistent, isang boot unit o imbakan ng vendor, at ang mga mekanismong iyon ay hindi mapagpapalit. Patunayan ang pinili mo sa pamamagitan ng reboot, dahil ang reload ay nagsasanay ng ibang daan.
I-verify ayon sa daan, pagkatapos ay i-roll back nang malinis
Subukan ang bawat daan nang hiwalay, dahil ang isang matagumpay na pagsusuri ay nagtatago sa iba. Ang hinarangang client ay dapat pa ring makarating sa internet sa pamamagitan ng tunnel ngunit mabibigo laban sa isang LAN host, ang pangalawang client ay dapat makarating sa parehong host, at ang address ng gateway at ang daan ng peer ay nangangailangan ng kani-kanilang obserbasyon. Isulat ang mga resulta sa tabi ng patakaran upang ang susunod na pagbabago ay may baseline. Ang talahanayan sa ibaba ang set na sulit itago sa ticket.
| Daan | Inaasahan sa patakaran | Kapag nabigo |
|---|---|---|
| Hinarangang client patungo sa isang LAN host | Walang sagot | Ang patakaran ay nasa ilalim ng isang pagtanggap, o hindi tugma ang source |
| Hinarangang client patungo sa internet | Gumagana sa pamamagitan ng tun0 | Masyadong malawak ang patakaran, walang tugma sa destinasyon |
| Pangalawang client patungo sa parehong LAN host | Gumagana | Nagtugma ang patakaran sa higit pa sa inaasahang host |
| Hinarangang client patungo sa LAN address ng gateway | Hinarang lamang kapag may tumutugmang patakaran sa INPUT | Walang patakaran sa INPUT |
| Hinarangang client patungo sa tunnel address ng isang peer | Gumagana pa rin | client-to-client ay naka-enable at labas sa saklaw ng firewall |
Ang rollback ay pagbura ayon sa espesipikasyon, hindi flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP ay nag-aalis ng eksaktong entry na iyon at iniiwan ang natitirang bahagi ng chain na buo. Alisin ang parehong linya mula sa alinmang file na nagbabalik ng mga patakaran sa boot, i-reload ito, at kumpirmahin na nakarating muli ang client sa LAN host. Ang flush ng FORWARD ay magpapawalang-bisa rin ng mga patakarang hindi mo isinulat, na ginagawang pangalawang insidente ang rollback.
Bago isara ang ticket, kumpirmahin ang tatlong bagay: tugma ang naka-pin na address sa certificate, ang patakaran ay nasa itaas ng mga pagtanggap na may counter na hindi zero, at ang file ng persistence ay naglalaman ng parehong patakarang sinubukan mo. Kung may kulang, ang pagharang ay ilusyon sa isang session ng shell.