Libvirt külalise DNS-i parandamine, mille blokeerib märgipõhine VPN-tulemüür

Vaike-libvirt-võrgu külalised lahendavad nimesid laitmatult seni, kuni WireGuard-liides üles tuleb, ja siis takerdub iga päring samasse kohta. dnsmasq kuulab endiselt aadressil 192.168.122.1:53, külalisel on endiselt see aadress lahendajana, ja päring jõuab endiselt kohale. Muutunud on see, et hosti enda ülesvoolu päringu või selle vastuse viskab nüüd ära reegel, mida hinnatakse enne mis tahes filtreerimisahelat, mida sa mõtleksid muuta. Väljapääs on märk, mis rakendatakse piisavalt vara, ühendusele, mille vastus pärib.

Külalised kaotavad DNS-i hetkel, mil tunnel üles tuleb

Kinnita kuju enne millegi muutmist. Võta tunnel alla, käivita külalisest dig @192.168.122.1 example.com ja vaata, et see vastab. Võta tunnel üles, korda ja vaata, et see aegub. See tulemutepaar välistab ühe sammuga katkise libvirt-võrgu, vale lahendaja aadressi ja surnud dnsmasq-i.

Seejärel vaata hosti poolt. Kui dnsmasq logib päringu ja selle ülesvoolu edastuse, jõudis pakett kohale ja viga on väljundis. Kui dnsmasq ei logi üldse midagi, visatakse külalise päring sissepääsus ära ja erand kuulub teise konksu alla kui see, mida see artikkel märgistab.

Miks hilisemas ahelas olev accept-reegel kunagi ei käivitu

Märgipõhine VPN-tulemüür otsustab paketi märgi või ühenduse märgi järgi, mitte sinu lähteaadressi järgi. Kõik, mis saabub füüsilisele liidesele ilma oodatud märgita, lükatakse tagasi, ja see tagasilükkamine toimub reeglistikus, millele märgitest kuulub. Hilisemasse ahelasse lisatud ip saddr 192.168.122.0/24 accept rida lihtsalt ei vaadata selle paketi jaoks kunagi, mistõttu näib ilmne reegel õige ega muuda midagi.

Selle laiendamine, kuni miski töötab, on teine lõks. Kogu libvirti alamvõrgu aktsepteerimine hosti sisendteel avab külalistele kõik hosti teenused, samas kui tegelik vajadus on üks port.

Mehhanism, mis teeb kitsa erandi võimalikuks, on ühenduste jälgimine. Kui seadistad paketile ct mark, salvestatakse väärtus conntrack-kirjesse, mitte ainult paketti, nii et iga pakk selles ühenduses kannab seda edaspidi, sealhulgas vastus hostist tagasi külalisele. See on kogu trikk: märgista päring üks kord ja tagasitee on juba märgistatud.

Märgista päring enne, kui VPN-tabel selle näeb

Pane erand omaette tabelisse, et hilisem lugeja leiaks selle ilma VPN-reegleid sõelumata:

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 negatiivne, mis asetab selle ahela ette tavalised filtreerimisahelad, mille VPN-pakett paigaldab prioriteedil null. Konksude järjekord teeb reegli toimivaks; sama reegel ahelas, mis järjestub pärast VPN-ahelat, on ainult kaunistus.

Märginumber ise ei ole teisaldatav. Võta väärtus, mida paigaldatud VPN-reeglid aktsepteerivad oma liikluse jaoks, loe see elavast reeglistikust ja kasuta seda. Vale märk toodab reegli, mis laaditakse puhtalt, sobib iga päringuga ega lase midagi läbi.

Hoia auk porta 53 laiune

Nii nagu kirjas, lubab see DNS-i libvirti alamvõrgust hosti TCP või UDP pordi 53 kaudu ja mitte midagi muud. See ei lase külalistel jõuda internetti väljaspool tunnelit ega lase hostil avada ühendusi külaliste suunas. Kui külalisel on hiljem vaja teist hostiteenust, lisa eraldi reegel, mis nimetab selle sihtpordi, selle asemel et seda reeglit lõdvendada.

Ole aus selle suhtes, mida sa vahetad. Külaline, kes pääseb lahendajani, võib ka DNS-päringute kaudu suvalisi andmeid tunnelitada, ja see erand on tahtlik lünk VPN-i piiris, mitte väide, et kohalik võrk on usaldusväärne. Allika piiramine aadressiga 192.168.122.0/24 hoiab lünga eemale igast teisest kohalikust alamvõrgust, ja päringute lugemine selle allika vastu on odav, kui oht on sinu jaoks oluline.

Tee see taaskäivituse üle elavaks ja tõesta mõlemad pooled

Käsureale trükitud reegel kaob järgmisel alglaadimisel ja reegel, mis laaditakse pärast seda, kui VPN-liides juba liiklust läbi laseb, kaotab võidujooksu esimesel ühendusel. Pane tabel hosti püsivasse nftables-konfiguratsiooni või unit-i, mis on järjestatud enne VPN-teenust, ja kontrolli järjekorda, selle asemel et seda eeldada.

Kontrollimine nõuab kolme eraldi vastust. Kinnita, et ahel on laaditud ja järjestatud esimesena, kinnita, et conntrack-kirje näitab märki mõlemas suunas, ja kinnita, et külalise päring tagastab aadressi. Seejärel kinnita teine pool: külalise tavaline veebiliiklus avalikku hosti ebaõnnestub endiselt, kuni tunnel on maas või blokeerib. Kui DNS töötab ja kõik muu lekib, on sinu reegel ülaltoodust laiem.

Kui päringud ebaõnnestuvad endiselt pärast märgi paigaldamist, vastusta kiusatust allikat laiendada. Kontrolli, kuhu dnsmasq edasi saadab, kas külalise lahendaja osutab aadressile 192.168.122.1 või avalikule aadressile, mille keegi sisestas, ja kas päring üldse hostini jõuab. Märgistamine laseb paketi läbi ja mitte midagi muud, nii et halb ülesvool või katkine virtuaalvõrk jäävad katkiseks, ükskõik kui palju reegleid lisad.