Jak jsme pomáhali Vodafone: diagnostika problému (část 1/2)

Nemám rád problémy, co se objeví samy od sebe. Je to nečekaná práce navíc, ale hlavně se to špatně vysvětluje zákazníkům (málo který má pochopení pro věci, co se rozbíjí samy od sebe). Příběh, který Vám chci vyprávět je přesně takový.

Je to příběh podivuhodný, jelikož problém jsme sice odstranili, stále však nevíme, co jej mohlo způsobit (třeba někdo budete vědět – určitě napište). Dále je zajímavý tím, že nám zákazníkův ISP (Vodafone) zaplatil za jeho řešení, protože sám nevěděl, jak problém vyřešit. Nyní však k příběhu.

Zákazník nám jednoho úterního odpoledne zavolal, že mu začal špatně fungovat VoIP (velká prodleva v telefonech) a informační systém (IS byl velice pomalý). Obě služby byly poskytovány z datacentra a z místní sítě byly dostupné skrze IPSec VPN.

Rychlý popis prostředí (viz obrázek):

  • zákazník má vlastní routery v HA clusteru
  • ISP má u zákazníka primární (bezdrátový spoj) a záložní linku (xDSL) s veřejnými IP, které jsou routovatelné oběma trasami. Switche i routery jsou v HA zapojení.
  • Jak primární, tak i záložní linka mají last mile provozovanou subdodavatelem ISP (aby to nebylo jednoduché).Diagram zapojení sítě zákazníka.

Rychlá diagnostika problému

Jako první jsme tedy zkontrolovali vytížení serveru v datacentru, vytížení datové linky u zákazníka a v datacentru. Vše však bylo v pořádku. Zkusili jsme ještě pingy na interní a externí IP datacentra, abychom ověřili latence. Trefa! Latence na interní IP (skrze IPSec VPN) byla příliš vysoká (cca 500 ms oproti běžným 7 ms).

Diagnostické informace:

  • Ping z LAN na externí IP routeru v datacentru: 7 ms.
  • Ping z LAN na interní IP routeru v datacentrum (skrze IPSec VPN): 500 ms.
  • Vytížení WAN na obou stranách pod kapacitou linky, na straně zákazníka se nic neměnilo.

Tohle nebude jednoduché

Dosti zajímavá situace, se kterou jsme se do té doby nesetkali. Doufali jsme, že jak to přišlo, tak to samo odejde (to se bohužel nedělo). Zavolali jsme na ISP. Zákazník má u ISP vysoké SLA, takže by se mohli postarat. Bohužel ty nám oznámili, že na jejich straně je vše v pořádku a žádné změny nedělali. To je přesně ten bod, kdy Vám dojde, že tohle nebude problém, co se vyřeší za dvě hodiny.

V tomto bodě jsme museli zjistit, zdali bude problém na straně ISP (trasa), datacentra, nebo zákazníka (routery, FW, nějaká nekompatibilita). S ISP a datacentrem je těžká domluva (korporát), bylo by to na dlouho a zákazníka stála každá hodina spoustu peněz.

Rozhodli jsme se tedy začít u sebe. Vzali jsme dva Mikrotik routery, nastavili mezi nimi IPSec tunel a otestovali latence (tzn. měli jsme jistotu, že tunel je funkční a bez nekompatibilit). Jeden Mikrotik jsme zapojili u nás na firmě. Druhý jsme dovezli k zákazníkovi a zapojili místo jeho cluster routeru. Udělali jsme ping skrze nový IPSec tunel a …. výsledek byl špatný jako u původního tunelu LAN – DC (datacentrum). Latence pingu skrze IPSec tunel byla opět cca 500 ms. Tím jsme vyloučili problém u zákazníka (výměna routerů za jinou ověřenou technologii). Zároveň jsme vyloučili problém na straně datacentra (druhý konec tunelu nebyl v datacentru, ale u nás na pobočce).

Diagnostické informace:

  • Ping z LAN na externí IP routeru v datacentru: 7 ms.
  • Ping z LAN na interní IP routeru v datacentrum (skrze IPSec VPN): 500 ms.
  • Vytížení WAN na obou stranách pod kapacitou linky, na straně zákazníka se nic neměnilo.
  • Problém není na straně zákazníka: otestováno s jinými routery, které jinde fungují. Latence stále 500 ms.
  • Problém není na straně datacentra: otestováno IPSec tunelem na naši pobočku. Latence stále 500 ms
  • Problém bude na straně ISP.

Stáli jsme tedy před problémem vysvětlit toto vše na podpoře ISP a doufat, že se to dostane ke správným osobám, které budou mít dostatek znalostí a oprávnění pro řešení tohoto problému. Osobně se nerad obracím na jakýkoliv support, jelikož časová efektivita je nízká. Nejprve problém vysvětlujete první osobě, ta Vás nutí zkoušet věci, které jste už testovali, pak vysvětlovat problém další osobě. Zvlášť zdlouhavé to je, pokud vstupuje do hry časový posun mezi Vámi a technickou podporou. Doufám však, že se do budoucna těchto předsudků zbavím.

O tom, jak se nám podařilo problém vyřešit a jak nám Vodafone zaplatil za řešení problému najdete v druhé části článku Jak jsme pomáhali Vodafone: řešení problému (část 2/2).

Líbí se vám témata, o kterých píši?

Abyste nemuseli kontrolovat, jestli už vyšel nový článek, rád vám ho ihned po zveřejnění pošlu do e-mailu. Každý kontakt, který mi poskytnete, si nechám vždy jen pro sebe.

Diskuze k článku

P.

26. 10. 2017 v 21:01

A co jako první zkusit nějaky sniffer a zjistit co se s pakety děje, zvlašť pokud to jede na MK? Tipoval bych na nějaký problém s MTU a fragmentaci paketů ale může to být víc věcí…

Odpovědět

Odpovědět

Martin Haller

27. 10. 2017 v 10:01

To je dobrý postřeh. Bohužel už je to delší dobu, co jsme to řešili. Materiály co jsem měl, jsem mezitím při nějakém „úklidu“ smazal O:-) . Tuším, že „packet capture“ jsme také dělali, ale ničeho podezřelého jsem si nevšiml (samozřejmě jsem to mohl i přehlédnout).
Popříští pondělí vyjde druhá část článku, je tam více diagnostiky. Přišli jsme na to, který prvek to způsoboval, avšak stále nevíme proč (ISP ho prostě vyměnil). Měl bych radost, když byste si je přečetl, třeba Vás napadne čím to mohlo být.

Odpovědět

Odpovědět

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Hack The Box OSCP MCSE CHFI ECSA CCNP CCNA