[MEGOLDVA] TCP reset TLS kapcsolaton keresztül beérkező nagyméretű leveleknél

Web, mail, IRC, IM, hálózatok

Sziasztok!

 Egy nagyon érdekes problémát vettem ma észre: Néhány külső mail szolgáltató (pl. google.com, t-online.hu) SMTP szervere TCP resetettel szakítja félbe a felőlük mifelénk beküldött leveleik TCP adatfolyamát, amint a beküldött adat mennyisége túllépi a 12MB-ot. Néhány napig újra próbálkozik az SMTP szerverük a levél beküldésével, de aztán feladja, amikor is a küldő valami ilyesmi hibaüzenetet kap (gmail esetén):

"Diagnostic-Code: smtp; write error: FAILED_PRECONDITION: write error (0): error"

 A leveleket fogadó mail gateway-ünk az internet felől nézve DNAT mögött van és postfix fut rajta. Megpróbáltam egy másik postfixről ennél nagyobb (kb. 25MB-os) levelet átküldeni a szóban forgó mail SMTP gatewayre hasonló DNAT-on keresztül, de arról simán, minden hibaüzenet beérkeztek ezek a nagyméretű levelek.

 Sokat próbálkoztam a postfixben a CHUNKING és PIPELINING képességes meghirdetésének kikapcsolásával, illetve a reject_unauth_pipelining korlátozás feloldásával, sőt átmenetileg még a spamszűrő miltert (rspamd) is letiltottam, de a hiba maradt. Ilyesmi üzeneteket látok a postfix logjában:

postfix/smtpd[7822]: lost connection after DATA (12779680 bytes) from mail-pl1-f169.google.com[209.85.214.169]

 Amikor viszont kikapcsoltam a STARTTLS képességet a bejövő levelek fogadása esetén (azaz titkosítatlanná tettem a bejövő levélforgalmunkat a smtpd_tls_security_level = none paraméterrel), akkor már probléma nélkül bejönnek a nagyméretű levelek a fent említett szolgáltatóktól.

 Összegezve úgy tűnik tehát, hogy bizonyos nagy email-szolgáltatók szerverei valami miatt nem hajlandóak kb. 12MB-nál hoszabb TLS titkosítású adatfolyamot fenntartani a felénk irányuló SMTP kommunikáció során, hanem látszólag minden különösebb ok nélkül TCP resettel zárják a kapcsolatot a bűvös határ átlépésekor. Néhány TLS kapcsolat kicsit tovább is eljut (láttam ~17MB-osat is), de általábon nem sokkal a 12MB-os korlát átlépésekor megjön a TCP RST.

Tapasztaltatok már ilyesmit? Mi lehet az oka?

 

Szerk: Ahogy andrej_ rávilágított, egy IDS/IPS rendszer okozta a hibát, amit azonban nem a szolgáltató üzemeltet, hanem on premise. Mea culpa.

  • 713 megtekintés

( n.balazs v | 2023. 04. 19., sze – 20:42 )

Szerkesztve: 2023. 04. 19., sze – 20:48

TLS-t enforce-olni még 2023-ban sem ajánlott SMTP esetén. Sok az elavult, régi SMTP szerver és/vagy tűzfal, céges L7 tűzfal.
Én az "smtpd_tls_security_level = may" beállítással használnám a Postfixet.

Majd hétvégén ránézek, hogy az én szerverem és a Gmail között is él-e a hiba.

Szerk:
- Melyik disztribúció? Hányas verzió?
- Levelező szervereknek mi a verziószámuk?

