DNS fan libvirt-gasten reparearje dat troch in mark-basearre VPN-firewall blokkearre wurdt

In mark-basearre VPN-firewall smyt gast-DNS fuort foardat in filterkeatling it sjocht. Ien regel mei mangle-prioriteit markearret de fraach en it antwurd, sûnder dyn LAN iepen te setten.

Gasten op it standert libvirt-netwurk losse nammen perfekt op oant it WireGuard-ynterface omheech komt, en dan stjûket elke syktocht op itselde plak. dnsmasq harket noch altyd op 192.168.122.1:53, de gast hat noch altyd dat adres as resolver, en de fraach komt noch altyd oan. Wat feroare is, is dat de eigen upstream-fraach fan 'e host, of it antwurd dêrop, no fuortsmiten wurdt troch in regel dy't evaluearre wurdt foardat in filterkeatling dy'tsto bewurkje soest. De útgong is in mark dy't betiid genôch tapast wurdt, op in ferbining dy't it antwurd erft.

Gasten ferlieze DNS op it momint dat de tunnel omheech komt

Befêstigje de foarm foardatst wat feroarje. Helje de tunnel del, rin dig @192.168.122.1 example.com fan in gast út, en sjoch it antwurdzjen. Helje de tunnel omheech, werhelje, en sjoch it tiidferrin. Dat pear resultaten slút in stikken libvirt-netwurk, in ferkeard resolver-adres en in deade dnsmasq yn ien stap út.

Sjoch dan nei de hostkant. As dnsmasq de fraach en syn upstream-trochstjoering logt, is it pakket oankommen en is de flater op 'e útgong. As dnsmasq hielendal neat logt, wurdt de fraach fan 'e gast by de yngong fuortsmiten en heart de útsûndering by in oare hook as dy't dit artikel markearret.

Wêrom't in accept-regel yn in lettere keatling nea ôfgiet

In mark-basearre VPN-firewall beslút troch nei de pakketmark of de ferbiningmark te sjen, net nei dyn boarne-adres. Alles wat sûnder de ferwachte mark op it fysike ynterface oankomt, wurdt wegere, en dy wegering bart yn 'e regelset dy't de marktest hat. In ip saddr 192.168.122.0/24 accept-rigel dy't oan in lettere keatling taheakke wurdt, wurdt foar dat pakket gewoan nea rieplachte, dêrom liket de fanselssprekkende regel korrekt en feroaret neat.

It ferbreedzjen oant der wat wurket is de twadde fal. It hiele libvirt-subnet yn 'e yngongspaad fan 'e host akseptearje iepenet elke host-tsjinst foar gasten, wylst de echte needsaak ien poarte is.

It meganisme dat in smelle útsûndering mooglik makket is ferbiningstracking. Assto ct mark op in pakket setst, wurdt de wearde yn 'e conntrack-ymlitsje opslein en net allinnich yn it pakket, dat elk pakket yn dy ferbining draacht it dêrnei, ynklusyf it antwurd fan 'e host werom nei de gast. Dat is de hiele trúk: markearje it fersyk ien kear, en it werompaad is al markearre.

Markearje de fraach foardat de VPN-tabel it sjocht

Set de útsûndering yn syn eigen tabel, sadat in lettere lêzer it fine kin sûnder de VPN-regels te ûntlijen:

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 is negatyf, wat dizze keatling foar de gewoane filterkeatlings pleatst dy't it VPN-pakket by prioriteit nul ynstallearret. De hook-oarder is wat de regel effektyf makket; deselde regel yn in keatling dy't nei de VPN-keatling sortearret, is fersiering.

It marknûmer sels is net oerdraachber. Nim de wearde dy't de ynstalleare VPN-regels foar har eigen ferkear akseptearje, lês dy út 'e libbene regelset en brûk dy. In ferkearde mark produsearret in regel dy't skjin laden wurdt, by elke fraach past en neat talit.

Hâld it gat de breedte fan poarte 53

Sa't it skreaun is, lit dit DNS fan it libvirt-subnet nei de host oer TCP of UDP poarte 53 ta en neat oars. It lit gasten it ynternet bûten de tunnel net berikke, en it lit de host gjin ferbiningen nei gasten iepenje. As in gast letter in oare host-tsjinst nedich hat, foegje dan in aparte regel ta dy't dy bestimmingpoarte neamt ynstee fan dizze te fersachtsjen.

Wês earlik oer watsto ruilest. In gast dy't in resolver berikke kin, kin ek willekeurige gegevens troch DNS-fragen tunnelje, en dizze útsûndering is in bewust gat yn 'e VPN-grins, net in bewearing dat it lokale netwurk fertroud is. It beheinen fan 'e boarne ta 192.168.122.0/24 hâldt it gat fuort fan elk oar lokaal subnet, en it tellen fan fragen tsjin dy boarne is goedkeap as de bedriging foar dy fan belang is.

Meitsje dat it in werstart oerlibbet en bewize beide helten

In regel dy't by in shell-prompt yntype wurdt, ferdwynt by de folgjende opstart, en in regel dy't laden wurdt neidat it VPN-ynterface al ferkear trochlit, ferliest de race by de earste ferbining. Set de tabel yn 'e persistinte nftables-konfiguraasje fan 'e host, of yn in unit dy't foar de VPN-tsjinst oardere is, en kontrolearje de oarder ynstee fan dy oan te nimmen.

Ferifikaasje hat trije aparte antwurden nedich. Befêstigje dat de keatling laden en as earste oardere is, befêstigje dat de conntrack-ymlitsje de mark yn beide rjochtingen sjen lit, en befêstigje dat in syktocht fan in gast in adres weromjout. Befêstigje dan de oare helte: gewoan webferkear fan gasten nei in iepenbiere host mislearret noch altyd wylst de tunnel del is of blokkearret. As DNS wurket en al it oare lekt, is dyn regel breder as dy hjirboppe.

As syktochten noch altyd mislearje neidat de mark op syn plak is, wjerstean de oanstriid om de boarne te ferbreedzjen. Kontrolearje wêr't dnsmasq nei trochstjoert, oft de resolver fan 'e gast nei 192.168.122.1 wiist of nei in iepenbier adres dat immen yntype hat, en oft de fraach de host ea berikt. Markearjen lit it pakket ta en neat oars, dus in minne upstream of in stikken firtueel netwurk bliuwt stikken, hoefolle regels oftst ek tafoegest.

Relatearre artikelen