Síťový problém - nedostupnost

Všeobecná diskuze [CZ]
1

Zdravím,

měl bych dotaz do pléna. Už delší dobu se potýkám s problémem se sítí, se kterým si nevím rady. Dělalo mi to v rámci předchozího routeru, tak i Turris Omnia, který používám nyní.

Problém se projevuje takto:

  • nenačítají se stránky vůbec (stránka není nalezena) nebo s velkou latencí

  • selhávají synchronizační služby (cloud apod.)

  • down/up je OK, linka není vytížená

Nepodařilo se mi odhalit jasnou příčinu. Testováním jsem akorát došel k závěru, že situace se zhoršuje využitím p2p služeb (pozorováno u klienta warthunder, bitcoin coru, ale někdy stačí zapnutá NAS). Vypnutím takových služeb se většinou situace zlepší (někdy ale až po restartu PC), nicméně není to vždy 100%. Vypnutí firewallu/antiviru jsem testoval také, bez pozitivní odezvy. K tomu ještě se jedná o “nárazový” problém. Poslední 3 měsíce mě to trápilo ojediněle, tento týden naopak neustále.

Vzhledem k chování mě napadl problém s DNS, ty mám nyní změněny na cznic, ale nepomohlo to (taktéž jsem testoval možnosti nastavení forwardování a DNSSEC na omnii).

Infrastruktura je IPS Centrio - router Omnia - switch 3com - zařízení (TV, PC, NTB). Pozoruji to jak na PC (Win10) tak na NTB (Win 10), tak i mobilu (Android), čímž tak trochu vylučuji switch. A nevidím důvod, proč by to muselo být u ISP (na webu jsem neobjevil, že by si někdo stěžoval na to samé).

Napadá Vás, co bych mohl ještě zkontrolovat-otestovat, třeba i v rámci služeb Omnie?

Díky

2

Zkoušel jste vypnout DNSSEC validaci? Myslím že si tu už někdo na Centrio stěžoval…

3

Ahoj,

to jsem zkoušel. Chvíli to vypadalo, že se to vyřešilo, ale následný den se problém i tak objevil. Už jsem také našel to téma ohledně Centria. Myslím, že jsem kombinaci forwardování a DNSSEC zkoušel, ale neměl jsem nastavené DNS cznic na routeru jako nyní. Zkusím tedy ještě jednou DNSSEC vypnout, ponechám forwardování a uvidíme. Ještě možná dám na radu jiného příspěvku a donastavím ještě další DNS, tj od Googlu.

Určitě se k tomu dostanu dnes večer, tak dám pak vědět, jak sjem dopadl.

4

DNS změněné na cznic znamená že se klienti ptají přímo adres z https://nic.cz/odvr?

5

No celkově, vzhledem k tomu, že to dělalo i s jiným routerem, bude hlavní příčina pravděpodobně někde u ISP…

1 Like
6

Rozumím, ale ze včerejšího testování mi zůstal v nastavení “bordel”. Nyní mám nastavené DNS cznic, google, opendns v tomto pořadí. Forwarding zapnutý, jt. DNSSEC na Omnii jsem vypnul. A testuji.

Výše jsem se vyjádřil neohrabaně, bylo by zvláštní nepodezřívat ISP a zároveň se rozhodnou nepoužívat jeho DNS :slight_smile: . Spíše nvm, v čem jiném by to případně mohlo být. Kromě toho, nejsem si ale už po té době tak jistý, v době rekonstrukce jsem v zásadě jel an VDF LTE. Kdy na tabletu jsem vytvořil hotspot. A takový warthunder klient způsoboval stejný problém na NTB - myslím, toto už jsou mlhavé paměti…

7

Tak pro info. Jak na tomto foru, tak u centria (rok 2015) jsem našel zřejmě totožné problémy. Bohužel nikdo od Centria to nechtěl tehdy řešit (chápu, jestli se ozve jeden z mnoha). Výše uvedené nastavení mi nijak nepomohlo. Problém na chvíli řeší resetování síťových nastavení, např:

  • ipconfig/flushdns
  • ipconfig /registerdns
  • ipconfig /release
  • ipconfig /renew
  • netsh winsock reset
  • reset PC

Nicméně to na základě využívání internetu vydrží den, dva. Zajímaví zjištění je, že když si zapnu VPN (typ přes prostředníka, v mém případě Avast), tak problémy postupně odezní. Sledoval jsem, jak se chová trace a odpovídá to:

== problémy ==

Tracing route to dnsres1.nic.cz [217.31.204.130]
over a maximum of 30 hops:

