Rekebisha DNS ya mgeni wa libvirt inayozuiwa na firewall ya VPN inayotumia alama

Wageni kwenye mtandao chaguo-msingi wa libvirt hutatua majina vizuri kabisa hadi kiolesura cha WireGuard kinapotokea, na kisha kila utafutaji unakwama mahali pale pale. dnsmasq bado inasikiliza kwenye 192.168.122.1:53, mgeni bado ana anwani hiyo kama kitatuzi, na swali bado linafika. Kilichobadilika ni kwamba swali la juu la mwenyeji wenyewe, au jibu lake, sasa linatupwa na sheria inayotathminiwa kabla ya mnyororo wowote wa vichujio ambao ungeweza kudhani unahitaji kuhariri. Njia ya kutoka ni alama iliyowekwa mapema vya kutosha, kwenye muunganisho ambao jibu hulirithi.

Wageni hupoteza DNS mara tu handaki linapotokea

Thibitisha umbo kabla ya kubadilisha kitu chochote. Shusha handaki, endesha dig @192.168.122.1 example.com kutoka kwa mgeni na uone linajibu. Panda handaki, rudia, na uone linapitwa na muda. Jozi hilo la matokeo huondoa mtandao wa libvirt ulioharibika, anwani isiyo sahihi ya kitatuzi na dnsmasq iliyokufa kwa hatua moja.

Kisha angalia upande wa mwenyeji. Ikiwa dnsmasq inaandika swali na upelekaji wake wa juu, pakiti ilifika na hitilafu iko kwenye utokaji. Ikiwa dnsmasq haiandiki chochote, swali la mgeni linatupwa kwenye uingizaji na ubaguzi unapaswa kuwa kwenye ndoano tofauti na ile ambayo makala hii inaweka alama.

Kwa nini sheria ya accept kwenye mnyororo wa baadaye haiwashi kamwe

Firewall ya VPN inayotumia alama huamua kwa kutazama alama ya pakiti au alama ya muunganisho, si anwani yako ya chanzo. Kitu chochote kinachofika kwenye kiolesura halisi bila alama inayotarajiwa hukataliwa, na kukataliwa huko hutokea katika seti ya sheria inayomiliki jaribio la alama. ip saddr 192.168.122.0/24 accept mstari ulioongezwa kwenye mnyororo wowote wa baadaye hauzingatiwi kamwe kwa pakiti hiyo, ndiyo sababu sheria iliyo wazi inaonekana sahihi na haibadilishi chochote.

Kuipanua hadi kitu kifanye kazi ni mtego wa pili. Kukubali subnet yote ya libvirt kwenye njia ya uingizaji ya mwenyeji hufungua kila huduma ya mwenyeji kwa wageni, wakati hitaji halisi ni bandari moja.

Utaratibu unaowezesha ubaguzi mwembamba ni ufuatiliaji wa muunganisho. Unapoweka ct mark kwenye pakiti, thamani huhifadhiwa kwenye ingizo la conntrack na si kwenye pakiti pekee, hivyo kila pakiti ya muunganisho huo huibeba baadaye, ikiwemo jibu kutoka kwa mwenyeji kurudi kwa mgeni. Hiyo ndiyo hila yote: weka alama kwenye ombi mara moja, na njia ya kurudi imekwishawekwa alama.

Weka alama kwenye swali kabla jedwali la VPN kuliona

Weka ubaguzi kwenye jedwali lake mwenyewe ili msomaji wa baadaye aupate bila kuchanganua sheria za 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 ni hasi, jambo linaloweka mnyororo huu mbele ya minyororo ya kawaida ya vichujio ambayo kifurushi cha VPN huweka kwa kipaumbele sifuri. Mpangilio wa ndoano ndio hufanya sheria iwe na matokeo; sheria hiyo hiyo kwenye mnyororo unaopangwa baada ya mnyororo wa VPN ni mapambo tu.

Namba ya alama yenyewe haibebeki. Chukua thamani ambayo sheria zilizowekwa za VPN hukubali kwa trafiki yao wenyewe, isome kutoka seti ya sheria inayoendelea, na itumie hiyo. Alama isiyo sahihi huzalisha sheria inayopakiwa safi, inayolingana na kila swali na haikubali chochote.

Weka shimo kwa upana wa bandari 53

Kama ilivyoandikwa, hii inaruhusu DNS kutoka subnet ya libvirt hadi kwa mwenyeji kupitia TCP au UDP bandari 53 na hakuna kingine. Haiwaruhusu wageni kufikia intaneti nje ya handaki, na haimruhusu mwenyeji kufungua miunganisho kuelekea wageni. Ikiwa mgeni atahitaji huduma nyingine ya mwenyeji baadaye, ongeza sheria tofauti inayotaja bandari hiyo ya mwisho badala ya kulegeza hii.

Kuwa mwaminifu kuhusu kile unachobadilisha. Mgeni anayeweza kufikia kitatuzi anaweza pia kupitisha data yoyote kupitia maswali ya DNS, na ubaguzi huu ni pengo la kukusudia kwenye mpaka wa VPN na si tamko kwamba mtandao wa ndani unaaminika. Kuwazuia chanzo hadi 192.168.122.0/24 huweka pengo mbali na kila subnet nyingine ya ndani, na kuhesabu maswali dhidi ya chanzo hicho ni rahisi ikiwa tishio linakuhusu.

Ifanye idumu baada ya kuwasha upya na uthibitishe nusu zote mbili

Sheria iliyochapwa kwenye kidokezo cha shell hupotea kwenye uanzishaji unaofuata, na sheria inayopakiwa baada ya kiolesura cha VPN kuwa tayari kinapita trafiki hushindwa mbio kwenye muunganisho wa kwanza. Weka jedwali kwenye usanidi wa kudumu wa nftables wa mwenyeji, au kwenye kitengo kilichopangwa kabla ya huduma ya VPN, na uangalie mpangilio badala ya kuudhani.

Uthibitishaji unahitaji majibu matatu tofauti. Thibitisha kwamba mnyororo umepakiwa na umepangwa kwanza, thibitisha kwamba ingizo la conntrack linaonyesha alama katika pande zote mbili, na thibitisha kwamba utafutaji wa mgeni unarudisha anwani. Kisha thibitisha nusu nyingine: trafiki ya kawaida ya wavuti ya mgeni kuelekea mwenyeji wa umma bado inashindwa wakati handaki liko chini au linazuia. Ikiwa DNS inafanya kazi na kila kitu kingine kinavuja, sheria yako ni pana kuliko ile ya juu.

Ikiwa utafutaji bado unashindwa baada ya alama kuwekwa, zuia hamu ya kupanua chanzo. Angalia dnsmasq inaelekeza wapi, ikiwa kitatuzi cha mgeni kinaelekeza kwenye 192.168.122.1 au kwenye anwani ya umma ambayo mtu aliandika, na ikiwa swali linafika kwa mwenyeji hata kidogo. Kuweka alama hukubali pakiti na hakuna kingine, hivyo chanzo kibaya cha juu au mtandao wa mtandaoni ulioharibika hubaki umeharibika bila kujali sheria ngapi unazoongeza.