Korjaa libvirt-vieraan DNS, jonka merkkipohjainen VPN-palomuuri estää

Oletusarvoisen libvirt-verkon vieraat ratkaisevat nimiä moitteettomasti, kunnes WireGuard-rajapinta nousee, ja silloin jokainen haku juuttuu samaan kohtaan. dnsmasq kuuntelee edelleen osoitteessa 192.168.122.1:53, vieraalla on edelleen tuo osoite ratkaisijanaan, ja kysely saapuu edelleen. Muutos on siinä, että isäntäkoneen oman ylävirran kyselyn tai siihen annetun vastauksen pudottaa nyt sääntö, joka arvioidaan ennen mitä tahansa suodatinketjua, jota kuvittelisit muokkaavasi. Ulospääsy on merkki, joka asetetaan riittävän aikaisin, yhteydelle, jonka vastaus perii.

Vieraat menettävät DNS:n heti, kun tunneli nousee

Vahvista muoto ennen kuin muutat mitään. Laske tunneli alas, aja dig @192.168.122.1 example.com vieraasta ja katso sen vastaavan. Nosta tunneli, toista ja katso sen aikakatkaisevan. Se tulosepari sulkee pois rikkinäisen libvirt-verkon, väärän ratkaisijan osoitteen ja kuolleen dnsmasqin yhdessä vaiheessa.

Katso sitten isäntäkoneen puolelta. Jos dnsmasq kirjaa kyselyn ja sen ylävirran välityksen, paketti saapui ja vika on lähdössä. Jos dnsmasq ei kirjaa mitään, vieraan kysely pudotetaan sisääntulossa ja poikkeus kuuluu eri koukkuun kuin se, jonka tämä artikkeli merkitsee.

Miksi myöhemmässä ketjussa oleva accept-sääntö ei koskaan laukea

Merkkipohjainen VPN-palomuuri päättää katsomalla paketin merkkiä tai yhteyden merkkiä, ei lähdeosoitettasi. Kaikki, mikä saapuu fyysiselle rajapinnalle ilman odotettua merkkiä, hylätään, ja se hylkäys tapahtuu sääntöjoukossa, joka omistaa merkkitestin. Myöhempään ketjuun lisätty ip saddr 192.168.122.0/24 accept-rivi jää yksinkertaisesti koskaan huomiotta kyseisen paketin osalta, minkä vuoksi ilmeinen sääntö näyttää oikealta eikä muuta mitään.

Sen leventäminen, kunnes jokin toimii, on toinen ansa. Koko libvirt-aliverkon hyväksyminen isäntäkoneen tuloreitillä avaa kaikki isäntäkoneen palvelut vieraille, vaikka todellinen tarve on yksi portti.

Mekanismi, joka mahdollistaa kapean poikkeuksen, on yhteyksien seuranta. Kun asetat ct mark-arvon paketille, arvo tallennetaan conntrack-tietueeseen eikä vain pakettiin, joten jokainen kyseisen yhteyden paketti kantaa sen sen jälkeen, mukaan lukien vastaus isäntäkoneesta takaisin vieraalle. Siinä koko temppu: merkitse pyyntö kerran, ja paluureitti on jo merkitty.

Merkitse kysely ennen kuin VPN-taulu näkee sen

Laita poikkeus omaan tauluunsa, jotta myöhempi lukija löytää sen jäsentämättä VPN-sääntöjä:

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 on negatiivinen, mikä sijoittaa tämän ketjun tavallisten suodatinketjujen edelle, jotka VPN-paketti asentaa prioriteetilla nolla. Koukkujen järjestys tekee säännöstä tehokkaan; sama sääntö ketjussa, joka järjestyy VPN-ketjun jälkeen, on koristetta.

Itse merkkiluku ei ole siirrettävä. Ota arvo, jonka asennetut VPN-säännöt hyväksyvät omalle liikenteelleen, lue se elävästä sääntöjoukosta ja käytä sitä. Väärä merkki tuottaa säännön, joka latautuu puhtaasti, osuu jokaiseen kyselyyn eikä päästä mitään läpi.

Pidä reikä portin 53 levyisenä

Kirjoitetussa muodossaan tämä sallii DNS:n libvirt-aliverkosta isäntäkoneelle TCP- tai UDP-portin 53 kautta eikä mitään muuta. Se ei päästä vieraita internetiin tunnelin ulkopuolella eikä anna isäntäkoneen avata yhteyksiä vieraisiin päin. Jos vieras tarvitsee myöhemmin toista isäntäpalvelua, lisää erillinen sääntö, joka nimeää kyseisen kohdeportin, sen sijaan että löysäisit tätä.

Ole rehellinen siitä, mitä vaihdat. Vieras, joka pääsee ratkaisijaan, voi myös tunneloida mielivaltaista dataa DNS-kyselyjen kautta, ja tämä poikkeus on tarkoituksellinen aukko VPN-rajassa, ei väite, että paikallisverkkoon voi luottaa. Lähteen rajaaminen osoitteeseen 192.168.122.0/24 pitää aukon poissa kaikista muista paikallisista aliverkoista, ja kyselyjen laskeminen tuota lähdettä vastaan on halpaa, jos uhka on sinulle merkityksellinen.

Tee siitä uudelleenkäynnistyksen kestävä ja todista molemmat puolet

Komentokehotteeseen kirjoitettu sääntö katoaa seuraavassa käynnistyksessä, ja sääntö, joka ladataan sen jälkeen kun VPN-rajapinta jo välittää liikennettä, häviää kilpajuoksun ensimmäisellä yhteydellä. Laita taulu isäntäkoneen pysyvään nftables-kokoonpanoon tai unitiin, joka on järjestetty ennen VPN-palvelua, ja tarkista järjestys sen sijaan että olettaisit sen.

Vahvistus tarvitsee kolme erillistä vastausta. Vahvista, että ketju on ladattu ja järjestetty ensimmäiseksi, vahvista, että conntrack-tietue näyttää merkin molempiin suuntiin, ja vahvista, että vieraan haku palauttaa osoitteen. Vahvista sitten toinen puoli: vieraan tavallinen verkkoliikenne julkiseen isäntään epäonnistuu edelleen, kun tunneli on alhaalla tai estää. Jos DNS toimii ja kaikki muu vuotaa, sääntösi on leveämpi kuin yllä oleva.

Jos haut epäonnistuvat edelleen merkin asettamisen jälkeen, vastusta houkutusta levittää lähdettä. Tarkista, mihin dnsmasq välittää, osoittaako vieraan ratkaisija 192.168.122.1-osoitteeseen vai julkiseen osoitteeseen, jonka joku on kirjoittanut, ja saavuttaako kysely ylipäätään isäntäkoneen. Merkitseminen päästää paketin läpi eikä mitään muuta, joten huono ylävirta tai rikkinäinen virtuaaliverkko pysyvät rikkinäisinä riippumatta siitä, kuinka monta sääntöä lisäät.