1 * * * Request timed out.
2 <1 ms <1 ms <1 ms 10.2.58.254
3 1 ms 1 ms 1 ms 172.21.18.1
4 1 ms 1 ms 1 ms 172.21.18.14
5 * * * Request timed out.
6 39 ms 1 ms 1 ms 172.21.17.30
7 1 ms 2 ms 1 ms 212.4.152.20
8 1 ms 1 ms 1 ms prg-sit-link.itself.cz [212.96.160.113]
9 5 ms 5 ms 4 ms brn-prg-link.itself.cz [212.96.178.220]
10 8 ms 8 ms 8 ms gw-b-01-v103.nic.cz [217.31.205.210]
11 8 ms 8 ms 8 ms dnsres1.nic.cz [217.31.204.130]

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 * * * Request timed out.
2 <1 ms <1 ms <1 ms 10.2.58.254
3 1 ms 1 ms 1 ms 172.21.18.1
4 1 ms 1 ms 1 ms 172.21.18.14
5 * * * Request timed out.
6 * * * Request timed out.
7 1 ms 1 ms 1 ms nixcz.net.google.com [91.210.16.211]
8 1 ms 1 ms 1 ms 108.170.245.49
9 1 ms 1 ms 1 ms 108.170.237.179
10 1 ms 1 ms 1 ms google-public-dns-a.google.com [8.8.8.8]

== OK stav ==

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 <1 ms <1 ms <1 ms 10.2.58.254
3 1 ms 1 ms 1 ms 172.21.18.1
4 1 ms 1 ms 1 ms 172.21.18.14
5 * * * Request timed out.
6 1 ms 1 ms 1 ms 172.21.17.14
7 1 ms 1 ms 1 ms nixcz.net.google.com [91.210.16.211]
8 1 ms 1 ms 1 ms 108.170.245.49
9 1 ms 1 ms 1 ms 108.170.237.179
10 1 ms 1 ms 1 ms google-public-dns-a.google.com [8.8.8.8]

== VPN ==

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 3 ms 4 ms 3 ms 100.100.56.1
2 15 ms 9 ms 8 ms r-2-40-234-77.ff.avast.com [77.234.40.2]
3 5 ms 6 ms 6 ms rtr-sky-01–out.avast.com [195.74.76.225]
4 7 ms 7 ms 9 ms nixcz.net.google.com [91.210.16.211]
5 5 ms 5 ms 5 ms 108.170.245.33
6 14 ms 11 ms 11 ms 108.170.232.25
7 5 ms 5 ms 6 ms google-public-dns-a.google.com [8.8.8.8]

Jde vidět, že v případě problémů mi to už hapruje na GW, 5 hop je vždy nedostupný a dost často se vytimeoutuje hop před vstupem do nixu. Takže jasně Centrio pakárna. VPN je bez problémů (samozřejmě s o něco větší latencí).

Nicméně uchlácholit se VPNkou se mi moc enchce, tak mám v plánu to na Centrio obrátit. Kromě těchto informací, napádá Vás, jestli má smysl jim ještě něco postnout?

8

Zdravím po delší době. Konečně jsem se dostal k to,mu to prodiskutovat s technickým oddělením na Centriu. Narozdíl od jiných jsem se dostal k adekvtání odpovědi.

Problem je způsoben vyčerpáním přidělených portů na jejich NATu. Celkový limit mají nastaven na 512. Samozřejmě na VPN se tento limit neuplatňuje. Zkontroloval mi provoz s tímto výsledkem:

Mohl jsem tedy konecne potvrdit, ze kdyz jsem se podival poprve (cca 14:39) mel jste navazanych 506 (vetsinou udp)
spojeni pri minimalnim provozu, coz je slusny vykon.
Vetsina z nich byla ovsem neaktivnich, takze to vypadalo na nejake proby.

O cca 5 minut pozdeji jich bylo jiz pouze 7

Jestli se jednalo o dnešní čas (ještě jsem to pro jistotu poptal) tak se v mém případě musí jednat o sabotáž ze strany chytré domácnosti. TV a BD je vypnuté, běží akorát chytré zásuvky (ty vylučuji, protože jsem je pořizoval během podzimu) a netatmo. Takže buď meteo stanice navazuje takovýto velký počet spojení a nebo mi ještě někdo visí na wifi. To si pro jistotu ověřím ještě zítra.

9

U mě netatmo žádný velký počet spojení nenavazuje, navíc je aktivní asi jednou za 5 minut a nebo na vyžádání a to jen asi vteřinu dvě.

10

Ahoj,

ano to jsem nyní také zjistil. Pro test jsem jej na chvíli odpojil a nic se nezměnilo. Takže musím pátrat dál…

