Ubuntu 22.04 LTS socket (?) probléma - kimenő kapcsolatok pár percig hibára futnak

Ubuntu Linux

Sziasztok!

Adott egy Ubuntu 22.04 LTS alapú szerver, DELL brand szerveren, melyen a gyártó szerint is támogatott ez az operációs rendszer. A szerveren web- és e-mail kiszolgálás is fut többek között (Apache, MariaDB, Dovecot, Postfix, Bind). A szerveren időnként előjön az a probléma, hogy nem tud kifelé kapcsolódni. Először a Postfix naplóban vettem észre ilyen és hasonló bejegyzéseket:

user@domain.tld - connect to mail.domain.tlx[ip-v4-address-here]:25: Connection refused

Pár (3-5) perc múlva a hiba magától megszűnik. Miközben a hiba fennáll, akkor semmihez sem lehet kifelé kapcsolódni. Próbáltam telnet-el tetszőleges portra (biztosan elérhető szerveren 25-ös, 443-as, stb.) kinyúlni, semmi, connection refused. Fut a szerveren egy Python szkript, ami monitorozás céljából adatokat gyűjt és ezeket HTTPS-en elküldni egy másik szerverre. Ez a szkript a következő hibákat naplózza pár percig, aztán helyreáll ez is:

[Errno 99] Cannot assign requested address

A szerver hardveres tűzfal mögött van, mellyel kettő, D-LINK márkájú, stack-elt switch-en keresztül kommunikál (LACP bond), azaz a szerver nincs kint publikus IP-n, csak a szükséges portok vannak forward-olva neki, és csak adott protokollokon mehet kifelé is.

A hálózati beállítások (netplan):

network:
  bonds:
    bond0:
      interfaces:
      - eno8303
      - eno8403
      parameters:
        lacp-rate: slow
        mode: 802.3ad
        transmit-hash-policy: layer2
  ethernets:
    eno8303: {}
    eno8403: {}
  version: 2
  vlans:
    bond0.15:
      addresses:
      - a.belso.ip.cim
      id: 15
      link: bond0
      routes:
      - to: default
        via: a.gateway.ip.cime
      link-local: [ ]
      dhcp6: no

Egyéb beállítások (IPv6 tiltás (sysctl)):

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.bond0.disable_ipv6 = 1
net.ipv6.conf.bond0/15.disable_ipv6 = 1
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.bond0.autoconf = 0
net.ipv6.conf.bond0/15.autoconf = 0

Ami érdekesebbé teszi a képet az az, hogy kívülről minden elérhető, a forward-olt portokon a szerver tökéletesen válaszol, fogadja a leveleket, elérhető a webmail, minden aminek mennie kell. A szerver terhelése kb. nulla, erősen túlméretezett a hardver. A legnagyobb gond az, hogy amikor megakad, akkor a DNS feloldás sem működik (helyben fut a Bind), és például egy beérkező levél feladó IP címének reverse DNS lekérdezése ilyenkor nem sikerül, a Postfix meg emiatt szépen eldobja a levelet. Puff neki...

A sztenderd naplókban (syslog, stb). semmi. Tanácstalan vagyok. Mi okozhat ilyen problémát?

Ui.: Boldog karácsonyt minden kedves kollégának!

  • 1171 megtekintés

( fairlane | 2023. 12. 25., h – 20:59 )

Mi van megadva DNS-nek, ha nem titok?
Esetleg egy BIND konfig is jól jöhet.

...úgyis jönnek...

A posztban nem volt egyértelmű számomra, most már igen.
Amikor a leállás történik, akkor egy időben kéne nézni a hoston tpcdumppal a ki- és bemenő csomagokat adott címre + a tűzfalon is a logokat.
Abból kiderülhet, hogy hol akad el.

Esetleg még a bondingot szétszedheted, de előtte azért mérnék egyet.

 

Szerk.: Most látom, hogy nem minden van a ti ellenőrzésetek alatt. Így azért egy picit nehezebb, de nem lehetetlen.

...úgyis jönnek...

DNS-nek a 127.0.0.1 van megadva, azon csücsül a Bind, rekurzív resolver-ként. Ezzel nincs is gond, mindent szuperül felold. Amikor "lehal" a kifelé kommunikáció, akkor nem csak a Bind nem tud kifelé kommunikálni, hanem semmi, egy sima telnet sem, egy wget sem, semmi. Természetesen ilyenkor nem DNS-re hivatkozom teszteléskor, hanem IP címre.

( zsirmo v | 2023. 12. 25., h – 21:02 )

mi az a hardveres tűzfal? ez inkább valami rate limit problémának néz ki

