Střípky z IT - (4) : MX-ONE : Uhádnete, kde byl problém?

11.4. 19:19 | Přečteno: 1964× | linux | poslední úprava: 11.4. 22:04

Další zapeklitý problémek, na který jsem narazil.

Úvod

MX-ONE je telefonní ústředna od Mitelu (původně Aastra, předtím Ericsson), běží na SLES a Wildfly. Ústřednu jsem popisoval v tomto zápisku :
Firemní telefonní ústředna Aastra MX-ONE
MGU je Media Gateway Unit, což je hw box, ve kterém jsou ISDN karty a další zařízení nutné pro komunikaci po ISDN, Analogu, s Digitálními telefony. Čistě při VOIP řešení se SIP trunkama není potřeba.

Zapojení

Máme více poboček, pokud je na některé pobočce ISDN a digitální telefony, tak je tam i MGU. Pobočky jsou propojeny buď v rámci outsourcingu (MPLS), nebo vlastními IPSEC tunely.

Řešení, kde vznikl problém, vypadá z pohledu sítě takto :

PBX <-> ZyWALL 110(centrála) <- IPSEC -> ZyWALL 110(pobočka) <-> MGU

Problém

Celé řešení funguje takto hodně dlouho bez změny nastavení na routerech. Problém nastal v případě údržby trafostanice / výpadku proudu. První den překlopení problém nenastal, druhý den překlopení problém nastal. V pobočce přestaly fungovat digitální telefony, SIP telefony fungovaly dál.

Ve stavu MX-ONE bylo jen vidět, že MGU nejde připojit. Do MGU mám čirou náhodou heslo, je to Linux s obstarožním kernelem 2.6.14.7.

Co jsem vyzkoušel :

• ping mezi PBX a MGU byl ok
• restartovat MGU nepomohlo
• restartovat IPSEC tunely nepomohlo
• překonfigurace IPSEC tunelů na IKEv2 nepomohlo
• support PBX, který se nám o ústřednu stará, si nevěděl rady
• pro jistotu nastavil jako první firewall pravidlo na ZyWALL routerech povolení komunikace mezi oběma zařízeními + logování provozu, který stejně nic neřekl

Následoval sniff komunikace. Díky tomu jsem zjistil, že PBX a MGU mezi sebou komunikují přes SCTP protokol. Nemusel jsem ho ani nijak studovat, abych zjistil podrobněji, co se děje.

• PBX poslala "INIT"
• MGU přijalo "INIT" a odeslalo "INIT ACK"
• na PBX už ale "INIT ACK" nedorazil

Sniff jsem spouštěl i na obou ZyWALL routerech na lance a na ZyWALL v pobočce přišel "INIT ACK" a další skok už je jen IPSEC a v centrále na ZyWALLu "INIT ACK" už nebyl. V rámci IPSECu a routování se vždy operuje s celými segmenty. ALG je vypnuté.

Tzn., zádrhel někde na síti. Na internetu jsem našel tento issue u Strongswanu, který se používá na hafec zařízení : #882 a nějaké další problémy s tímto protokolem na starších kernelech u RedHatu v issue.

MGU je na stejném subnetu jako počítače a SIP telefony. U všeho dalšího nebyl problém, komunikace s PBX šla stejně jako s jinými servery na stejném subnetu jako je PBX. Prostě dva subnety spojené IPSCE tunelem s hafec servery a klienty, veškerá komunikace ok, jen jedno zařízení(MGU) má problém.

Závěr

Ještě bych mohl nahodit jednu nápovědu, ale to už by možná bylo do očí bijící.

Uhádnete, kde byl problém?

Zdar Max
PS: problém je již vyřešen, jedná se o kvízek

UPDATE: a máme vítěze kvízu Boban, komentář #5        

Komentáře

[ewew]

• IPSec nemá rád NAT ak je v určitom nastavení.
• Pravdepodobne firewall niekde po ceste blokoval protokol použivaný medzi dvomi čásťami PBX

Možno to nie je nič čo som napísal vyššie.

[Max]

NAT se tam nepoužívá, jen routing. A ve firewalle je vše povoleno.
Zdar Max
PS: provozuji doma Asterisk, server mám za natem a SIP mi fičí pěkně, tj. NAT(server) - NAT(client) no problemo

[debian+]

zle nastavená sieť, to už som raz videl.

[Max]

Ne.
Zdar Max

[Boban]

Řekl bych že problém byl v multihomingu SCTP. Napadá mě několik scénářů, konkrétní případ by měl být vidět z paketu INIT ACK.

[Max]

Ano,
je to tak. Resp. aspoň si to myslím. abych pravdu řekl, moc podrobně jsem obsah "INIT ACK" nezkoumal, ale mám ještě schované dumpy.
FreeBSD a některé implementace používají virtuální device pro IPSEC. Strongswan na Linuxu třeba ne. Takže se Strongswanem na Linuxu je vidět na WANce lokální provoz, protože WANka je iface pro ipsec. Mno a ZyWALL to má asi řešeno přes virtuální device, protože když to MGU nešlo připojit, viděl jsem "INIT ACK" na WAN rozhraní(na ZyWALLu v pobočce) a běžně tam vidět není (ve sniffu u ZyWALLu se dá nastavit jen sniff fyzického portu).
Řešením byl tedy nejspíše restart ZyWALLu. Já jsem to spojil s upgradem FW, ale myslím si, že restart by to dal dokupy. Jak to řešit systémověji jsem nezkoumal.
Zdar Max

[trekker.dk]

Strongswan na Linuxu třeba ne.

Může, když se tak nastaví. Z toho, že mi lokální provoz leze z interface pro WAN, by mi asi bylo na blití.

Na druhou stranu to, že se vám ipsec podařilo vůbec rozchodit, to je na pochvalu před nastoupenou jednotkou

[Max]

Provozuji Strongswan (na Debianu) několik let pro BYOD, cca 400 klientů. A nejen, že mi funguje, ale funguje mi NAT-NAT a pro všechny platformy (Win Mobile 8/8.1 i 10, win7/8/8.1/10, Android, iOS...).
Teď to jen budu muset trochu překopat z hlediska uložiště uživatelů a hesel a kvůli nasazení group based firewall policy.
Mám to rozjetý na IKEv2. Funkční mám i NAT-NAT L2TP over IPSEC, ale nepoužívám, protože oproti IKEv2 to je středověká záležitost.
Myslím, že to mám slušně najetý, ale stále tam jsou nějaké mezery k dopilování.

Ohledně toho iface, Strongswan jsem rozjížděl v době, kdy šel do monolitu a zbavoval se pluto, takže staré KLIPS implementace včetně PFKEY. Zůstalo to jen u FreeBSD.
VTI přišlo před pár lety a teď se objevilo ještě XFRX.
Zdar Max

[Jenda]

Já myslím, že to prostě bylo rozbitý.

[Max]

Samozřejmě, ale člověk musí vědět proč a jak to diagnostikovat. Slepě něco restartovat, když to nefunguje, to není řešení, ale workaround. A takový věci se mohou nasčítávat až to jednomu přeroste přes hlavu.
Zdar Max

[Jenda]

Nebo to prostě vypnout. 99% počítačů běží naprosto zbytečně.

[BFU]

Nebylo by lepsi to radeji zakazat ?

[Jenda]

Ne, ale dal bych na počítače spotřební daň jako na alkohol nebo cigarety.