Ripari DNS de libvirt-gastoj blokitan de mark-bazita VPN-fajroŝirmilo

Gastoj sur la defaŭlta libvirt-reto solvas nomojn perfekte ĝis la WireGuard-interfaco ekfunkcias, kaj tiam ĉiu serĉo haltas ĉe la sama loko. dnsmasq ankoraŭ aŭskultas ĉe 192.168.122.1:53, la gasto ankoraŭ uzas tiun adreson kiel sian solvilon, kaj la peto ankoraŭ alvenas. Kio ŝanĝiĝis estas, ke la propra suprenflua peto de la gastiganto, aŭ la respondo al ĝi, nun estas faligata de regulo, kiu estas taksata antaŭ iu ajn filtra ĉeno, kiun vi pensus redakti. La eliro estas marko aplikata sufiĉe frue, sur konekto, kiun la respondo heredas.

Gastoj perdas DNS en la momento, kiam la tunelo ekfunkcias

Konfirmu la formon antaŭ ol ŝanĝi ion ajn. Mallevu la tunelon, rulu dig @192.168.122.1 example.com el gasto, kaj rigardu ĝin respondi. Levu la tunelon, ripetu, kaj rigardu ĝin tempolimi. Tiu paro da rezultoj ekskludas rompitan libvirt-reton, malĝustan solvilan adreson kaj mortan dnsmasq en unu paŝo.

Poste rigardu la gastigantan flankon. Se dnsmasq protokolas la peton kaj ĝian suprenfluan plusendadon, la pakaĵo alvenis kaj la fiasko estas ĉe la eliro. Se dnsmasq tute ne protokolas ion, la gasta peto estas faligata ĉe la eniro kaj la escepto apartenas al alia hoko ol tiu, kiun ĉi tiu artikolo markas.

Kial akcepta regulo en posta ĉeno neniam ekfunkcias

Mark-bazita VPN-fajroŝirmilo decidas rigardante la pakaĵmarkon aŭ la konektomarkon, ne vian fontadreson. Ĉio, kio alvenas sur la fizika interfaco sen la atendata marko, estas rifuzata, kaj tiu rifuzo okazas en la reguloaro, kiu posedas la markoteston. Linio ip saddr 192.168.122.0/24 accept aldonita al iu posta ĉeno simple neniam estas konsultata por tiu pakaĵo, kaj tial la evidenta regulo ŝajnas ĝusta kaj ŝanĝas nenion.

Larĝigi ĝin ĝis io funkcias estas la dua kaptilo. Akcepti la tutan libvirt-subreton en la enira vojo de la gastiganto malfermas ĉiun gastigantan servon al gastoj, dum la reala bezono estas unu pordo.

La mekanismo, kiu ebligas mallarĝan escepton, estas konektospurado. Kiam vi agordas ct mark sur pakaĵon, la valoro estas konservata en la conntrack-enskribo anstataŭ nur en la pakaĵo, do ĉiu pakaĵo en tiu konekto portas ĝin poste, inkluzive la respondon de la gastiganto reen al la gasto. Tio estas la tuta truko: marku la peton unufoje, kaj la revena vojo jam estas markita.

Marku la peton antaŭ ol la VPN-tabelo vidas ĝin

Metu la escepton en sian propran tabelon, por ke posta leganto povu trovi ĝin sen analizi la VPN-regulojn:

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 estas negativa, kio metas ĉi tiun ĉenon antaŭ la ordinaraj filtraj ĉenoj, kiujn la VPN-pakaĵo instalas ĉe prioritato nulo. La hoko-ordo estas tio, kio igas la regulon efika; la sama regulo en ĉeno, kiu ordiĝas post la VPN-ĉeno, estas ornamaĵo.

La marka numero mem ne estas portebla. Prenu la valoron, kiun la instalitaj VPN-reguloj akceptas por sia propra trafiko, legu ĝin el la viva reguloaro, kaj uzu ĝin. Malĝusta marko produktas regulon, kiu ŝargiĝas pure, kongruas kun ĉiu peto, kaj allasas nenion.

Tenu la truon larĝa kiel pordo 53

Kiel skribite, tio permesas DNS de la libvirt-subreto al la gastiganto tra TCP aŭ UDP pordo 53 kaj nenion alian. Ĝi ne lasas gastojn atingi la interreton ekster la tunelo, kaj ĝi ne lasas la gastiganton malfermi konektojn al gastoj. Se gasto poste bezonas alian gastigantan servon, aldonu apartan regulon nomantan tiun cellokon-pordon anstataŭ malstreĉi ĉi tiun.

Estu honestaj pri tio, kion vi interŝanĝas. Gasto, kiu povas atingi solvilon, ankaŭ povas tuneli arbitrajn datumojn tra DNS-petoj, kaj ĉi tiu escepto estas intenca breĉo en la VPN-limo, ne aserto, ke la loka reto estas fidinda. Limigi la fonton al 192.168.122.0/24 tenas la breĉon for de ĉiu alia loka subreto, kaj nombri petojn kontraŭ tiu fonto estas malmultekosta, se la minaco gravas al vi.

Igu ĝin postvivi restarigon kaj pruvu ambaŭ duonojn

Regulo tajpita ĉe ŝela invito malaperas ĉe la sekva lanĉo, kaj regulo ŝargita post kiam la VPN-interfaco jam pasas trafikon perdas la kuradon ĉe la unua konekto. Metu la tabelon en la daŭran nftables-agordon de la gastiganto, aŭ en unuon ordigitan antaŭ la VPN-servo, kaj kontrolu la ordon anstataŭ supozi ĝin.

Kontrolado bezonas tri apartajn respondojn. Konfirmu, ke la ĉeno estas ŝargita kaj ordigita unue, konfirmu, ke la conntrack-enskribo montras la markon en ambaŭ direktoj, kaj konfirmu, ke gasta serĉo redonas adreson. Poste konfirmu la alian duonon: ordinara gasta reta trafiko al publika gastiganto ankoraŭ fiaskas dum la tunelo estas malsupre aŭ blokas. Se DNS funkcias kaj ĉio alia likas, via regulo estas pli larĝa ol la supra.

Se serĉoj ankoraŭ fiaskas post kiam la marko estas en loko, rezistu la emon larĝigi la fonton. Kontrolu, kien dnsmasq plusendas, ĉu la gasta solvilo montras al 192.168.122.1 aŭ al publika adreso, kiun iu tajpis, kaj ĉu la peto entute atingas la gastiganton. Markado allasas la pakaĵon kaj nenion alian, do malbona suprenfluo aŭ rompita virtuala reto restas rompitaj, kiom ajn da reguloj vi aldonos.