Ezt nem tudom pontosan, a tűzfalat nem mi kezeljük, hanem egy külsős rendszergazda. Korábban már kérdeztem tőle van-e bármilyen limitálás, elmondása szerint nincs (pontosabban annyi van hogy kifelé csak adott protokollokon kommunikálhatunk, ilyenek például a HTTP, HTTPS, DNS, SMTP, NTP, csak ami feltétlenül szükséges). Én is hasonlót sejtek, mert példának okáért a biztonsági mentések is "cakkosan" mennek kifelé, értsd: egyszer megindul emberi sebességgel, majd leesik nullára. Több tíz másodperc szünet, megint megindul, és így tovább. Már feljebb kellett vennem a retry count értékeket az S3 kliensben hogy ne fusson hibára...

Új infó: eddig ezt nem vettem észre: a két bond member interfész egyikénél ezt látom:

eno8403: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP>

A társa működik és ezek szerint csak azon van kapcsolatunk most:

eno8303: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>

Attól függetlenül hogy a bond "féllábú", még mennie kellene, nem?

Parancsolj:

Ethernet Channel Bonding Driver: v5.15.0-91-generic

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

802.3ad info
LACP active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable

Slave Interface: eno8403
MII Status: down
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: IFACE:MAC:ADDRES:WAS:HERE:1d
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: churned
Partner Churn State: churned
Actor Churned Count: 1
Partner Churned Count: 1

Slave Interface: eno8303
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: IFACE:MAC:ADDRES:WAS:HERE:1c
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0

Helyreállítottuk a bond-ot. A probléma prózaian agyszerű volt: nem volt bedugva az egyik kábel. ;) Így már kerek maga a bond, de a problémák nem hárultak el, ugyanúgy folytatódik a mizéria. Sokszor 5 percig kifelé semmi nem megy. :(

Ethernet Channel Bonding Driver: v5.15.0-91-generic

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

802.3ad info
LACP active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable

Slave Interface: eno8403
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: IFACE:MAC:ADDRES:WAS:HERE:1d
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 1
Partner Churned Count: 1

Slave Interface: eno8303
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: IFACE:MAC:ADDRES:WAS:HERE:1c
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0

Szerintem itt lesz a hiba oka elhantolva: "A szerver hardveres tűzfal mögött van".

Egyszerűen betelik a NAT tábla. Viszont ennek valami nyomának kellene lennie annak a tűzfalnak a logjában.
Ezért is magyarázat, hogy a portforwardolt szolgáltatások működnek, csak már kifelé nem tud új kapcsolatot nyitni a gép.

( ricpet | 2023. 12. 25., h – 22:47 )

Próbáltam telnet-el tetszőleges portra (biztosan elérhető szerveren 25-ös, 443-as, stb.)

Próbáld ki ugyanezt ugyanabban az időben egy olyan cél szerverre is, ami ugyanazon a subnet-en van, mint a problémás szerver. Így kiderülhet, hogy a hardveres tűzfal okoz-e gondot, vagy már lokálisan sem tud kifelé nyitni kapcsolatot a problémás szervered.

( NevemTeve | 2023. 12. 26., k – 06:58 )

Szerkesztve: 2023. 12. 26., k – 07:00

Az errno=99 (EADDRNOTAVAIL) azt jelentheti a bind(2) válaszában, hogy az a lokális IP, amit használni akar, az nincs. Mondhatjuk úgy is, hogy `interface is down`. Ugye volt egy olyan rész, hogy `NO_CARRIER`, vagyis Ethernet szintű gond van. Vagy ez önmagában 'down-olja' az interface-t, vagy valamilyen segítőszoftver időzített futása teszi ezt. (Most nem mondom ki a medve nevét, de van egy tippem.)

Megnéztem a syslog-ban, nem megy DOWN-ra az interfész. A bond még gyanús nekem, bár nem értem miért csinálhat ilyet, akkor is ha most "féllábú". A szerver IP címe a bond-on belüli VLAN-ban van, és az interfész ugye él, mert amúgy kívülről sem lehetne kapcsolódni. Mindösszesen kettő aktív IP címe van: egy a loopback 127.0.0.1 és egy magának a bond-olt interfészen belül ami a külső kapcsolatokat biztosítja a tűzfal felé / felől. Igazából a bond-ot leszámítva ez egy "full alap" telepítés. A bond is "csak" azért van hogy ha már ott van a két interfész, a stack-elt switch-ek, akkor használjuk már ki... Sebesség, redundancia.

Sejtettem hogy ez lesz a válasz, tegyük fel tényleg a systemd környékén van valami ami szórakozik velünk. Na de miért nem jön ki három másik szerveren, ugyanilyen szoftverek mellett (na jó, azokon más a hardver és nincs bond). És ha mondjuk tényleg ez rontja el a hálózatot, akkor hogyan lehet az hogy kívülről amúgy minden tökéletesen elérhető, nem szakadnak meg a kapcsolatok, stb?

( Friczy v | 2023. 12. 26., k – 10:04 )

A connection refused alapján a server tud kifelé kapcsolódni, csak valami előtte elutasítja. Ha nem tudna kapcsolódni, akkor timeout lenne az üzenet tartalma, a refused esetében jellemzően egy TCP RST válaszcsomag érkezett. Azt nyilván nem lehet tudni, hogy ki/mi küldte, de a server előtti tűzfal az első számú 'gyanúsított'.

Köszönöm, már többen erre gyanakodtatok (velem és kollégáimmal együtt). Rendbe rakatom a féllábú bond-ot a switch-eken (azokat sem mi kezeljük), és alaposan átnézetem a tűzfalat. Ha bármi más ötlet lenne, ne tartsátok magatokban. :))

