Ayusin ang DNS ng bisitang libvirt na hinaharang ng firewall ng VPN na nakabatay sa marka
Ang firewall ng VPN na nakabatay sa marka ay nagtatapon ng DNS ng bisita bago pa ito makita ng isang kadena ng filter. Isang tuntunin na may priyoridad na mangle ang nagmamarka ng query at ng sagot nito, nang hindi binubuksan ang iyong LAN.
Ang mga bisita sa default na libvirt network ay perpektong nagreresolba ng mga pangalan hanggang sa umangat ang interface ng WireGuard, at pagkatapos ay tumitigil ang bawat paghahanap sa parehong lugar. dnsmasq ay nakikinig pa rin sa 192.168.122.1:53, mayroon pa rin ang bisita ng address na iyon bilang resolver, at dumarating pa rin ang query. Ang nagbago ay ang upstream query mismo ng host, o ang sagot dito, ay itinatapon na ngayon ng isang tuntuning sinusuri bago ang anumang kadena ng filter na iisipin mong i-edit. Ang labasan ay isang markang inilapat nang sapat na maaga, sa isang koneksyon na minamana ng sagot.
Nawawala ang DNS ng mga bisita sa sandaling umangat ang tunnel
Kumpirmahin ang hugis bago magbago ng kahit ano. Ibaba ang tunnel, patakbuhin ang dig @192.168.122.1 example.com mula sa isang bisita at panoorin itong sumagot. Itaas ang tunnel, ulitin, at panoorin itong mag-time out. Ang pares ng resultang iyon ay nag-aalis ng sirang libvirt network, maling address ng resolver, at patay na dnsmasq sa isang hakbang.
Pagkatapos tingnan ang panig ng host. Kung nila-log ng dnsmasq ang query at ang upstream forward nito, dumating ang packet at ang kabiguan ay sa egress. Kung hindi kailanman nag-log ng kahit ano ang dnsmasq, itinatapon ang query ng bisita sa ingress at ang exception ay kabilang sa ibang hook kaysa sa minamarka ng artikulong ito.
Bakit hindi kailanman pumapalo ang accept rule sa isang susunod na kadena
Ang firewall ng VPN na nakabatay sa marka ay nagpapasya sa pamamagitan ng pagtingin sa marka ng packet o marka ng koneksyon, hindi sa iyong source address. Anumang dumarating sa pisikal na interface nang walang inaasahang marka ay tinatanggihan, at ang pagtanggi ay nangyayari sa set ng mga tuntunin na nagmamay-ari ng pagsubok sa marka. ip saddr 192.168.122.0/24 accept linyang idinagdag sa anumang susunod na kadena ay hindi kailanman isinasaalang-alang para sa packet na iyon, kaya ang halatang tuntunin ay mukhang tama at walang binabago.
Ang pagpapalawak nito hanggang may gumana ay ang ikalawang bitag. Ang pagtanggap sa buong libvirt subnet sa input path ng host ay nagbubukas ng bawat serbisyo ng host sa mga bisita, gayong isang port lang ang tunay na pangangailangan.
Ang mekanismong nagpapangyari ng makitid na exception ay connection tracking. Kapag nagtakda ka ng ct mark sa isang packet, ang halaga ay iniimbak sa conntrack entry at hindi lang sa packet, kaya dinadala ito ng bawat packet sa koneksyong iyon pagkatapos, kasama ang sagot mula sa host pabalik sa bisita. Iyon ang buong pakulo: markahan ang kahilingan nang isang beses, at ang daan pabalik ay nakamarka na.
Markahan ang query bago ito makita ng VPN table
Ilagay ang exception sa sarili nitong table para mahanap ito ng susunod na mambabasa nang hindi binabasa ang mga tuntunin ng VPN:
table inet allowedLocal {
chain guest_dns {
type filter hook input priority mangle; policy accept;
ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
th dport 53 ct mark set 0x00000f41
}
}
priority mangle ay negatibo, na naglalagay ng kadenang ito sa harap ng mga ordinaryong kadena ng filter na ini-install ng VPN package sa priyoridad na zero. Ang ayos ng hook ang nagpapabisa sa tuntunin; ang parehong tuntunin sa kadenang nauuna pagkatapos ng VPN chain ay palamuti lang.
Ang numero ng marka mismo ay hindi portableng dalhin. Kunin ang halagang tinatanggap ng mga naka-install na tuntunin ng VPN para sa sarili nilang trapiko, basahin ito mula sa live na ruleset, at gamitin iyon. Ang maling marka ay gumagawa ng tuntuning malinis na naglo-load, tumutugma sa bawat query, at walang pinapapasok.
Panatilihing kasinglawak ng port 53 ang butas
Gaya ng nakasulat, pinapayagan nito ang DNS mula sa libvirt subnet patungo sa host sa TCP o UDP port 53 at wala nang iba. Hindi nito pinapayagan ang mga bisitang maabot ang internet sa labas ng tunnel, at hindi nito pinapayagan ang host na magbukas ng mga koneksyon patungo sa mga bisita. Kung kailanganin ng isang bisita ang ibang serbisyo ng host mamaya, magdagdag ng hiwalay na tuntuning nagpapangalan sa destinasyong port na iyon sa halip na luwagan ito.
Maging tapat sa ipinagpapalit mo. Ang bisitang nakakaabot sa isang resolver ay maaari ring mag-tunnel ng anumang data sa pamamagitan ng mga query sa DNS, at ang exception na ito ay sadyang butas sa hangganan ng VPN at hindi isang pahayag na mapagkakatiwalaan ang lokal na network. Ang paglilimita sa source sa 192.168.122.0/24 ay naglalayo sa butas na iyon sa bawat iba pang lokal na subnet, at ang pagbilang ng mga query laban sa source na iyon ay mura kung mahalaga sa iyo ang banta.
Gawin itong tumagal pagkatapos ng reboot at patunayan ang dalawang kalahati
Ang tuntuning tinipa sa shell prompt ay nawawala sa susunod na boot, at ang tuntuning na-load pagkatapos na nagpapasa na ng trapiko ang VPN interface ay natatalo sa karera sa unang koneksyon. Ilagay ang table sa persistenteng nftables configuration ng host, o sa isang unit na inayos bago ang serbisyo ng VPN, at suriin ang ayos sa halip na ipagpalagay ito.
Kailangan ng beripikasyon ng tatlong hiwalay na sagot. Kumpirmahin na ang kadena ay na-load at inayos muna, kumpirmahin na ang conntrack entry ay nagpapakita ng marka sa dalawang direksyon, at kumpirmahin na ang paghahanap ng bisita ay nagbabalik ng address. Pagkatapos kumpirmahin ang kabilang kalahati: ang ordinaryong web traffic ng bisita patungo sa pampublikong host ay nabigo pa rin habang nakababa o nagba-block ang tunnel. Kung gumagana ang DNS at tumutulo ang lahat ng iba, mas malawak ang tuntunin mo kaysa sa nasa itaas.
Kung nabigo pa rin ang mga paghahanap matapos mailagay ang marka, pigilan ang hilig na palawakin ang source. Suriin kung saan nagfo-forward ang dnsmasq, kung ang resolver ng bisita ay nakaturo sa 192.168.122.1 o sa pampublikong address na tinipa ng isang tao, at kung umaabot ba ang query sa host. Ang pagmamarka ay nagpapapasok ng packet at wala nang iba, kaya ang masamang upstream o sirang virtual network ay mananatiling sira gaano man karaming tuntunin ang idagdag mo.