Unbound i konfiguracja iptables

[bluzman]

Witam. Postanowiłem skonfigurować DNS typu cache na zewnętrznej maszynie (VPS) używając Unbound. Sama konfiguracja usługi raczej jest poprawna. Po sprawdzeniu "unbound-checkconf" nie wypluwa żadnych błędów. Problem tkwi w iptables. Bez firewalla serwer działa, keszuje, wszystko ok, jak go włączę to przy sprawdzaniu przez "unbound-control status" pokazuje błąd z połączeniem "unbound-control[23452:0] fatal error: timeout: could not connect to server".
W sieci są poradniki do konfigurowania DNS, wiele przetestowałem i nic to nie dało. Zaczynając od najprostszych reguł "iptables -A INPUT -p tcp –dport 53 -j ACCEPT" i "iptables -A OUTPUT -p tcp –dport 53 -j ACCEPT"  kończąc na tych bardziej zaawansowanych. Zwracam się o pomoc w konfiguracji iptables, jak to ma wyglądać bo już nie mam pomysłów a jest to pierwszy DNS jaki postawiłem.

[@sunrise]

DNS generalnie używa protokołu udp

[bluzman]

Wiem, robiłem regułki dla udp i tcp oraz jedno i drugie. To co napisałem to tylko przykłady, trochę nie precyzyjnie opisałem.

[@sunrise]

22 godziny temu, bluzman napisał:

To co napisałem to tylko przykłady, trochę nie precyzyjnie opisałem.

Łatwiej byłoby gdybyś podawał całą konfigurację.

Ponieważ jest to serwer pośredniczący według mnie musisz zezwolić na ruch "w obie strony", bo jest on zarówno serwerem jak i klientem.

Powinno być to coś takiego (nie testowałem):

#zezwolenie na ruch przychodzący 
iptables -A INPUT -p all --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p all --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT

#zezwolenie na ruch wychodzący twój dns do innego dnsa
iptables -A OUTPUT -p all --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p all --sport 53 -m conntrack --ctstate ESTABLISHED -j ACCEPT

 

[bluzman]

Godzinę temu, sunrise napisał:

Łatwiej byłoby gdybyś podawał całą konfigurację.

Wstawiłem te regułki ale nie działa. btw. iptables wypluwa błąd o "--dport"