( lcseh | 2023. 12. 28., cs – 10:21 )

Én vetnék egy pillantást a session number beállításra a tűzfalon. Nekem ugyanezt a hibát az oldotta meg, hogy nagyobbra kellett venni.

Kedves fórumozók, kedves lcseh! Végül kiderült, itt volt a kutyus elásva. Akkor vázolom a helyzetet mert szeretnék még segítséget kérni: először is kb. két hete rendbe lett rakva a bond, jelenleg layer2+3 beállítással muzsikál. Nincs szakadás vagy ilyesmi, és mindkét "lábán" van adatforgalom. Bekerült egy másik gép ugyanabba a subnet-be, és írtam pár teszt szkriptet is. Sok adatot gyűjtöttünk, próbáltunk az adatokban rendszert keresni, összevetettük a naplókkal, szerintem nagyon alaposak voltunk, kizártuk a szerver hibáját.

- Mint kiderült, a "[Errno 99] Cannot assign requested address" megtévesztő volt. A kód ami ezt produkálta át lett nézve, és kiderült hogy a 99-es állapotkód nem csak ezt jelentheti, így nem szabadott volna hinni neki. Az igazi ok a "connection refused" volt.

- Meggyőződtem róla, hogy alig van ESTABLISHED és TIME_WAIT állapotban kapcsolat, csúcsidőben is 200 alatt van az összes, ebben benne vannak a helyi interfészek közötti kapcsolatok is (pl. Docker). Kifelé irányba többnyire 100 alatt vannak.

- Van ez a szuper strace nevű eszköz, ezzel naplóztam hosszú ideig percenként WAN felé kimenő, és az egy subnet-en belüli géppel is a kapcsolatot. Kiderült, hogy a belső hálózaton semmi de semmi gond nincs, soha nem szakad meg. A probléma csak a kimenő kapcsolatok esetében áll fenn, hol egy, hol kettő, hol öt vagy tíz percre "connection refused" jön. Aztán "magától" helyreáll.

Ma kibogoztuk, a tűzfalon elértünk egy ilyet: "maximum sessions per host (1000) was exceeded"

Megnézte a kolléga azt is milyen csomagok utaznak: a legtöbb DNS lekérdezés. Nem csoda, ez egy e-mail szerver, a beérkező levelek meg vannak nézve mindenféle blacklist-eken, stb. Használjuk a SpamHaus DQ-t is, ez ilyesmi DNS lekérdezéseket futtat:

- apps.microsoft.com.a-mi-acces-keyunk.dbl.dq.spamhaus.net/A
- a.felado.ipv4.cime.a-mi-acces-keyunk.zen.dq.spamhaus.net/A

A válaszok ezekre: "ncache nxdomain", azaz ha jól értem nem megy cache-be az eredmény. Így minden egyes beérkező levélkor kimegy újra. Jól gondolom hogy ilyenkor ráadásul még be is járja a "fát", kezdve a .net-től szépen sorban, azaz valójában egy rakás DNS lekérdezés kimegy egy IP / hoszt esetén is. Ez azért meglehetősen morbid, hamar összejön sok száz nyitott kapcsolat.

A kérdéseim:

- Normális az, hogy több ezer nyitott kapcsolat keletkezik a tűzfalon egy közepes forgalmú (kb. 100 user) e-mail szerver esetén?

- Az UDP ugye stateless, de a tűzfalnak őriznie kell a forrás IP / forrás port / cél IP / cél port négyest, érthető okokból.

