Rregulloni DNS-në e mysafirit libvirt që bllokohet nga një firewall VPN i bazuar në shenja

Mysafirët në rrjetin e parazgjedhur libvirt i zgjidhin emrat në mënyrë të përsosur derisa të ngrihet ndërfaqja WireGuard, dhe pastaj çdo kërkim ngec në të njëjtin vend. dnsmasq vazhdon të dëgjojë në 192.168.122.1:53, mysafiri vazhdon ta ketë atë adresë si zgjidhës, dhe kërkesa vazhdon të mbërrijë. Ajo që ka ndryshuar është se vetë kërkesa e sipërme e hostit, ose përgjigjja ndaj saj, tani hidhet poshtë nga një rregull që vlerësohet përpara çdo zinxhiri filtri që do të mendonit të redaktonit. Rruga e daljes është një shenjë e vendosur mjaft herët, mbi një lidhje që përgjigjja e trashëgon.

Mysafirët humbin DNS në momentin që tuneli ngrihet

Konfirmoni formën përpara se të ndryshoni çdo gjë. Ulni tunelin, ekzekutoni dig @192.168.122.1 example.com nga një mysafir dhe shikoni se përgjigjet. Ngrini tunelin, përsëritni dhe shikoni se skadon. Ai çift rezultatesh përjashton në një hap një rrjet libvirt të prishur, një adresë zgjidhësi të gabuar dhe një dnsmasq të vdekur.

Pastaj shikoni anën e hostit. Nëse dnsmasq regjistron kërkesën dhe përcjelljen e sipërme të saj, paketa mbërriti dhe dështimi është në dalje. Nëse dnsmasq nuk regjistron kurrë asgjë, kërkesa e mysafirit hidhet në hyrje dhe përjashtimi i takon një grep tjetër, jo atij që shënon ky artikull.

Pse një rregull accept në një zinxhir të mëvonshëm nuk aktivizohet kurrë

Një firewall VPN i bazuar në shenja vendos duke shikuar shenjën e paketës ose shenjën e lidhjes, jo adresën tuaj burimore. Çdo gjë që mbërrin në ndërfaqen fizike pa shenjën e pritur refuzohet, dhe ai refuzim ndodh në grupin e rregullave që zotëron provën e shenjës. ip saddr 192.168.122.0/24 accept rresht i shtuar në çdo zinxhir të mëvonshëm thjesht nuk merret kurrë parasysh për atë paketë, prandaj rregulli i dukshëm duket i saktë dhe nuk ndryshon asgjë.

Zgjerimi i tij derisa diçka të funksionojë është kurthi i dytë. Pranimi i të gjithë nënrrjetit libvirt në rrugën hyrëse të hostit i hap çdo shërbim të hostit mysafirëve, kur nevoja reale është një port.

Mekanizmi që e bën të mundur një përjashtim të ngushtë është gjurmimi i lidhjeve. Kur vendosni ct mark mbi një paketë, vlera ruhet në hyrjen conntrack dhe jo vetëm në paketë, kështu që çdo paketë e asaj lidhje e mbart më pas, përfshirë përgjigjjen nga hosti përsëri te mysafiri. Ky është i gjithë truku: shënoni kërkesën një herë dhe rruga e kthimit është tashmë e shënuar.

Shënoni kërkesën përpara se ta shohë tabela VPN

Vendoseni përjashtimin në tabelën e vet, që një lexues i mëvonshëm ta gjejë pa analizuar rregullat VPN:

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 është negativ, gjë që e vendos këtë zinxhir përpara zinxhirëve të zakonshëm të filtrave që paketa VPN i instalon me përparësi zero. Rendi i grepave është ai që e bën rregullin efektiv; i njëjti rregull në një zinxhir që renditet pas zinxhirit VPN është thjesht zbukurim.

Numri i shenjës në vetvete nuk është i transportueshëm. Merrni vlerën që rregullat e instaluara të VPN-së pranojnë për trafikun e tyre, lexojeni nga grupi i rregullave aktiv dhe përdoreni atë. Një shenjë e gabuar prodhon një rregull që ngarkohet pastër, përputhet me çdo kërkesë dhe nuk pranon asgjë.

Mbajeni vrimën sa gjerësia e portës 53

Siç është shkruar, kjo lejon DNS nga nënrrjeti libvirt drejt hostit përmes TCP ose UDP në portën 53 dhe asgjë tjetër. Nuk i lejon mysafirët të arrijnë internetin jashtë tunelit dhe nuk e lejon hostin të hapë lidhje drejt mysafirëve. Nëse një mysafir ka nevojë më vonë për një shërbim tjetër të hostit, shtoni një rregull të veçantë që emërton atë portë destinacioni në vend që ta lehtësoni këtë.

Jini i sinqertë për atë që po shkëmbeni. Një mysafir që mund të arrijë një zgjidhës mund të tunelojë gjithashtu të dhëna arbitrare përmes kërkesave DNS, dhe ky përjashtim është një vrimë e qëllimshme në kufirin e VPN-së, jo një deklaratë se rrjeti lokal është i besuar. Kufizimi i burimit në 192.168.122.0/24 e mban vrimën larg çdo nënrrjeti tjetër lokal, dhe numërimi i kërkesave ndaj atij burimi është i lirë nëse kërcënimi ka rëndësi për ju.

Bëjeni të mbijetojë rinisjen dhe provoni të dyja gjysmat

Një rregull i shtypur në një prompt shell zhduket në nisjen tjetër, dhe një rregull i ngarkuar pasi ndërfaqja VPN tashmë po kalon trafik e humb garën në lidhjen e parë. Vendoseni tabelën në konfigurimin e vazhdueshëm nftables të hostit, ose në një njësi të renditur përpara shërbimit VPN, dhe kontrolloni rendin në vend që ta supozoni.

Verifikimi kërkon tri përgjigje të veçanta. Konfirmoni se zinxhiri është ngarkuar dhe renditur i pari, konfirmoni se hyrja conntrack e tregon shenjën në të dy drejtimet, dhe konfirmoni se një kërkim i mysafirit kthen një adresë. Pastaj konfirmoni gjysmën tjetër: trafiku normal i uebit të mysafirit drejt një hosti publik vazhdon të dështojë ndërsa tuneli është ulur ose bllokon. Nëse DNS funksionon dhe gjithçka tjetër rrjedh, rregulli juaj është më i gjerë se ai më sipër.

Nëse kërkimet vazhdojnë të dështojnë pasi shenja është vendosur, përmbajeni dëshirën për të zgjeruar burimin. Kontrolloni ku përcjell dnsmasq, nëse zgjidhësi i mysafirit tregon drejt 192.168.122.1 apo drejt një adrese publike që dikush e ka shtypur, dhe nëse kërkesa mbërrin fare te hosti. Shënimi e pranon paketën dhe asgjë tjetër, kështu që një burim i sipërm i keq ose një rrjet virtual i prishur mbeten të prishur, sado rregulla të shtoni.