Mae gwesteion ar y rhwydwaith libvirt diofyn yn datrys enwau'n berffaith nes bod y rhyngwyneb WireGuard yn codi, ac yna mae pob chwiliad yn stopio yn yr un man. Mae dnsmasq yn dal i wrando ar 192.168.122.1:53, mae gan y gwestai'r cyfeiriad hwnnw fel ei ddatryswr o hyd, ac mae'r cwestiwn yn dal i gyrraedd. Yr hyn sydd wedi newid yw bod cwestiwn upstream yr host ei hun, neu'r ateb iddo, bellach yn cael ei ollwng gan reol a werthir cyn unrhyw gadwyn hidlo y byddech yn meddwl ei golygu. Y ffordd allan yw marc a gymhwysir yn ddigon cynnar, ar gysylltiad y mae'r ateb yn ei etifeddu.

Mae gwesteion yn colli DNS yr eiliad y mae'r twnnel yn codi

Cadarnhewch y siâp cyn newid unrhyw beth. Gollyngwch y twnnel, rhedwch dig @192.168.122.1 example.com o westai, a gwyliwch ef yn ateb. Codwch y twnnel, ailadroddwch, a gwyliwch ef yn amseru allan. Mae'r pâr hwnnw o ganlyniadau yn diystyru rhwydwaith libvirt wedi torri, cyfeiriad datryswr anghywir, a dnsmasq marw mewn un cam.

Yna edrychwch ar ochr yr host. Os yw dnsmasq yn cofnodi'r cwestiwn a'i anfon upstream, cyrhaeddodd y pecyn ac mae'r methiant ar yr allanfa. Os nad yw dnsmasq yn cofnodi dim, mae cwestiwn y gwestai'n cael ei ollwng ar y fynedfa ac mae'r eithriad yn perthyn i fachyn gwahanol i'r un y mae'r erthygl hon yn ei farcio.

Pam nad yw rheol accept mewn cadwyn hwyrach byth yn tanio

Mae wal dân VPN sy'n seiliedig ar farciau yn penderfynu drwy edrych ar farc y pecyn neu farc y cysylltiad, nid ar eich cyfeiriad ffynhonnell. Mae unrhyw beth sy'n cyrraedd y rhyngwyneb corfforol heb y marc a ddisgwylir yn cael ei wrthod, ac mae'r gwrthod hwnnw'n digwydd yn y set rheolau sy'n berchen ar y prawf marc. Nid yw llinell ip saddr 192.168.122.0/24 accept a ychwanegir at ryw gadwyn hwyrach byth yn cael ei hystyried ar gyfer y pecyn hwnnw, a dyna pam mae'r rheol amlwg yn edrych yn gywir ac yn newid dim.

Ehangu nes bod rhywbeth yn gweithio yw'r ail fagl. Mae derbyn y is-rwydwaith libvirt gyfan yn llwybr mewnbwn yr host yn agor pob gwasanaeth host i westeion, pan mai'r angen gwirioneddol yw un porth.

Y mecanwaith sy'n gwneud eithriad cul yn bosibl yw olrhain cysylltiadau. Pan osodwch ct mark ar becyn, mae'r gwerth yn cael ei storio ar gofnod conntrack yn hytrach nag ar y pecyn yn unig, felly mae pob pecyn yn y cysylltiad hwnnw'n ei gario wedyn, gan gynnwys yr ateb o'r host yn ôl at y gwestai. Dyna'r tric cyfan: marciwch y cais unwaith, ac mae'r llwybr dychwelyd eisoes wedi'i farcio.

Marciwch y cwestiwn cyn i'r tabl VPN ei weld

Rhowch yr eithriad yn ei dabl ei hun fel y gall darllenydd hwyrach ddod o hyd iddo heb ddadansoddi rheolau 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 yn negyddol, sy'n gosod y gadwyn hon o flaen y cadwyni hidlo arferol y mae'r pecyn VPN yn eu gosod ar flaenoriaeth sero. Trefn y bachau sy'n gwneud y rheol yn effeithiol; mae'r un rheol mewn cadwyn sy'n didoli ar ôl cadwyn VPN yn addurn.

