Laga DNS gesta í libvirt sem blokkerast af VPN eldvegg sem byggir á merkjum
VPN eldveggur sem byggir á merkjum hendir DNS gesta áður en nokkur síukeðja sér það. Ein regla með mangle forgangi merkir fyrirspurnina og svarið, án þess að opna LAN-ið þitt.
Gestir á sjálfgefnu libvirt-netinu leysa nöfn fullkomlega þar til WireGuard-tengið kemur upp, og þá stöðvast hver leit á sama stað. dnsmasq hlustar enn á 192.168.122.1:53, gesturinn hefur enn þetta vistfang sem leysir, og fyrirspurnin berst enn. Það sem breyttist er að uppstreymisfyrirspurn hýsilsins sjálfs, eða svarið við henni, er nú hent af reglu sem er metin áður en nokkur síukeðja sem þú myndir hugsa um að breyta kemur til greina. Útvegurinn er merki sem er beitt nógu snemma, á tengingu sem svarið erfir.
Gestir missa DNS um leið og göngin koma upp
Staðfestu formið áður en þú breytir nokkru. Taktu göngin niður, keyrðu dig @192.168.122.1 example.com frá gesti og sjáðu hann svara. Taktu göngin upp, endurtaktu og sjáðu tímann renna út. Þetta par af niðurstöðum útilokar brotið libvirt-net, rangt leysivístfang og dautt dnsmasq í einu skrefi.
Líttu síðan á hýsilinn. Ef dnsmasq skráir fyrirspurnina og uppstreymisáframsendingu hennar, þá kom pakkinn og bilunin er á útleið. Ef dnsmasq skráir ekkert, er fyrirspurn gestanna hent á innleið og undantekningin tilheyrir öðrum krók en þeim sem þessi grein merkir.
Hvers vegna accept-regla í síðari keðju virkjast aldrei
VPN eldveggur sem byggir á merkjum ákveður með því að skoða pakkamerkið eða tengimerkið, ekki upprunavistfangið þitt. Öllu sem berst á líkamlega tengið án vænts merkis er hafnað, og sú höfnun á sér stað í reglusafninu sem á merkisprófið. Línu ip saddr 192.168.122.0/24 accept sem bætt er við síðari keðju er einfaldlega aldrei flett upp fyrir þann pakka, sem er ástæðan fyrir því að hinar augljósu reglur virðast réttar og breyta engu.
Að víkka hana þar til eitthvað virkar er önnur gildran. Að samþykkja allt libvirt-undirnetið á inngangsleið hýsilsins opnar hverja hýsilþjónustu fyrir gestum, þótt raunverulega þörfin sé ein höfn.
Aðferðin sem gerir þrönga undantekningu mögulega er tengisporun. Þegar þú setur ct mark á pakka er gildinu vistað í conntrack-færslunni en ekki bara í pakkanum, þannig að hver pakki í þeirri tengingu ber það eftir það, þar á meðal svarið frá hýsilnum til baka til gestsins. Það er allt trikkið: merktu beiðnina einu sinni og bakleiðin er þegar merkt.
Merktu fyrirspurnina áður en VPN-taflan sér hana
Settu undantekninguna í sína eigin töflu svo síðari lesandi finni hana án þess að flokka VPN-reglurnar:
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 er neikvætt, sem setur þessa keðju fram fyrir venjulegu síukeðjurnar sem VPN-pakkinn setur upp með forgangi núll. Röð krókanna er það sem gerir regluna virka; sama regla í keðju sem raðast á eftir VPN-keðjunni er skraut.
Merkitalan sjálf er ekki flytjanleg. Taktu gildið sem uppsettu VPN-reglurnar samþykkja fyrir eigin umferð, lestu það úr lifandi reglusafninu og notaðu það. Rangt merki framleiðir reglu sem hleðst hreint, passar við hverja fyrirspurn og hleypir engu í gegn.
Haltu holunni jafnbreiðri og höfn 53
Eins og skrifað er leyfir þetta DNS frá libvirt-undirnetinu til hýsilsins um TCP eða UDP höfn 53 og ekkert annað. Það leyfir gestum ekki að ná internetinu utan ganganna, og það leyfir hýsilnum ekki að opna tengingar í átt að gestum. Ef gest þarf síðar aðra hýsilþjónustu skaltu bæta við sérstakri reglu sem nefnir þá áfangahöfn í stað þess að slaka á þessari.
Vertu heiðarlegur um það sem þú skiptir. Gestur sem kemst í leysi getur líka göngufært handahófskennd gögn í gegnum DNS-fyrirspurnir, og þessi undantekning er viljandi gap í VPN-mörkum en ekki yfirlýsing um að staðarnetið sé treyst. Að takmarka upprunann við 192.168.122.0/24 heldur gapinu í burtu frá hverju öðru staðarundirneti, og að telja fyrirspurnir gegn þeim uppruna er ódýrt ef ógnin skiptir þig máli.
Láttu það lifa endurræsingu af og sannaðu báða helmingana
Regla sem slegin er inn í skeljarprompt hverfur við næstu ræsingu, og regla sem hlaðin er eftir að VPN-tengið er þegar farið að flytja umferð tapar kapphlaupinu á fyrstu tengingu. Settu töfluna í varanlega nftables-stillingu hýsilsins, eða í einingu sem raðast fyrir VPN-þjónustuna, og athugaðu röðina í stað þess að gera ráð fyrir henni.
Sannprófun þarf þrjú aðskilin svör. Staðfestu að keðjan sé hlaðin og röðuð fyrst, staðfestu að conntrack-færslan sýni merkið í báðar áttir, og staðfestu að leit gests skili vistfangi. Staðfestu síðan hinn helminginn: venjuleg vefumferð gests að opinberum hýsli mistekst enn á meðan göngin eru niðri eða loka. Ef DNS virkar og allt annað lekur er reglan þín breiðari en sú hér að ofan.
Ef leitir mistekst enn eftir að merkið er komið fyrir skaltu standast löngunina til að víkka upprunann. Athugaðu hvert dnsmasq áframsendir, hvort leysir gestsins vísar á 192.168.122.1 eða á opinbert vistfang sem einhver sló inn, og hvort fyrirspurnin nái yfirhöfuð til hýsilsins. Merking hleypir pakkanum í gegn og engu öðru, svo slæmt uppstreymi eða brotið sýndarnet verður áfram brotið sama hversu mörgum reglum þú bætir við.