- Mit javasoltok, mekkora legyen ez a limit? Most sokszorosára lett emelve, de bántja a szemem. :(

Minden eddigi és jövőbeni segítséget nagyon köszönök!

Megszokásból. A szerveren egy teljes értékű DNS szolgáltatás fut, kiszolgálja saját magát, nem függ mástól. Én ezt így üzembiztosabbnak gondolom, mint olyan eszközre bízni a feladatot ami nincs a kezelésünk alatt. A másik gond az, hogy muszáj cache-elős DNS szervernek lennie saját IP címmel, nem lehet olyat hogy a kéréseket továbbítod valami publikus resolver-nek, mert akkor elbúcsúzhatsz bizonyos DNSBL-ek használatától. Utóbbiak megkövetelik hogy saját cache-elő névszervereket használj és beregisztráld az IP címüket hozzájuk.

( azbest | 2023. 12. 28., cs – 21:12 )

Szerkesztve: 2023. 12. 28., cs – 21:13

Tudom triviális de nem lehet különböző szinteken a rendszereitekből pinget próbálni mondjuk 1.1.1.1 vagy 8.8.8.8 címre? Nem a netszolgáltató szarakodik?
Vagy akár a különböző belső eszközeitek közt pinget próbálni, hogy melyik kettő közt nem él a kapcsolat valamikor.

Például a digi hetek óra rendszeresen berohad nálunk, fél percekre szakadozik a kapcsolat rajtuk át hetente 2-3 nap munkaidő közepén órákig.

Honlap felállítunk egy cselekvési tervet erre. Több pontot fogunk tesztelni, hosszú órákon keresztül:

- Beteszünk egy ideiglenes eszközt ugyanabba a subnet-be, és ping-elünk oda-vissza folyamatosan.
- Jelenleg a tűzfal nem válaszol ping-re, ezt beállíttatom és azt is folyamatosan ping-elni fogjuk.
- Ugyanígy, kifelé is ping-elni fogunk legalább egy általános hosztot.

Aztán megnézzük a naplókat.

Az internetszolgáltató azért nem gyanús, mert több IP címünk van egymás mellett, ugyanazon a fizikai linken, és nincs probléma a többin. Ugyanígy, befelé minden kapcsolat működik, élő. Ha szakadozna a kapcsolat, azok sem működnének.

Ping mellé egy mtr-t is javasolnék futtatni, az nagyon jól megmutatja, ha gond van, hol kell keresgélni.

 

( azbest | 2023. 12. 28., cs – 21:12 ) Permalink

A DIGI mostanában egészen furcsán viselkedik. Az örömteli, hogy a külföldet végre nem az RCS-RDS-sel oldják meg, hanem Telia-val és RETN-nel, de rendszeres, hogy megáll 1--1 másodpercekre a forgalom. Netrádió mindig szól, ott azonnal hallom, ha valami zűr van. Persze lehet a rádió oldalán is, de több rádióval is jelentkezik a gond, meg ha fut mtr, akkor az is mutatja, hogy néha megugrik a loss... A Prohardver fórum tele van szegedi panaszokkal, de én úgy látom, hogy a probléma többé-kevésbé máshol is megjelenik.

TheAdam

( gabrielakos v | 2023. 12. 28., cs – 23:18 )

user@domain.tld - connect to mail.domain.tlx[ip-v4-address-here]:25: Connection refused

99.9% router / tűzfal probléma.

A connection refused az azt jelenti valaki "lelőtte/elutasította" a kapcsolatot, tehát félig "létrejött"
Routing (default gw) biztosan jó? Nem megy teljesen másfelé a csomag mint amerre gondolod?

zászló, zászló, szív

( apal v | 2023. 12. 29., p – 08:45 )

Nezd meg a transmit-hash-policy erteket. Azt erdemes ugy allitani ahogy a halozaton levo tobbi LACP eszkozon (masik gepeken ill. a szviccsen) is van. Pl elso korben nezd meg hogy mit csinal layer2 helyett layer3+4 beallitas mellett. 

Egyeztettem a helyi hálózat felelősével, azt az információt kaptam, hogy a switch-eken "IP Source Dest" mód van beállítva. Itt akkor eltérés van, mert szerver oldalon az alapértelmezett MAC (layer2) van beállítva. Ezek szerint ezt módosítanom kell "layer2+3" módra, és akkor egyezni fognak. Kérdésem: ez a hibás beállítás tudja a nyitó hozzászólásban szereplő hibát okozni?

( lcseh | 2024. 01. 31., sze – 06:24 )

Az 1000 session kb otthoni gépek esetén elég. Nézd meg mennyi egyidejű session-t kezel maximálisan a tűzfal, ezt mindegyiknél megadják. Milyen tűzfal egyébként? Nem triviális, hogy 100 user esetén mekkora kell, itthon rendzeresen alultervezik ezeket.

Én elindulnék kb 1500-tól és 50-100-anként változtatnék lefele, amíg elkezdi újra produkálni. Ja kevés, akkor felfele kell emelni.

Ha jól méretezett a tűzfal, nem lesz probléma, ha kicsi, akkor okozhat galibát.

Pl Zyxel esetén kell egy 200as legalább erre a feladatra, de inkább 500at használnék.

A pontos típust nem nevezhetem meg, de megüti azt a szintet amit ajánlásként írsz. Jelenleg 20.000 (húszezer) a limit erre a hosztra, de tegnap láttunk 4.000 feletti egyidejű kimenő UDP DNS kapcsolatot, és az este elérte ezt a limitet is... Gyanús hogy itt valami nem oké.

Mennyi az UDP "session" timeout a tűzfalon?

A DNS UDP reply csomag után a tűzfal még vár valahány másodpercet mielőtt úgy gondolja az a kapcsolat már nem "kell"

Így elég sok UDP bejegyzés bír lenni a a kapcsolati táblájában a random forrásportok miatt.

Ezeket a timeoutokat lehet állítani minden tűzfalon (linux alapúaknál ez a globális nf_conntrack_udp_timeout_stream paraméter)  ,de "jó" ok nélkül nem szokták állítani, vagy legalábbis specifikusan és nem globálisan ha már hozzá kell nyúlni.

WAN oldalon több IP címünk van. Van egy amin az irodai dolgozók mennek ki a netre, és van egy amin a levelező szerver. Minden, a levelező szerver irányából jövő csomag a neki fenntartott IP címen megy ki, és az arra a címre érkező HTTP(S) / IMAP / POP3 / SMTP kérések be vannak NAT-olva a levelező szervernek fenntartott alhálózatba. Nem osztozik senkivel, ez a subnet / VLAN csak az övé.

Arra gondolsz hogy a DNS pl. másik IP-n menne ki, és ott fogyna el a rendelkezésre álló session? Ez szerintem nincs így, a tegnapi limit-emelés óta csak egyetlen egyszer volt hogy elértem a limitet. Megnéztem ezt is, alaposabban:

A probléma egyik alkalommal akkor jelentkezett, amikor egy technikai e-mail címre kaptunk levelet. Vagyis nem levelet, hanem egymás után többet, kis idő-eltéréssel. Adott egy e-mail cím, legyen ez mondjuk a mindenkinek@domain.tld cím. Erre fel van véve egy rakás forward e-mail cím, egy része szerveren belüli, egy része szerveren kívüli (külsős munkatársak címei). Nézem a naplót, és a következő történik: bejön a levél, a Postfix megnézi 1-2 alap DNSBL-en, majd átadom az Amavis-nak. Itt aztán be van kötve a kiskutya füle is, hogy hatékonyak legyünk, többek között a SpamHaus DQS is. Ez utóbbit ha megnézzük, ilyen kéréseket intéz:

- apps.microsoft.com.a-mi-acces-keyunk.dbl.dq.spamhaus.net/A
- a.felado.ipv4.cime.a-mi-acces-keyunk.zen.dq.spamhaus.net/A

Mivel NCACHE NXDOMAIN jön vissza, és a zóna SOA rekordjában 1s cache TTL szerepel, így a kapott választ nem teszi el a helyi rekurzív névszerver cache-be, azaz szépen, minden alkalommal végiggyalogol majdnem az egész hierarchián. Ez oké eddig, nade ha van még húsz címzettünk akkor az Amavis milter a továbbított leveleken is végigmegy, mindannyinál lefuttatva a szűréseket. Plusz van még másik filter is ami megnézi a levélben szereplő URL-eket, stb., hogy nem-e adathalász oldalra visz, stb. Azaz simán ki tud menni 30-50 DNS lekérdezés egy levélhez, ha az "tartalmas". Húsz címzettnél ha realtime a blacklist (nincs DNS cache-elés) akkor akár több száz lekérdezés is kimegy. Ha a bejövő levélfogalom sűrű, és sok jön ilyen "listákra", akkor könnyen összejön több ezer session, ha pl. 2 perc a timeout...

Helyes az okfejtésem? A húszezer még mindig gyanús kicsit, de átnézem ma az összes SpamAssassin / Amavis konfigurációt, mert mint írtam igyekszünk nagyon hatékonyan SPAM-et szűrni, és jó pár helyről szipkázunk be adatokat hozzá.