Pull to refresh

Comments 15

А вот dnsmasq он мне так и не заменил... А задача была простейшая: запрос с рабочим днс-суффиксом отправить через впн к рабочему же днс-серверу, а все остальное - мимо впн, к стандартному. А если уж вспомнить про кеширование днс-запросов... Впрочем, настраивал я это года три назад в минте, возможно systemd уже научился так.

Хех, я кстати пытался использовать systemd в качестве DHCP-сервера... Действительно, очень уж он урезанный. Так что я остановился на нём именно в качестве DHCP-клиента, используя тот же dnsmasq там где нужен DHCP и/или DNS сервер. Хотя, честно, он тоже странно себя ведёт местами, но как-то непереусложнённой альтернативы не особо нет. Иногда хочется написать свой, но где столько времени и сил-то найти =) Худо бедно его хватает, с оговорками.

В последних версиях networkd DHCP сервер сильно раздался в фичах, даже появилась возможность статической конфигурации по MAC-адресам, чего нам не хватало и из-за чего мы сидели на dnsmasq. Теперь вот подумываю выбросить dnsmasq и обходиться одним networkd.

Странно. У меня с этим проблем не было. Достаточно добавить Domains=~. в секцию [Network].

В результате resolvctl у меня показывает вот это:

Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: uplink
Fallback DNS Servers: 1.1.1.1 9.9.9.10 8.8.8.8 2606:4700:4700::1111 2620:fe::10 2001:4860:4860::8888

Link 3 (wlo1)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.254
       DNS Servers: 192.168.0.254
        DNS Domain: ~.

Link 9 (tun0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: xxx.xxx.xxx.xxx 
       DNS Servers: xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy
        DNS Domain: zone1.my-corp.com zone2.my-coprp.com my-corp.com

И все что из my-corp.com резолвится через tun0, в то время как другие домены - через wlo1

Кстати, у меня с systemd-resolved есть одна странная проблема, при использовании его совместно с docker... После ребута хоста, видимо, DNS не успевает по DHCP подтянуть сервера, и после запуска контейнеров с автозапуском - у них нет DNS-а.

Приходится либо контейнеры перезапускать (после чего они таки подхватывают DNS), либо весь докер демон.

Я от отчаяния уже написал вот такой drop-in для докера, но он не помог...

[Unit]
Requires=systemd-resolved.service
After=systemd-resolved.service

[Service]
ExecStartPre=-/usr/bin/sleep 10

Что я делаю не так? Есть возможность как-то решить это раз и навсегда?

Я бы попробовал поставить After=systemd-networkd-wait-online.service

Спасибо, при очередном обслуживании сервиса опробую =)

Ох, проблема оказалась вообще в другом. Я в своё время заменил resolvconf на systemd-resolved но не менял саму конфигурацию через debian-овские интерфейсные файлы на systemd-networkd. Как оказалось, systemd-resolved не особо хорошо дружит с дебиановским дефолтным нетворкингом, потому что тот пишет DNS-сервера напрямую в /etc/resolv.conf, что и вызывает полный бардак... Докером подхватывался какой-то промежуточный resolv.conf, который, само собой, не работал. Изменив всё на systemd-networkd всё взлетело.

Ааа, ну да, там могут быть самые разные приколы. Я поэтому стараюсь использовать полный стек от systemd, включая systemd-tmpfiles чтобы быть уверенным что /etc/resolv.conf указывает на правильный resolv.conf сгенерированный systemd-resolved.

Я в отличии от комментария выше просто забил на проблему (лень было перенастраивать каждый раз), спасибо вам за это решение, оно очень мне помогло. Настроил через NetworkManager. Только есть проблема, что пришлось вручную домен поиска прописывать ведь ~. мешает почему-то использовать и вписанное значение и значение из DHCP.

Возможно, проблема была в настройке кеширования... То ли ошибочные ресолвы я не смог настроить не кешировать, то ли ещё что-то... Не помню за давностью. Попробую снова на днях - может и завезли уже все нужное. Так-то юниты действительно удобны.

Спасибо за постановку проблемы и решение!

Но в Debian 11 теперь nftables обязательно, или нет? Я настроил пока у себя на новом сервере правила без VPN, но на будущее хочется знать, куда смотреть :)

То есть, остаёмся с iptables через "прокладки, как (возможно) сейчас, или всё же всё переводим на nft?

Ну, на самом деле вроде iptables-compat никто пока убирать не собирается. Но вообще есть некоторые вещи, которые nft пока всё ещё не может, так что даже iptables-legacy всё ещё жив.

Я бы пока не беспокоился на эту тему, но думаю при желании это решение можно и на nft переписать без особых проблем.

Даже сейчас, nft list ruleset вполне выдаёт валидную конфигурацию:

table ip mangle {
        chain PREROUTING {
                type filter hook prerouting priority mangle; policy accept;
                counter packets 1268889 bytes 206776017 meta mark set ct mark
                mark 0x2 counter packets 1225490 bytes 191328440 accept
                iifname "eth0" counter packets 329 bytes 15363 meta mark set 0x2
                counter packets 43399 bytes 15447577 ct mark set mark
        }

        chain INPUT {
                type filter hook input priority mangle; policy accept;
        }

        chain FORWARD {
                type filter hook forward priority mangle; policy accept;
        }

        chain OUTPUT {
                type route hook output priority mangle; policy accept;
                counter packets 1133182 bytes 168075102 meta mark set ct mark
                mark 0x2 counter packets 1085533 bytes 161248520 accept
                oifname "eth0" counter packets 6964 bytes 2185183 meta mark set 0x2
                counter packets 47649 bytes 6826582 ct mark set mark
        }

        chain POSTROUTING {
                type filter hook postrouting priority mangle; policy accept;
        }
}

Этот дамп скорее всего "перегружен" и его можно упростить (статистику количества пакетов/байтов убрать), но я думаю суть ясна примерно =)

Мне кажется проблема немного надуманная. Дефолтным шлюзом VPN обычно выбирают на клиентских машинах и следовательно вопрос потери удаленного доступа не стоит. На серверах ты обычно совершенно точно знаешь какие конкретно подсети заворачивать в VPN.

Странно, что не сказано, что статья описывает в общем-то обычный source based routing (SBR), приходится продираться через описание. Если кому непонятно, что вообще происходит: раз, два.

Only those users with full accounts are able to leave comments. Log in, please.