11

Samotné DNS bude generovat typicky několik UDP “spojení” na každý necachovaný DNS dotaz od klienta. Jen načtení jednoho webu může vygenerovat slušný počet DNS dotazů.

EDIT: na redukci by šel použít DNS forwarding přes sdílené TCP nebo TLS spojení, ale to nebude na Omnii snadno dostupné dříve než za měsíc nebo tři – a dobrá podpora na cílových serverech asi bude trvat ještě déle.

12

Rozumím, nicméně zatím jsem nezjistil, že by vysloveně některé ze zařízení způsobovalo extrémní provoz (pro jistotu jsem na čas vypnul i wifi). Naštěstí v grafech jsem objevil možnost sledovat počet dotazů přes UDP/TCP. A skutečně v součtu jsem se bez problémů dostal nad 1000 dotazů. Bohužel v případě, že počet dotazů nárazově vyskočil, tak není lehké zjistit aktuálnéího viníka. Ani v majordomu jsem si nevšiml ničeho zvláštního.

Pak jsem vypozoroval spoustu dotazů přes Ipv6. Pro mě zbytečné. Vypnul jsem jej nedřív ve Foris rozhraní, ale v lucile zůstalo rozhraní - port stále zapnuté. Po vypnutí rozhraní a nastavení dhcp serveru v LAN na disabled se počet dotazů rapidně snížil. Ale i tak po načtení nějaké stránky pořád k těmto připojení dochází. Čímž pak dojde ke špičkovému nárůstu dotazů a vyčerpání toho limitu u Centria. V přehledech jsem si všiml, že např. můj PC má stále vedle ipv4 adresy přidělenou i ipv6. V grafu pak vidím několik zdrojových ipv6 adres.

Takže můj dotaz. Ten wanovský port se vždy po rebootu nahodí. Lze jej natrvalo vypnout, aniž bych jej mazal? A co mám ještě upravit (klidně přes ssh), aby k těmto připojením nedocházelo?

EDIT: Tak z IPV6 mi už zůstaly jen spojení odkazující na jeden cíl, např.:

IPV6 UDP [fd46:5227:8a0f::1]:58661 [ff0e::c]:1900

Jedná se o jednotky spojení, takže OK. Špičky teď už dělají jen dotazy na DNS, jak si psal. Klidně pak počet spojení vyskočí o několik set dotazů. Takže stejně ten limit skokově vyčerpám. Fakt paráda.

13

Tyhle dvě IPv6 ani nemají globální scope, takže by snad neměly být znát…

14

Dobrý den,
vidím že zmiňujete nainstalované Majordomo. V tom bych dle mého spatřoval zdroj vašich problémů s vyčerpáváním portů.
Na vině bude jedna z utilitek Majordoma (majordomo_locked_precache.sh spouštěná skrz cron v /etc/cronu.d/majordomo ), která se pokouší každou hodinu přeložit IP adresy v databázi na DNS jména a jelikož je tato operace časově omezena(zabita) tak se toto děje každou hodinu (zahlcování dotazy na DNS překlad).

Odkáži vás na popis fungování Majordomo https://forum.test.turris.cz/t/majordomo-nesbira-data/3810/4 a témata řešení tohoto chování https://forum.test.turris.cz/t/how-to-make-dns-resolv-working-in-majordomo/1169/36

15

vcunat

Ano vypadá to tak a i kdyby, jedná se skutečně o min provoz.

ajb007

Díky. Dobrý postřeh. Lookup jsem vypnul, stejně jako v uvedeném vlákně se mi stejně adresy nepřekládaly a nepotřebuji to. Uvidíme, co to udělá s počtem dotazů.

16

Tak nic moc. Majordomo jsem musel odinstalovat, vypnutí lookupu nemělo vliv. Jak si sám psal v uvedeném příspěvku, tak to adresy stejně nadále překládalo. Poté byla situace znatelně lepší. Bohužel i tak není pro mou síť problém počet přidělených portů vyčerpat. Většinou je to skoková záležitost, kdy se připojuje další zařízení a nebo jednoduše v případě, že jsem sám přes prohlížeč aktivní. Docela mě překvapuje, že se s tím nesetkají i ostatní uživatelé. Chápal bych to v té minulosti kvůli torentům, ale to u mě už dávno pasé…

17

Tak já jsem svůj problém vyřešil veřejnou adresou (stejně jsem ji plánoval, abych mohl využít další možnosti routeru). Celkově tak pokleslo i zatížení routeru požadavky. Zřejmě se jich spoustu opakovalo v reakci na blokaci ze strany NATu poskytovatele.