Das ist doch die Selbsthilfegruppe hier?
Herrn Stoll fehlten ein paar Cent in der Abrechnung, mir fehlt ein ACK 🙂
Hintergrund: ein haproxy proxied SMTP. Dahinter steht ein (genauer: zwei) Exchange 2019. Der haproxy ist eine VM in ESX, der Exchange Blech, dazwischen eine Checkpoint, ebenfalls Blech. Zabbix meldet alle ca. 5 Minuten ein Problem mit dem haproxy:
Die Strecke geht so: SMTP-Client → haproxy in → haproxy out → Checkpoint in → Checkpoint out → Cisco Router → Exchange
Der haproxy hat nur ein Interface.
Ich hatte erst den Fehler gemacht, immer mit nmap nachzusehen, ob der Port offen ist. Nun, er ist immer offen für nmap. Ein telnet bringt es dann ans Licht:
~$ telnet haproxy 25 Trying x.x.x.x... Connected to haproxy. Escape character is '^]'. Connection closed by foreign host. ~$
Das ist nicht gesund. Da müßte das Banner des Exchange kommen — kommt auch meistens, aber eben viel zu oft nicht. Ein tcpdump zeigt mir dies:
No. Time Source Destination Protocol Length Info 80876 2020-08-27 20:58:14.221894 x.x.x.x y.y.y.y TCP 74 45794 → 25 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3775646035 TSecr=0 WS=128 Frame 80876: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) Ethernet II, Src: HewlettP_3e:28:38 (f4:03:43:3e:28:38), Dst: All-HSRP-routers_82 (00:00:0c:07:ac:82) Internet Protocol Version 4, Src: x.x.x.x, Dst: y.y.y.y Transmission Control Protocol, Src Port: 45794, Dst Port: 25, Seq: 0, Len: 0 Source Port: 45794 Destination Port: 25 [Stream index: 14791] [TCP Segment Len: 0] Sequence number: 0 (relative sequence number) Sequence number (raw): 1310793810 [Next sequence number: 1 (relative sequence number)] Acknowledgment number: 0 Acknowledgment number (raw): 0 1010 .... = Header Length: 40 bytes (10) Flags: 0x002 (SYN) Window size value: 64240 [Calculated window size: 64240] Checksum: 0x2041 [unverified] [Checksum Status: Unverified] Urgent pointer: 0 Options: (20 bytes), Maximum segment size, SACK permitted, Timestamps, No-Operation (NOP), Window scale [Timestamps] No. Time Source Destination Protocol Length Info 80877 2020-08-27 20:58:14.222206 y.y.y.y x.x.x.x TCP 66 25 → 45794 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1 Frame 80877: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) Ethernet II, Src: Cisco_84:ae:c8 (00:b0:8e:84:ae:c8), Dst: HewlettP_3e:28:38 (f4:03:43:3e:28:38) Internet Protocol Version 4, Src: y.y.y.y, Dst: x.x.x.x Transmission Control Protocol, Src Port: 25, Dst Port: 45794, Seq: 0, Ack: 1, Len: 0 Source Port: 25 Destination Port: 45794 [Stream index: 14791] [TCP Segment Len: 0] Sequence number: 0 (relative sequence number) Sequence number (raw): 3795728774 [Next sequence number: 1 (relative sequence number)] Acknowledgment number: 1 (relative ack number) Acknowledgment number (raw): 1310793811 1000 .... = Header Length: 32 bytes (8) Flags: 0x012 (SYN, ACK) Window size value: 65535 [Calculated window size: 65535] Checksum: 0xd0cb [unverified] [Checksum Status: Unverified] Urgent pointer: 0 Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted [SEQ/ACK analysis] [Timestamps] No. Time Source Destination Protocol Length Info 80878 2020-08-27 20:58:14.222473 x.x.x.x y.y.y.y TCP 54 45794 → 25 [RST, ACK] Seq=1 Ack=1 Win=64256 Len=0 Frame 80878: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) Ethernet II, Src: HewlettP_3e:28:38 (f4:03:43:3e:28:38), Dst: All-HSRP-routers_82 (00:00:0c:07:ac:82) Internet Protocol Version 4, Src: x.x.x.x, Dst: y.y.y.y Transmission Control Protocol, Src Port: 45794, Dst Port: 25, Seq: 1, Ack: 1, Len: 0 Source Port: 45794 Destination Port: 25 [Stream index: 14791] [TCP Segment Len: 0] Sequence number: 1 (relative sequence number) Sequence number (raw): 1310793811 [Next sequence number: 1 (relative sequence number)] Acknowledgment number: 1 (relative ack number) Acknowledgment number (raw): 3795728775 0101 .... = Header Length: 20 bytes (5) Flags: 0x014 (RST, ACK) Window size value: 502 [Calculated window size: 64256] [Window size scaling factor: 128] Checksum: 0x0fa5 [unverified] [Checksum Status: Unverified] Urgent pointer: 0 [SEQ/ACK analysis] [Timestamps]
Sprich: Ich habe:
- SYN
- SYN/ACK
- RST
Zu wenig für eine sinnvolle Kommunikation 🙁
Bevor ich anfange serielle Nadeldrucker zu klauen, frage ich mal in die Runde: Irgendwelche Ideen?
Stellte sich dann raus:
Der Kollege, der den Rechner aufgesetzt und den haproxy installiert hatte, hatte mit ACLs experimentiert. Kann man ja machen. Was man aber nicht machen sollte: nach jeder Änderung einer ACL einfach haproxy nochmal starten, ohne ihn voher beendet zu haben.
Das hatte dann zur Folge, daß fröhlich vile haproxy-Prozesse liefen, veon dnen die meisten mit Hand gestartet waren, offensichtlich hatte dann jeder eine andere Revision der ACLs im Speicher — und es war nur noch Zufall, welcher haproxy-Prozess (oder Thread?) mit welcher Konfiguration gerade den Request bearbeitete. Ein paar Prozesse ließen sich noch via systemctl beenden, ein paar mit einem simplen kill, der Rest mußte mit SIGKILL massakriert werden.
Danach ein systemctl start haproxy — und die Welt war wieder fein.
Ein Reboot hätte es auch getan, aber dann hätten wir nie die Ursache erfahren.
Der Kollege ist eigentlich ganz nett, aber von Linux sollte er vielleicht doch besser die Finger lassen…