iptables -A INPUT -p all --dport 53 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables v1.8.7 (legacy): unknown option "--dport"
Try `iptables -h' or 'iptables --help' for more information.

Kiedy zmieniłem parametr "-p all" na "-p udp" i "-p tcp" i oddzielnie wstawiam, jedno po drugim to jest dobrze. Chyba ta wersja iptables nie rozumie "all"
Podaję moją konfigurację obecną po wstawieniu w/w regułek
 

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
2    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
3    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
4    ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain ctstate NEW,ESTABLISHED
5    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain ctstate NEW,ESTABLISHED
6    ACCEPT     udp  --  anywhere             anywhere             udp spt:domain ctstate ESTABLISHED
7    ACCEPT     tcp  --  anywhere             anywhere             tcp spt:domain ctstate ESTABLISHED
8    ACCEPT     udp  --  anywhere             anywhere             udp dpt:51820 ctstate NEW
9    DROP       all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
2    ACCEPT     all  --  anywhere             anywhere             ctstate NEW

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     udp  --  anywhere             anywhere             udp spt:domain ctstate ESTABLISHED
2    ACCEPT     tcp  --  anywhere             anywhere             tcp spt:domain ctstate ESTABLISHED
3    ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain ctstate NEW,ESTABLISHED
4    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain ctstate NEW,ESTABLISHED
[root@myvpn ~]# unbound-control status
[1635325847] unbound-control[29009:0] fatal error: timeout: could not connect to server

 

[@sunrise]

17 minut temu, bluzman napisał:

Chyba ta wersja iptables nie rozumie "all"

Pewnie rozumie, tylko jeżeli się używa  --dport to nie może być all bo protokół icmp nie używa portów.

Kilka pytań:

1. Czy akceptujesz cały ruch dla interfejsu lo?

2. Nie używam unbound, ale co masz w konfigu w sekcji?

remote-control:
    control-enable: "co tu masz" 
    control-interface: "co tu masz"
    control-port: "co tu masz"

 

[bluzman]

9 minut temu, sunrise napisał:

1. Czy akceptujesz cały ruch dla interfejsu lo?

Oczywiście, że nie. Głupotę walnąłem. Byłem przekonany, że jest. To trudno trochę zauważyć po komendzie "iptables -L".
Otworzyłem plik z zapisanymi regułami iptables to zobaczyłem, że nie ma ruchu lo. Musiałem nie zapisać i po restarcie firewalla zniknął.
To tak na przyszłość będzie dla potrzebujących konfiguracji dla DNS informacja. Trzeba mieć:

iptables -I INPUT 1 -i lo -j ACCEPT

Teraz jest:
 

[root@myvpn ~]# unbound-control status
version: 1.13.2
verbosity: 1
threads: 4
modules: 3 [ ipsecmod validator iterator ]
uptime: 93399 seconds
options: reuseport control
unbound (pid 23368) is running...

Dziękuję za pomoc.

[bluzman]

Skoro już jesteśmy przy temacie DNS oraz iptables to zadam pytania, żeby nie rozciągać tego na kolejne posty. Plan jest taki, że ostatecznie ta konfiguracja wyląduje na lokalnej maszynie gdzie jest słabe łącze internetowe (ewentualnie na tym VPS jeszcze podziała). Chciałbym dodać do tego kolejny forward-zone dla szyfrowania TLS na porcie 853. Rozumiem, że należałoby dodać port 853 analogicznie do iptables jak teraz ten 53?
Następne pytanie to utrzymanie tego keszu. Nie mam doświadczenia w tym. Jak zrobię restart serwera to cała zawartość zostanie skasowana, czy należałoby napisać jakiś skrypt w bashu i dodać np. do crona żeby zapisywał do pliku i później przywracać zawartość po restarcie? No i te te adresy też mają jakąś żywotność ustawioną. Czy jest sens robienia tego wszystkiego, zbierać wpisy w pamięci jeżeli to się kasuje a komputery w sieci lokalnej nie działają np. 1-2 dni?
Załączę jeszcze plik konfiguracyjny unbound żeby pokazać wszystko a głównie czasy żywotności i ilość pamięci.

unbound.conf

[@sunrise]

8 godzin temu, bluzman napisał:

Rozumiem, że należałoby dodać port 853 analogicznie do iptables jak teraz ten 53?

Generalnie tak.

 

8 godzin temu, bluzman napisał:

Jak zrobię restart serwera to cała zawartość zostanie skasowana, czy należałoby napisać jakiś skrypt w bashu i dodać np. do crona żeby zapisywał do pliku i później przywracać zawartość po restarcie?

Myślę, że to jest nie możliwe, oraz raczej pozbawione sensu. Czas trwania rekordu dns przeważnie jest krótki wynosi od kilku sekund do kilku godzin, czasy rzędu dni są raczej rzadko spotykane..

[bluzman]

Czy w unbound można 2 razy wpisać do konfiguracji opcję "interface:" ? Jedno z IP publicznym i drugie z lokalnym serwera. Mam router porypany, który nie rozumie swojego publicznego IP od sieci lokalnej. Komputery z jego lokalnej mogą do serwera się dostać do usług różnych wpisując adres wewnętrzny serwera192.168.0.X  a serwer można jedynie w funkcji DMZ umieścić, żeby wystawić go przed router.

[bluzman]

Przestawiam się z iptables na nftables i coś tu nie wychodzi do końca z blokowaniem całej polityki łańcucha input, czyli w iptables to by wyglądało tak:
 

iptables -A INPUT -j DROP

a w nftables na końcu łańcucha
 

table ip filter {
        chain input {
                type filter hook input priority filter; policy accept;
                iifname "lo" counter packets 264 bytes 863192 accept
                ct state established,related counter packets 41894 bytes 9758780 accept
                tcp dport 22 counter packets 1719 bytes 268543 accept
                udp dport 53 ct state established counter packets 0 bytes 0 accept
                tcp dport 53 ct state established counter packets 0 bytes 0 accept
                udp sport 53 ct state established counter packets 0 bytes 0 accept
                tcp sport 53 ct state established counter packets 0 bytes 0 accept
                udp dport 51820 ct state new counter packets 3 bytes 528 accept
                counter packets 1 bytes 141 drop
        }

Po dodaniu powyższej reguły niby działa, ALE Unbound nie keszuje adresów wcale. W czym problem? W tej zaporze jakoś inaczej się blokuje się wszystkie porty?
Jeszcze jeden problem jest z łańcuchami. Kiedy dodaję do wszystkiego łańcuch z "policy drop'
 

table ip filter {
        chain blokowane {
                type filter hook input priority filter; policy drop;
        }

blokuje mnie, wywala z połączenia i muszę robić reboot serwera z pulpitu VPS a co mnie dziwi jeszcze bardziej to, że przy dopisywaniu tego łańcucha nftables jest wyłączony i zastopowany, czyli:
 

systemctl disable nftables
systemctl stop nftables

 

[Fedoras]

Tak przy okazji. TCP/53 służy do transferu stref. Jeżeli tego nie używaż, to śmiało możesz wyłączyć ten protokół dla DNSa. Do zamiany nazw na ip zupełnie wystarcza UDP/53

[bluzman]

3 godziny temu, Fedoras napisał:

Tak przy okazji. TCP/53 służy do transferu stref. Jeżeli tego nie używaż, to śmiało możesz wyłączyć ten protokół dla DNSa. Do zamiany nazw na ip zupełnie wystarcza UDP/53

Zasadniczo to tak, chyba transferowania stref używa się przy serwerach autorytatywnych? Chwilowo to mam ten w/w problem z nftables i wcale nie keszuje się DNS.

[@sunrise]

W dniu 30.10.2021 o 06:29, Fedoras napisał:

Tak przy okazji. TCP/53 służy do transferu stref. Jeżeli tego nie używaż, to śmiało możesz wyłączyć ten protokół dla DNSa

Nie jest to prawdą, To czy DNS używa UDP czy TCP zależy tak naprawdę, od ilości danych przesyłanych. Kiedyś był limit dla protokołu  UDP 512B a obecnie jest 4096B. Generalnie lepiej

nie blokować ruchu TCP.

W dniu 28.10.2021 o 20:47, bluzman napisał:

Czy w unbound można 2 razy wpisać do konfiguracji opcję "interface:" ?

Według dokumentacji można.

 

W dniu 30.10.2021 o 10:28, bluzman napisał:

Chwilowo to mam ten w/w problem z nftables i wcale nie keszuje się DNS.

Może taki przykład Ci pomoże https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server

Dodatkowo zainstaluj pakiet iptables-nft wtedy będziesz miał dostępne narzędzie do konwersji iptables do nftables

Przykładowa dokumentacja dal RHEL8 ale dla Fedory jest tak samo.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/securing_networks/getting-started-with-nftables_securing-networks#converting-iptables-rules-to-nftables-rules_assembly_migrating-from-iptables-to-nftables

[bluzman]

W dniu 1.11.2021 o 13:47, sunrise napisał:

Może taki przykład Ci pomoże https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server

Dodatkowo zainstaluj pakiet iptables-nft wtedy będziesz miał dostępne narzędzie do konwersji iptables do nftables

Przykładowa dokumentacja dal RHEL8 ale dla Fedory jest tak samo.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/securing_networks/getting-started-with-nftables_securing-networks#converting-iptables-rules-to-nftables-rules_assembly_migrating-from-iptables-to-nftables

Pakiet do translacji iptables>nftables mam od początku. Już przerabiałem te linki wcześniej, ładnie opisane ale nic nie rozwiązuje. Powyższy przykład na wiki w zasadzie niczego nie wprowadza przydatnego jak dla mnie. Tu zrobili taką strukturę, że są łańcuchy dla ipv4 i dla ipv6 w tablicy inet a vmap:
 

        # Allow traffic from established and related packets, drop invalid
        ct state vmap { established : accept, related : accept, invalid : drop } 

        # Allow loopback traffic.
        iifname lo accept

        # Jump to chain according to layer 3 protocol using a verdict map
        meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 }

odsyła do nich
U mnie dokładnie to tak wygląda, tyle że ipv6 nie używane jest
 

table ip filter {
        chain input {
                type filter hook input priority filter; policy drop;
                iifname "lo" counter packets 202 bytes 658758 accept
                ct state established,related counter packets 37308 bytes 8916821 accept
                tcp dport 22 counter packets 1609 bytes 254971 accept
                udp dport 53 ct state established counter packets 0 bytes 0 accept
                tcp dport 53 ct state established counter packets 0 bytes 0 accept
                udp sport 53 ct state established counter packets 0 bytes 0 accept
                tcp sport 53 ct state established counter packets 0 bytes 0 accept
                udp dport 51820 ct state new counter packets 2 bytes 352 accept
        }

        chain output {
                type filter hook output priority filter; policy accept;
                udp sport 53 ct state established counter packets 1150 bytes 159030 accept
                tcp sport 53 ct state established counter packets 21 bytes 1220 accept
                udp dport 53 ct state established counter packets 0 bytes 0 accept
                tcp dport 53 ct state established counter packets 159 bytes 6651 accept
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
                ct state established,related counter packets 5084 bytes 2919832 accept
                iifname "wg0" oifname "wg0" ct state new counter packets 0 bytes 0 accept
        }
}
table ip nat {
        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
        }

        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                oifname "eth0" ip saddr 10.200.200.0/24 counter packets 341 bytes 36726 masquerade
        }
}