libvirt қонағының DNS-ін белгіге негізделген VPN брандмауэры бөгеп тастауын түзету

Белгіге негізделген VPN брандмауэры қонақ DNS-ін кез келген сүзгі тізбегі оны көрмей тұрып тастайды. mangle басымдығы бар бір ереже сұраныс пен оның жауабын белгілейді, LAN-ды ашпай.

Әдепкі libvirt желісіндегі қонақтар WireGuard интерфейсі көтерілгенге дейін атауларды мінсіз шешеді, содан кейін әр іздеу сол жерде тұрып қалады. dnsmasq әлі де 192.168.122.1:53 мекенжайында тыңдап тұр, қонақ әлі де сол мекенжайды шешуші ретінде пайдаланады, және сұраныс әлі де келеді. Өзгергені — хосттың өзінің жоғары ағын сұранысы немесе оған жауап енді сіз өңдеуді ойлаған кез келген сүзгі тізбегінен бұрын бағаланатын ереже арқылы тасталады. Шығудың жолы — жауап мұраға алатын қосылымда жеткілікті ерте қолданылған белгі.

Туннель көтерілген сәтте қонақтар DNS-тен айырылады

Бірдеңені өзгерту алдында пішінді растаңыз. Туннельді түсіріңіз, қонақтан dig @192.168.122.1 example.com іске қосыңыз және оның жауап беруін көріңіз. Туннельді көтеріңіз, қайталаңыз және оның уақыты бітетінін көріңіз. Нәтижелердің бұл жұбы бір қадамда бұзылған libvirt желісін, дұрыс емес шешуші мекенжайын және өлі dnsmasq-ты жоққа шығарады.

Содан кейін хост жағын қараңыз. Егер dnsmasq сұранысты және оның жоғары ағынға жіберілуін тіркесе, пакет жеткен және ақау шығу жағында. Егер dnsmasq ештеңе тіркемесе, қонақ сұранысы кіру жағында тасталады және ерекшелік осы мақала белгілейтін ілгектен басқа ілгекке жатады.

Неге кейінгі тізбектегі accept ережесі ешқашан іске қосылмайды

Белгіге негізделген VPN брандмауэры пакет белгісіне немесе қосылым белгісіне қарап шешеді, сіздің бастау мекенжайыңызға емес. Күтілетін белгісіз физикалық интерфейске келгеннің бәрі қабылданбайды, және бұл қабылдамау белгі сынағына ие ережелер жиынында болады. Кейінгі тізбекке қосылған ip saddr 192.168.122.0/24 accept жолы бұл пакет үшін ешқашан қаралмайды, сондықтан айқын ереже дұрыс көрінеді және ештеңені өзгертпейді.

Бірдеңе істегенше оны кеңейту — екінші тұзақ. Хосттың кіру жолында бүкіл libvirt ішкі желісін қабылдау қонақтарға хосттың барлық қызметін ашады, ал нақты қажеттілік — бір порт.

Тар ерекшелікті мүмкін ететін механизм — қосылымдарды бақылау. Пакетке ct mark орнатқанда, мән тек пакетте емес, conntrack жазбасында сақталады, сондықтан сол қосылымдағы әр пакет оны кейін тасиды, соның ішінде хосттан қонаққа қайтатын жауап. Бүкіл айла осында: сұранысты бір рет белгілеңіз, және қайту жолы әлдеқашан белгіленген.

VPN кестесі көрмей тұрып сұранысты белгілеңіз

Ерекшелікті өз кестесіне салыңыз, кейінгі оқырман 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 теріс, бұл осы тізбекті VPN пакеті нөлдік басымдықта орнататын қарапайым сүзгі тізбектерінің алдына қояды. Ілгектердің реті ережені тиімді етеді; VPN тізбегінен кейін сұрыпталатын тізбектегі сол ереже тек әшекей.

Белгі нөмірінің өзі тасымалданбайды. Орнатылған VPN ережелері өз трафигі үшін қабылдайтын мәнді алыңыз, оны тірі ережелер жиынынан оқыңыз және солай пайдаланыңыз. Қате белгі таза жүктелетін, әр сұранысқа сәйкес келетін және ештеңе өткізбейтін ереже жасайды.

Тесікті 53 портының енінде ұстаңыз

Жазылғандай, бұл libvirt ішкі желісінен хостқа TCP немесе UDP 53 порты арқылы DNS-ке рұқсат береді және басқа ештеңеге жоқ. Ол қонақтарға туннельден тыс интернетке шығуға мүмкіндік бермейді және хостқа қонақтарға қарай қосылымдар ашуға мүмкіндік бермейді. Егер қонаққа кейін басқа хост қызметі қажет болса, бұл ережені босатудың орнына сол баратын портты атайтын бөлек ереже қосыңыз.

Нені айырбастап жатқаныңызға адал болыңыз. Шешушіге жете алатын қонақ DNS сұраныстары арқылы кездейсоқ деректерді де туннельдей алады, және бұл ерекшелік VPN шекарасындағы әдейі жасалған саңылау, жергілікті желі сенімді деген мәлімдеме емес. Бастауды 192.168.122.0/24-мен шектеу саңылауды кез келген басқа жергілікті ішкі желіден алыс ұстайды, және қауіп сізге маңызды болса, сол бастауға қарсы сұраныстарды санау арзан.

Ол қайта жүктеуден өтсін және екі жартысын дәлелдеңіз

Shell сұранысында теру арқылы енгізілген ереже келесі жүктеуде жоғалады, ал VPN интерфейсі трафикті өткізіп жатқаннан кейін жүктелетін ереже бірінші қосылымда жарыстан ұтылады. Кестені хосттың тұрақты nftables конфигурациясына немесе VPN қызметінен бұрын реттелген unit-ке қойыңыз және ретті болжаудың орнына тексеріңіз.

Тексеру үш бөлек жауапты қажет етеді. Тізбектің жүктелгенін және бірінші реттелгенін растаңыз, conntrack жазбасы белгіні екі бағытта да көрсететінін растаңыз және қонақтың іздеуі мекенжайды қайтаратынын растаңыз. Содан кейін екінші жартысын растаңыз: қонақтың қоғамдық хостқа қарай әдеттегі веб трафигі туннель төменде немесе бөгеп тұрғанда әлі де сәтсіз аяқталады. Егер DNS жұмыс істесе, ал қалғанының бәрі ағып жатса, сіздің ережеңіз жоғарыдағыдан кеңірек.

Белгі қойылғаннан кейін де іздеу сәтсіз болса, бастауды кеңейту ниетіне қарсы тұрыңыз. dnsmasq қайда жіберетінін, қонақтың шешушісі 192.168.122.1-ге ме, әлде біреу терген қоғамдық мекенжайға ма нұсқайтынын және сұраныс хостқа жететінін тексеріңіз. Белгілеу пакетті өткізеді және басқа ештеңе жоқ, сондықтан нашар жоғары ағын немесе бұзылған виртуалды желі қанша ереже қоссаңыз да бұзылып қалады.

Қатысты мақалалар