Маскарад Iptables нарушает поиск DNS

Я тестирую что-то с IP-маскарадом на локально сгенерированном трафике, но, похоже, он нарушает поиск DNS. Все остальное работает нормально – весь IP-трафик без DNS-запросов работает.

$ iptables -t mangle -A OUTPUT -j MARK --set-mark 2 $ iptables -t nat -A POSTROUTING -m mark --mark 0x2 -j MASQUERADE 

Почему это работает со всем IP-трафиком, кроме DNS-запросов?

Результаты запрошенных команд ниже:

 # ip address 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp2s0f1:  mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 54:21:c6:28:99:1f brd ff:ff:ff:ff:ff:ff 3: wlp3s0:  mtu 1500 qdisc mq state UP group default qlen 1000 link/ether c1:b2:a1:55:34:d2 brd ff:ff:ff:ff:ff:ff inet 192.168.1.108/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp3s0 valid_lft 242078sec preferred_lft 242078sec inet6 fe80::1dd6:f094:be8d:ef51/64 scope link noprefixroute valid_lft forever preferred_lft forever 

 # ip route default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600 169.254.0.0/16 dev wlp3s0 scope link metric 1000 192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.108 metric 600 

В неожиданном повороте systemd действует как DNS-сервер на 127.0.0.53.


systemctl status systemd-resolved сообщает «systemd-resolved [3315]: получен пакет с неожиданным диапазоном IP-адресов, отказывается». после включения двух команд.


Я считаю, что эта проблема может быть связана.

  • https://github.com/kubernetes/kubernetes/issues/66067
  • https://github.com/kontena/pharos-cluster/issues/482

Соответствующие части этих двух ссылок:

все запросы к 127.0.0.53:53 идут не из 127.0.0.0/8, а из интерфейса с маршрутом по умолчанию из-за маскировки, и systemd-resolved отклоняет все эти запросы с помощью

systemd-resolved [21366]: получил пакет с неожиданным диапазоном IP-адресов, отказавшись.

systemd-resolved требует дополнительных усилий для проверки адресов источника / назначения заглушки, и поэтому правило MASQUERADE нарушает эти предположения:

 if (in_addr_is_localhost(p->family, &p->sender) family, &p->destination) <= 0) { log_error("Got packet on unexpected IP range, refusing."); dns_stub_send_failure(m, s, p, DNS_RCODE_SERVFAIL, false); goto fail; } 

Для меня решение, основанное на поведении, разрешенном systemd, заключалось в реализации таких правил:

 $ iptables -t mangle -A OUTPUT ! -s 127.0.0.1 -j MARK --set-mark 2 $ iptables -t nat -A POSTROUTING -m mark --mark 0x2 -j MASQUERADE 

Я выключил systemd-resolved, но у меня все еще есть проблема с dns resolver, которую я исправляю, используя ваше решение mangle.

Представляем альтернативный ответ, потому что, возможно, мы просто хотим, чтобы iptables, а не systemd-resolved был нашим брандмауэром:

StubListener для no в /etc/systemd/resolved.conf.d/00- hostname .conf

Какое-то неудобное время, мы только что разрешили systemd, и у нас не было никакого способа остановить его запуск и убрать домен межсетевого экрана от iptables.

Какое-то время у нас была возможность остановить это, и вернуться либо просто к отложению в Google resolver, либо в opennic resolvers. Проверьте namebench, для быстрого выбора на месте.

Или мы можем иметь dnsmasq или старый добрый djbdns dnscache. Мы можем улучшить Google и / или OpenNIC или что-то еще, с помощью dnsmasq или dnscache или их комбинации. Я использую dnsmasq с namebench-ed opennic plus 127.0.0.53 dnscache, поэтому http://www.bigtube.com SERVFAIL не занимает три минуты! У меня есть dnsmasq 127.0.0.1 в / etc / resolvconf и NetworkManager. У djbns dnscache Эрвина Хоффмана действительно есть ipv6, не то, чтобы я заботился лично.