Konpondu libvirt gonbidatuen DNS marketan oinarritutako VPN suebaki batek blokeatuta

Libvirt sare lehenetsiko gonbidatuek izenak primeran ebazten dituzte WireGuard interfazea altxatzen den arte, eta orduan kontsulta bakoitza leku berean trabatzen da. dnsmasq oraindik 192.168.122.1:53 helbidean entzuten ari da, gonbidatuak oraindik helbide hori du ebazle gisa, eta kontsultak oraindik iristen dira. Aldatu dena da ostalariaren beraren upstream kontsulta, edo hari emandako erantzuna, orain editatzea pentsatuko zenukeen edozein iragazki-kate baino lehenago ebaluatzen den arau batek botatzen duela. Irtenbidea da behar adina goiz aplikatzen den marka bat, erantzunak heredatzen duen konexio batean.

Gonbidatuek DNS galtzen dute tunela altxatzen den unean

Egiaztatu forma ezer aldatu aurretik. Jaitsi tunela, exekutatu dig @192.168.122.1 example.com gonbidatu batetik, eta ikusi erantzuten duela. Altxatu tunela, errepikatu, eta ikusi denbora amaitzen zaiola. Emaitza-bikote horrek libvirt sare hautsia, ebazle helbide okerra eta dnsmasq hila baztertzen ditu urrats bakarrean.

Ondoren begiratu ostalariaren aldetik. Dnsmasq-ek kontsulta eta bere upstream birbidalketa erregistratzen baditu, paketea iritsi da eta hutsegitea irteeran dago. Dnsmasq-ek ezer erregistratzen ez badu, gonbidatuaren kontsulta sarreran botatzen ari da eta salbuespena artikulu honek markatzen duen hook ezberdin bati dagokio.

Zergatik ez den inoiz pizten geroagoko kate bateko accept araua

Marketan oinarritutako VPN suebaki batek pakete-marka edo konexio-marka begiratuz erabakitzen du, ez zure iturburu-helbidea. Marka espero gabe interfaze fisikoan iristen den edozer ukatzen da, eta ukapen hori marka-proba duen arau-multzoan gertatzen da. Geroagoko kate batera gehitutako ip saddr 192.168.122.0/24 accept lerroa ez da inoiz kontsultatzen pakete horretarako, horregatik arau nabaria zuzena dirudi eta ezer ez du aldatzen.

Hori zabaltzea zerbait funtzionatu arte bigarren tranpa da. Ostalariaren sarrera-bidean libvirt azpisare osoa onartzeak ostalariaren zerbitzu guztiak irekitzen dizkie gonbidatuei, benetako beharra portu bat denean.

Salbuespen estu bat ahalbidetzen duen mekanismoa konexioen jarraipena da. Pakete bati ct mark ezartzen diozunean, balioa conntrack sarreran gordetzen da, ez paketean soilik, beraz konexio horretako pakete bakoitzak darama ondoren, ostalaritik gonbidaturako erantzuna barne. Hori da trikimailu osoa: markatu eskaera behin, eta itzulera-bidea jada markatuta dago.

Markatu kontsulta VPN taulak ikusi aurretik

Jarri salbuespena bere taulan, geroagoko irakurle batek VPN arauak aztertu gabe aurki dezan:

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 negatiboa da, eta horrek kate hau VPN paketeak zero lehentasunean instalatzen dituen iragazki-kate arrunten aurretik jartzen du. Hook ordena da araua eraginkor egiten duena; VPN katearen ondoren ordenatzen den kate bateko arau bera apaingarria da.

Marka-zenbakia bera ez da eramangarria. Hartu instalatutako VPN arauek beren trafikoarentzat onartzen duten balioa, irakurri arau-multzo bizitik eta erabili. Marka okerrak arau bat sortzen du, garbi kargatzen dena, kontsulta guztiekin bat egiten duena eta ezer onartzen ez duena.

Eduki zuloa 53 portuaren zabaleran

Idatzita dagoen bezala, honek libvirt azpisaretik ostalarira DNS onartzen du TCP edo UDP 53 portuaren bidez eta besterik ez. Ez die gonbidatuei tunelaz kanpoko internetera iristen uzten, eta ez dio ostalariari gonbidatuetarako konexiorik irekitzen uzten. Gonbidatu batek geroago beste ostalari-zerbitzu bat behar badu, gehitu portu helburu hori izendatzen duen arau bereizi bat, hau lasaitzen duen ordez.

Izan zaitez zintzoa trukatzen ari zarenaren inguruan. Ebazle batera irits daitekeen gonbidatu batek datu arbitrarioak tuneleatu ditzake DNS kontsulten bidez, eta salbuespen hau VPN mugako hutsune deliberatua da, ez sare lokala fidagarria dela dioen adierazpena. Iturburua 192.168.122.0/24-ra mugatzeak zuloa beste edozein sare lokaletatik urrun mantentzen du, eta iturburu horren kontrako kontsultak zenbatzea merkea da mehatxua garrantzitsua bazaizu.

Egin berrabiarazte bat bizirik irauteko eta frogatu bi erdiak

Shell gonbitean idatzitako araua hurrengo abioan desagertzen da, eta VPN interfazea jada trafikoa pasatzen ari denean kargatzen den arauak lehen konexioan galtzen du lasterketa. Jarri taula ostalariaren nftables konfigurazio iraunkorrean, edo VPN zerbitzuaren aurretik ordenatuta dagoen unitate batean, eta egiaztatu ordena suposatu beharrean.

Egiaztatzeak hiru erantzun bereiz behar ditu. Egiaztatu katea kargatuta dagoela eta lehenengo ordenatuta dagoela, egiaztatu conntrack sarrerak marka bi noranzkoetan erakusten duela, eta egiaztatu gonbidatu baten bilaketak helbide bat itzultzen duela. Egiaztatu ondoren beste erdia: gonbidatuen web trafiko arruntak ostalari publiko batera huts egiten jarraitzen du tunela behera edo blokeatzen ari den bitartean. DNS funtzionatzen badu eta gainerako guztia iragazten bada, zure araua goiko baino zabalagoa da.

Bilaketek huts egiten badute marka jarri ondoren, eutsi iturburua zabaltzeko bultzadari. Egiaztatu dnsmasq-ek nora birbidaltzen duen, gonbidatuaren ebazleak 192.168.122.1-ra edo norbaitek idatzitako helbide publiko batera seinalatzen duen, eta kontsulta ostalarira iristen den. Markatzeak paketea onartzen du eta besterik ez, beraz upstream txar bat edo sare birtual hautsia hautsita jarraitzen du zenbat arau gehitzen dituzun.