Suricata/PaKon + dualstack - 5 sec prodleva u DNS dotazu


#1

Zdravim,
vypada to ze problemy se Suricatou asi neustavaji :frowning:
Dneska jsem zjistil ze linuxovy pocitace trpi navlas stejnym problemem jako je popsany treba zde, zde nebo zde a ktery zmizi jakmile se vypne suricata.

Z myho chatrnyho pokusu o zjisteni o co jde neni problem v knot-resolveru ani clienta (ackoliv ta ficura v glibcim getaddrinfo() na A i AAAA dotaz asi umi nadelat pekny vrasky). Pokud je kresd mimo TO nebo je suricata vypla, tak to jede.

Dodani “options single-request” do /etc/resolv.conf u klientů neni reseni priciny (prestoze to funguje), to je rovnak na ohybak.

Vic popisovat nechci, resp. nemuzu, protoze v tom vazne nejsem kovany.

Muzu tak jeste maximalne pastnout:
Suricata vypla:

root@latitude:~# curl -w "@curl-format.txt" -o /dev/null -s www.nic.cz


            time_namelookup:  0,004239
               time_connect:  0,009635
            time_appconnect:  0,000000
           time_pretransfer:  0,009674
              time_redirect:  0,000000
         time_starttransfer:  0,014306
                            ----------
                 time_total:  0,014353

Suricata zapla (a jeji FW pravidla):

root@latitude:~# curl -w "@curl-format.txt" -o /dev/null -s www.nic.cz

            time_namelookup:  5,514732
               time_connect:  5,520761
            time_appconnect:  0,000000
           time_pretransfer:  5,520815
              time_redirect:  0,000000
         time_starttransfer:  5,525666
                            ----------
                 time_total:  5,525717


A pokud si pri zaply suricate vynutim IPv4 nebo IPv6:

root@latitude:~# curl -4 -w "@curl-format.txt" -o /dev/null -s www.nic.cz

            time_namelookup:  0,004203
               time_connect:  0,011191
            time_appconnect:  0,000000
           time_pretransfer:  0,011274
              time_redirect:  0,000000
         time_starttransfer:  0,015276
                            ----------
                 time_total:  0,015316

root@latitude:~# curl -6 -w "@curl-format.txt" -o /dev/null -s www.nic.cz

            time_namelookup:  0,012403
               time_connect:  0,016116
            time_appconnect:  0,000000
           time_pretransfer:  0,016214
              time_redirect:  0,000000
         time_starttransfer:  0,019944
                            ----------
                 time_total:  0,020032


#2

Dobrý den,
díky za nahlášení, chybu jsme dokázali zreprodukovat.

Naše pracovní verze je, že je to bug v Suricatě, která z neznámého důvodu zahazuje nějaké pakety které by neměla. Snažíme se najít příčinu, dáme vědět až zjistíme více.


#3

Dobrý den,

tak chybu jsme odhalili. Bohužel bug není v Suricatě (kde bychom to dokázali opravit snadněji), ale v kernelu, resp. tom mechanismu kterým Suricata získává data. DNS resolving se dneska chová tak, že se pošlou paralelně dva dotazy na A i na AAAA - což je přesně co ta volba “options single-request” může zakázat). Suricata získává data pomocí NFQUEUE (používá ho i spousta dalšího síťového softwaru) - ten má bug, že pokud přijdou 2 pakety hned po sobě na začátku spojení, tak ten druhý neprojde.
Je to “známý” problém - no, po spoustě hledání, moc dobře známé to není. Viz třeba:
https://www.spinics.net/lists/netfilter-devel/msg27248.html

Přesně proto se zasekne ten resolving, protože nepřijde odpověď na jeden z těch dotazů - ten druhý dotaz neprojde. Glibc na odpověď počká 5 vteřin a pak zkusí 2 sekvenční dotazy, které už projdou. Proto se to chová tak jak popisujete.

Nějak jsme to opravili (no, oprava je taky spíš z kategorie “narovnávák na ohýbák” :face_with_raised_eyebrow:, ono to asi dobré řešení nemá, obcházíme bug v kernelu). Oprava by měla vyjít s 3.10. Je to problém jen pro UDP nebo ICMP (TCP to nevadí), takže je řešíme nějak jinak… není to ideální, ale asi lepší než nic. Dlouhodobější řešení zkusíme probrat s vývojáři Suricaty.

Díky za ten bug report, takhle detailní popis problému fakt usnadnil hledání příčiny :+1:.


Developer update #1
#4

Zdravím,
bylo toto řešení nasazeno? Protože ty pěti sekundové prodlevy stále registruji i na 3.10.3 (Turris 1.x)


#5

Zdravím, mělo by to být vydané.
Můžete se zkusit podívat na raw tabulku iptables když suricata je spuštěna? Mělo by tam být toto:

#iptables -L -t raw
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
suricata-pakon !tcp  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
suricata-pakon !tcp  --  anywhere             anywhere            

Chain suricata-pakon (2 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             mark match 0x2/0x2
NFQUEUE    all  --  anywhere             anywhere             NFQUEUE num 10 bypass

To co není tcp by mělo lézt do suricaty právě přes tu raw tabulku, tím by se snad měl tenhle problém řešit.

Nebo ten problém trvá i s tímhle? Alespoň já ho po tomhle fixu už nepozoruju…


#6

Suricatu jsem aktuálně vypnul v rámci investigace problémů s některými servery na tunelovaném IPv6: Performance issue with IPv6 (6rd) on Turris Omnia

Nicméně na tomto obrázku je těch 5 sekund vidět:


#7

Tak jsem suricatu zase zapnul a v iptables to vypadá stejně:

root@turris ~ $ iptables -L -t raw
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
suricata-pakon !tcp  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
suricata-pakon !tcp  --  anywhere             anywhere

Chain suricata-pakon (2 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere             mark match 0x2/0x2
NFQUEUE    all  --  anywhere             anywhere             NFQUEUE num 10 bypass

A samozřejmě, že se mi ten problém aktuálně nedaří nasimulovat :smiley:

Nicméně, tyhle 2 sekundy jsou OK?

root@turris ~ $ time nslookup linux.org
Server:    127.0.0.1
Address 1: 127.0.0.1 localhost

Name:      linux.org
Address 1: 2400:cb00:2048:1::681c:111a
Address 2: 104.28.17.26
Address 3: 104.28.16.26
real    0m 2.03s
user    0m 0.00s
sys     0m 0.00s

#8

S úplně prázdnou cache a DNSSEC validací mi přijdou 2s jako OK čas.


#9

OK. Budu to dále pozorovat a jestli se problém projeví, tak se ozvu.