Nid yw'r rhif marc ei hun yn gludadwy. Cymerwch y gwerth y mae'r rheolau VPN sydd wedi'u gosod yn ei dderbyn ar gyfer eu traffig eu hunain, ei ddarllen o'r set rheolau fyw, a'i ddefnyddio. Mae marc anghywir yn cynhyrchu rheol sy'n llwytho'n lân, yn cyfateb i bob cwestiwn, ac yn derbyn dim.

Cadwch y twll yn lled porth 53

Fel y'i hysgrifennwyd, mae hyn yn caniatáu DNS o is-rwydwaith libvirt i'r host dros TCP neu UDP porth 53 a dim arall. Nid yw'n gadael i westeion gyrraedd y rhyngrwyd y tu allan i'r twnnel, ac nid yw'n gadael i'r host agor cysylltiadau tuag at westeion. Os bydd gwestai angen gwasanaeth host arall yn hwyrach, ychwanegwch reol ar wahân sy'n enwi'r porth cyrchfan hwnnw yn lle llacio hon.

Byddwch yn onest ynghylch yr hyn rydych yn ei fasnachu. Gall gwestai sy'n gallu cyrraedd datryswr hefyd dwnelu data mympwyol drwy gwestiynau DNS, ac mae'r eithriad hwn yn fwlch bwriadol yn ffin y VPN yn hytrach na datganiad bod y rhwydwaith lleol yn cael ei ymddiried ynddo. Mae cyfyngu'r ffynhonnell i 192.168.122.0/24 yn cadw'r bwlch oddi wrth bob is-rwydwaith lleol arall, ac mae cyfrif cwestiynau yn erbyn y ffynhonnell honno'n rhad os yw'r bygythiad yn bwysig i chi.

Gwnewch iddo oroesi ailgychwyn a phrofwch y ddau hanner

Mae rheol a deipir mewn prydlon powlen yn diflannu ar y cychwyn nesaf, ac mae rheol a lwythir ar ôl i'r rhyngwyneb VPN fod eisoes yn pasio traffig yn colli'r ras ar y cysylltiad cyntaf. Rhowch y tabl yng nghyfluniad nftables parhaus yr host, neu mewn unit a drefnwyd cyn y gwasanaeth VPN, a gwiriwch y drefn yn lle ei thybio.

Mae angen tri ateb ar wahân ar y gwirio. Cadarnhewch fod y gadwyn wedi'i llwytho ac wedi'i threfnu'n gyntaf, cadarnhewch fod cofnod conntrack yn dangos y marc yn y ddau gyfeiriad, a chadarnhewch fod chwiliad gwestai yn dychwelyd cyfeiriad. Yna cadarnhewch y hanner arall: mae traffig gwe arferol y gwestai i host cyhoeddus yn dal i fethu tra bo'r twnnel i lawr neu'n rhwystro. Os yw DNS yn gweithio ac mae popeth arall yn gollwng, mae eich rheol yn lletach na'r un uchod.

Os yw chwiliadau'n dal i fethu ar ôl i'r marc fod yn ei le, gwrthwynebwch yr ysfa i ehangu'r ffynhonnell. Gwiriwch beth mae dnsmasq yn ei anfon ymlaen ato, a yw datryswr y gwestai'n pwyntio at 192.168.122.1 neu at gyfeiriad cyhoeddus y gwnaeth rhywun ei deipio, ac a yw'r cwestiwn yn cyrraedd yr host o gwbl. Mae marcio'n derbyn y pecyn a dim byd arall, felly mae upstream gwael neu rwydwaith rhithwir wedi torri'n aros wedi torri ni waeth faint o reolau a ychwanegwch.

Erthyglau cysylltiedig