Отстраняване на блокиран DNS на гост в libvirt от VPN защитна стена на базата на маркери

VPN защитна стена на базата на маркери изхвърля DNS на госта, преди която и да е верига за филтриране да го види. Едно правило с приоритет mangle маркира заявката и отговора ѝ, без да отваря вашата LAN.

Гостите в мрежата libvirt по подразбиране разрешават имена безупречно, докато не се появи интерфейсът WireGuard, и тогава всяко търсене засича на едно и също място. dnsmasq все още слуша на 192.168.122.1:53, гостът все още използва този адрес като свой резолвер и заявката все още пристига. Промяната е, че собствената upstream заявка на хоста, или отговорът на нея, вече се изхвърля от правило, което се оценява преди всяка верига за филтриране, която бихте се сетили да редактирате. Изходът е маркер, приложен достатъчно рано, върху връзка, която отговорът наследява.

Гостите губят DNS в момента, в който тунелът се вдигне

Потвърдете формата, преди да променяте каквото и да е. Свалете тунела, изпълнете dig @192.168.122.1 example.com от гост и гледайте как отговаря. Вдигнете тунела, повторете и гледайте как изтича времето. Тази двойка резултати изключва счупена мрежа libvirt, грешен адрес на резолвер и мъртъв dnsmasq с една стъпка.

След това погледнете от страната на хоста. Ако dnsmasq записва заявката и нейното upstream препращане, пакетът е пристигнал и проблемът е на изхода. Ако dnsmasq не записва нищо, заявката на госта се изхвърля на входа и изключението принадлежи на друга кука, различна от тази, която тази статия маркира.

Защо правило за разрешаване в по-късна верига никога не се задейства

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

Както е написано, това разрешава DNS от подмрежата libvirt към хоста през TCP или UDP порт 53 и нищо друго. То не позволява на гостите да достигат интернет извън тунела и не позволява на хоста да отваря връзки към гости. Ако по-късно на гост потрябва друга услуга на хоста, добавете отделно правило, което назовава този порт на местоназначението, вместо да разхлабвате това.

Бъдете честни за това какво разменяте. Гост, който може да достигне резолвер, може също да тунелира произволни данни през DNS заявки, и това изключение е умишлена пролука във VPN границата, а не твърдение, че локалната мрежа е доверена. Ограничаването на източника до 192.168.122.0/24 държи пролуката далеч от всяка друга локална подмрежа, а броенето на заявки срещу този източник е евтино, ако заплахата има значение за вас.

Направете го да преживее рестарт и докажете двете половини

Правило, написано в шел подкана, изчезва при следващото зареждане, а правило, заредено след като интерфейсът на VPN вече пропуска трафик, губи състезанието при първата връзка. Поставете таблицата в постоянната конфигурация на nftables на хоста или в unit, подреден преди услугата VPN, и проверете подредбата, вместо да я предполагате.

Проверката изисква три отделни отговора. Потвърдете, че веригата е заредена и подредена първа, потвърдете, че записът conntrack показва маркера в двете посоки, и потвърдете, че търсене от гост връща адрес. След това потвърдете другата половина: обикновеният уеб трафик на госта към публичен хост все още се проваля, докато тунелът е свален или блокира. Ако DNS работи, а всичко останало изтича, вашето правило е по-широко от горното.

Ако търсенията все още се провалят след поставянето на маркера, устоите на желанието да разширите източника. Проверете към какво препраща dnsmasq, дали резолверът на госта сочи към 192.168.122.1 или към публичен адрес, който някой е въвел, и дали заявката изобщо достига до хоста. Маркирането допуска пакета и нищо друго, така че лош upstream или счупена виртуална мрежа остават счупени, колкото и правила да добавите.

Подобни статии