Поправка на DNS на гостин во libvirt блокиран од VPN заштитен ѕид заснован на ознаки

Гостите на стандардната libvirt мрежа ги решаваат имињата совршено сѐ додека не се подигне интерфејсот WireGuard, и тогаш секое пребарување заглавува на истото место. dnsmasq сѐ уште слуша на 192.168.122.1:53, гостинот сѐ уште ја има таа адреса како resolver, и барањето сѐ уште пристигнува. Она што се смени е тоа што сопственото горно барање на домаќинот, или одговорот на него, сега се фрла од правило што се оценува пред која било филтерска верига што би помислиле да ја уредите. Излезот е ознака применета доволно рано, на врска што одговорот ја наследува.

Гостите го губат DNS-от во моментот кога ќе се подигне тунелот

Потврдете ја формата пред да смените нешто. Спуштете го тунелот, извршете dig @192.168.122.1 example.com од гостин и гледајте како одговара. Подигнете го тунелот, повторете и гледајте како истекува. Овој пар резултати во еден чекор исклучува скршена libvirt мрежа, погрешна адреса на resolver и мртов 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

Како што е напишано, ова дозволува DNS од libvirt подмрежата до домаќинот преку TCP или UDP порта 53 и ништо друго. Тоа не им дозволува на гостите да го достигнат интернетот надвор од тунелот и не му дозволува на домаќинот да отвора врски кон гостите. Ако на гостинот подоцна му треба друга услуга на домаќинот, додајте посебно правило што ја именува таа целна порта наместо да го олабавите ова.

Бидете искрени за тоа што го менувате. Гостин што може да достигне resolver може и да тунелира произволни податоци преку DNS барања, и овој исклучок е намерна празнина во VPN границата, а не изјава дека локалната мрежа е доверлива. Ограничувањето на изворот на 192.168.122.0/24 ја држи празнината подалеку од секоја друга локална подмрежа, а броењето барања кон тој извор е ефтино ако заканата ви е важна.

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

Правило внесено во командната линија исчезнува при следното подигање, а правило вчитано откако VPN интерфејсот веќе пропушта сообраќај ја губи трката при првата врска. Ставете ја табелата во постојаната nftables конфигурација на домаќинот, или во unit подреден пред VPN услугата, и проверете го редоследот наместо да го претпоставувате.

Проверката бара три одделни одговори. Потврдете дека веригата е вчитана и подредена прва, потврдете дека записот conntrack ја покажува ознаката во двете насоки и потврдете дека пребарувањето од гостин враќа адреса. Потоа потврдете ја другата половина: обичниот веб сообраќај на гостинот кон јавен домаќин сѐ уште не успева додека тунелот е спуштен или блокира. Ако DNS работи, а сѐ друго протекува, вашето правило е пошироко од горното.

Ако пребарувањата сѐ уште не успеваат откако ознаката е на место, спротивставете се на нагонот да го проширите изворот. Проверете каде проследува dnsmasq, дали resolver-от на гостинот покажува на 192.168.122.1 или на јавна адреса што некој ја внел, и дали барањето воопшто стигнува до домаќинот. Означувањето го пропушта пакетот и ништо друго, така што лош горен тек или скршена виртуелна мрежа остануваат скршени колку и да додадете правила.