Los libvirt-gaste se DNS wat deur 'n merkgebaseerde VPN-firewall geblokkeer word op

'n Merkgebaseerde VPN-firewall laat gasheer-DNS val voordat enige filterketting dit sien. Een reël met mangle-prioriteit merk die navraag en die antwoord, sonder om jou LAN oop te maak.

Gaste op die verstek libvirt-netwerk los name perfek op totdat die WireGuard-koppelvlak opkom, en dan staan elke opsoeking by dieselfde plek vas. dnsmasq luister steeds op 192.168.122.1:53, die gas het nog daardie adres as sy oplosser, en die navraag kom steeds aan. Wat verander het, is dat die gasheer se eie opstroom-navraag, of die antwoord daarop, nou deur 'n reël laat val word wat geëvalueer word voordat enige filterketting wat jy sou wou wysig, aan die beurt kom. Die uitweg is 'n merk wat vroeg genoeg toegepas word, op 'n verbinding wat die antwoord erf.

Gaste verloor DNS sodra die tonnel opkom

Bevestig die vorm voordat jy enigiets verander. Bring die tonnel af, voer dig @192.168.122.1 example.com vanaf 'n gas uit en kyk of dit antwoord. Bring die tonnel op, herhaal, en kyk of dit uittyd. Daardie paar resultate sluit 'n stukkende libvirt-netwerk, 'n verkeerde oplosseradres en 'n dooie dnsmasq in een stap uit.

Kyk dan na die gasheerkant. As dnsmasq die navraag en sy opstroom-deurstuur log, het die pakket aangekom en is die fout by uitgang. As dnsmasq niks log nie, word die gas se navraag by ingang laat val en hoort die uitsondering op 'n ander haak as dié wat hierdie artikel merk.

Waarom 'n aanvaardingsreël in 'n latere ketting nooit vuur nie

'n Merkgebaseerde VPN-firewall besluit deur na die pakketmerk of die verbindingsmerk te kyk, nie na jou bronadres nie. Enigiets wat op die fisiese koppelvlak aankom sonder die verwagte merk, word geweier, en daardie weiering gebeur in die reëlstel wat die merktoets besit. 'n ip saddr 192.168.122.0/24 accept-reël wat by een of ander latere ketting gevoeg word, word bloot nooit vir daardie pakket geraadpleeg nie, en daarom lyk die ooglopende reël korrek en verander niks.

Om dit te verbreed tot iets werk, is die tweede lokval. Om die hele libvirt-subnet in die gasheer se ingangspad te aanvaar, maak elke gasheerdiens vir gaste oop, terwyl die werklike behoefte een poort is.

Die meganisme wat 'n smal uitsondering moontlik maak, is verbindingopsporing. Wanneer jy ct mark op 'n pakket stel, word die waarde op die conntrack-inskrywing gestoor eerder as net op die pakket, sodat elke pakket in daardie verbinding dit daarna dra, insluitend die antwoord van die gasheer terug na die gas. Dit is die hele truuk: merk die versoek een keer, en die terugpad is reeds gemerk.

Merk die navraag voordat die VPN-tabel dit sien

Plaas die uitsondering in sy eie tabel sodat 'n latere leser dit kan vind sonder om die VPN-reëls te ontleed:

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 negatief, wat hierdie ketting voor die gewone filterkettings plaas wat die VPN-pakket by prioriteit nul installeer. Haakorde is wat die reël effektief maak; dieselfde reël in 'n ketting wat ná die VPN-ketting sorteer, is versiering.

Die merkgetal self is nie oordraagbaar nie. Neem die waarde wat die geïnstalleerde VPN-reëls vir hul eie verkeer aanvaar, lees dit uit die lewende reëlstel en gebruik dit. 'n Verkeerde merk lewer 'n reël wat skoon laai, by elke navraag pas en niks toelaat nie.

Hou die gat die breedte van poort 53

Soos geskryf, laat dit DNS van die libvirt-subnet na die gasheer oor TCP of UDP poort 53 toe en niks anders nie. Dit laat gaste nie die internet buite die tonnel bereik nie, en dit laat die gasheer nie verbindings na gaste oopmaak nie. As 'n gas later 'n ander gasheerdiens nodig het, voeg 'n aparte reël by wat daardie bestemmingspoort noem eerder as om hierdie een te verslap.

Wees eerlik oor wat jy verruil. 'n Gas wat 'n oplosser kan bereik, kan ook willekeurige data deur DNS-navrae tonnel, en hierdie uitsondering is 'n doelbewuste gaping in die VPN-grens eerder as 'n verklaring dat die plaaslike netwerk vertrou word. Om die bron tot 192.168.122.0/24 te beperk, hou die gaping weg van elke ander plaaslike subnet, en om navrae teen daardie bron te tel is goedkoop as die bedreiging vir jou saak maak.

Laat dit herlaai oorleef en bewys albei helftes

'n Reël wat by 'n dopopdrag getik word, verdwyn by die volgende herlaai, en 'n reël wat gelaai word nadat die VPN-koppelvlak reeds verkeer deurlaat, verloor die wedloop op die eerste verbinding. Sit die tabel in die gasheer se volgehoue nftables-konfigurasie, of in 'n eenheid wat voor die VPN-diens bestel word, en kontroleer die ordening eerder as om dit te aanvaar.

Verifikasie het drie afsonderlike antwoorde nodig. Bevestig dat die ketting gelaai en eerste georden is, bevestig dat die conntrack-inskrywing die merk in albei rigtings wys, en bevestig dat 'n gas se opsoeking 'n adres teruggee. Bevestig dan die ander helfte: gewone gas se webverkeer na 'n publieke gasheer misluk steeds terwyl die tonnel af is of blokkeer. As DNS werk en alles anders lek, is jou reël breër as dié hierbo.

As opsoekings steeds misluk nadat die merk in plek is, weerstaan die drang om die bron te verbreed. Kontroleer waarheen dnsmasq deurstuur, of die gas se oplosser na 192.168.122.1 wys of na 'n publieke adres wat iemand ingetik het, en of die navraag hoegenaamd die gasheer bereik. Merk laat die pakket toe en niks anders nie, so 'n slegte opstroom of 'n stukkende virtuele netwerk bly stukkend maak nie saak hoeveel reëls jy byvoeg nie.

Verwante artikels