Eddig nálam is csak "smtpd_tls_security_level = may" volt, de most teljesen ki kellett kapcsolnom :-( Azt sem zárom ki, hogy TCP/IP szinten van a hiba, mondjuk valahol a DNAT-oló tűzfalban, de akkor is érdekes, hogy egy másik postfix simán áthámozta magát rajta, illetve a gmail-féléket is csak akkor zavarja, ha STARTTLS-t használnak. Nagyméretű (~15MB-os) csatolmányokat próbáltam gmailről beküldteni, de mind zátonyra futott, amíg ki nem kapcsoltam a titkosítást.

A verziókkal kapcsolatban nem szeretnék nagyon részletekbe bocsátkozni, de annyit elmondhatok, hogy mind a probléma által sújtott SMTP gateway, mind a mögötte lévő levelezőszerver annyira friss, amennyire csak lehet. Különösen az előbbi. Azon majdnem minden szoftver az aktuális upstream verzión van.

( arpi_esp v | 2023. 04. 19., sze – 20:56 )

hat ez eleg furan hangzik... en nem lattam meg ilyet, pedig eleg nagy a forgalmunk gmail-el, tls-en, sot ujabban ipv6-on.

elso korbe azt mondanam MTU, de akkor tls nelkul se menne...

esetleg egy tcpdumpot megnezni, hogy mi tortenik a reset elott, van-e valami timeout, csomag ismetles, stb vagy gyorsan es folyamatosan jon a data aztan hirtelen vege szakad? egyszer valami MFP mailkuldeset debuggoltuk ami 10 secnel megszakadt hirtelen, igy nagyobb scanneleseknel volt hiba.

Megnéztem Wiresharkkal. Amennyire én meg tudom ítélni, minden tökéletes, legalábbis a Winreshark semmilyen hibára nem figyelmeztet, ráadásul a TLS titkosítás nélküli levélküldés közben ugyanakkora adatcsomagok és ugyanolyan gyakori ACK válaszok vannak, mint a titkosítatlan forgalom esetében. Csak IPv4-es címünk van, és a gmailből küldött levelek általában a 209.85.0.0/16 hálózat felől jönnek. Most úgy érzem, az internetszolgáltatónknál van a hiba. A titkosítatlan és titkosított forgalom kísértetiesen hasonló - és hibátlannak tűnő - TCP-felépítéséből, illetve a gmail hibaüzenetéből (Diagnostic-Code: smtp; write error: FAILED_PRECONDITION: write error (0): error) ítélve jelenleg azt gondolom, hogy a gmail levélküldő szervere is úgy látja, mintha a mi SMTP szerverünk küldené neki a TCP RST csomagot, így aztán szerintem inkább arról lehet szó, hogy a szolgáltatónk valamelyik hálózati eszköze gondolja úgy, hogy gyanús a köztünk folyó kommunikáció, ezért mindkét félnek TCP RST-t küldve megöli a kapcsolatot :-(

( pepelopez | 2023. 04. 20., cs – 07:43 )

Szerkesztve: 2023. 04. 20., cs – 07:43

az én debian 11/exim vps-em eldobálta a gmailes kapcsolatokat ez lett a megoldás
net.ipv4.tcp_window_scaling=0 hátha segít:)

( NevemTeve | 2023. 04. 20., cs – 08:30 )

Melyik hálózati készülék végez víruskeresést (vagy hasonló jócselekedet) a rajta átfolyó tartalmon?

( uid_4278 | 2023. 04. 20., cs – 11:13 )

Az smtpd_tls_loglevel segíthet, hogy miért lett RST?

( nice | 2023. 04. 20., cs – 14:07 )

Úgy néz ki, tényleg a szolgáltatónk okozza a problémát. Valószínűleg egy olyan tartalomszűrő van valahol a hálózatukban, ami mindkét irányba bontja a 25-ös TCP portunkra irányuló STARTTLS-es kapcsolatokat kb 12MB forgalmazás után. Megkértem egy ismerősömet, hogy küldjön nagyméretű levelet egy on premise SMTP szerverről, és mindkettőnk szervere úgy látta, mintha a másik bontaná a kapcsolatot. Sőt, a TCP RST után egy ideig nem is tudott új TCP kapcsolatot nyitni a 25-ös portunk felé, mert már a kapcsolat felépítésekor, a kisméretű SYN csomagok cseréjekor mindkét gép úgy látta, mintha a másik TCP RST-tel bontaná a kapcsolatot, így csomagméret-problémáról nem igazán lehet szó, inkább arról, hogy a minket megvédeni próbáló szolgáltatói hálózati eszköz az eredeti kapcsolat bontása után már TCP/IP szinten is "védeni" kezdett minket.