cs:spravce:monitoring:end2end_monitoring_new

Toto je starší verze dokumentu!


end2end monitoring

Úvod

Na základě zkušeností s zaváděním eduroamu jsme dospěli k závěru, že monitoring postavený jen na kontrole stavu jednotlivých RADIUS serverů není dostatečný. Docházelo totiž k případům, kdy chyba v konfiguraci na některé z organizaci vedla k tomu, že se návštěvníci nemohli získat přístup k síti ale monitoring nás na toto neupozornil předem.

Ideální by asi bylo mít možnost instalovat do každé připojené instituce počítač s WiFi kartou a příslušným softwarovým vybavením. To by ale bylo dosti nákladné a administrativně jen velmi obtížně realizovatelné.

CESNETem implementované řešení používá k monitorování jediný k tomuto účelu vyhrazený počítač. Tento počítač je nezávislý na eduroam infrastruktuře a s jednotlivými RADIUS servery organizací zapojenými do eduroamu komunikuje přímo. Počítač, na kterém je monitoring provozován, vystupuje v podstatě v roli dalšího Access Pointu. Proto je nutné, aby měl přístup k RADIUS serveru organizace, který se běžně stará o vyřizování dotazů z AP.

Díky přímému přístupu ke koncovým RADIUS serverům a faktu, že pro testování se používají testovací účty všech zapojených institucí, se jedná o testování každého s každým, tedy o end2end monitoring. Výhodou tohoto monitoringu je kromě získání informací, kde mohou mít návštěvníci z některých institucí problém s přístupem, také to, že nezohledňuje transport dotazů mezi RADIUS serverem hostitelské a domácí instituce. Díky tomu bude tento monitoring použitelný i v případě, že v budoucnu dojde k vyřazení proxy serverů a komunikace mezi zapojenými institucemi bude probíhat přímo.

Zátěž generovaná monitoringem

Náčrtek situace s pohledu monitoringu

Nevýhodou tohoto způsobu monitorování je, že systém generuje podstatně vyšší zátěž než jak tomu bylo v minulosti. Zátěž se pochopitelně agreguje na proxy serverech, ale i koncové RADIUS servery organizací musí vyřídit nemalé množství dotazů.

Na obrázku je znázorněna situace z pohledu monitoringu. Pro monitoring není podstatné, že komunikace je realizována prostřednictvím NREN proxy RADIUS serverů. Také není moc podstatné, že některé instituce mají dva RADIUS servery a jiné jen jeden. Hrubě řečeno - monitorující systém má k dispozici seznam serverů a seznam testovacích účtů, testuje každý s každým a nic víc nepotřebuje.

To, že pro monitoring není podstatná znalost zapojení infrastruktury, je zjednodušení, které je přínosné pro výpočet generované zátěže. Implementovaný monitoring pochopitelně bere ohled na zapojení infrastruktury. Ve výpočtu zohledňuji pouze fakt, že dotaz s funkčním testovacím účtem stojí podstatně méně zdrojů, než dotaz s testovacím účtem, jehož domácí RADIUS server neodpovídá. To je dáno tím, že monitoring musí dlouho čekat než vyprší timeouty a RADIUS servery po cestě musí zkoušet opakovat dotazy na protějšek, který neodpovídá.

Odvození teoretické zátěže

RS Počet monitorovaných RADIUS serverů.
TA Počet testovacích účtů (test account).
Ng Frekvence testování návštěv (guest).
Nl Frekvence testování lokálním účtem.
Qm=Ng*(TA-1)+Nl Počet dotazů, které monitoring pošle přímo RADIUS serveru.
Qt=Ng*(TA-1)+Nl+Ng(RS-1) Celkový počet dotazů, které musí vyřídit RADIUS server organizace. Z toho Nl+Ng(RS-1) dotazů musí odbavit lokální AAI.
Qt=Ng*(TA+RS-2)+Nl Celkový počet dotazů, které musí vyřídit RADIUS server organizace.
Qnren=RS*Ng(TA-1) Počet dotazů, které musí zpracovat NREN RADIUS servery.

Vypočtená teoretická zátěž

Zátěž celé infrastruktury závisí na počtu zapojených organizací TA, počet RADIUS serverů je odvozen od počtu testovacích účtů: RS=1.5*TA. Ng=2, Nl=12. V časovém intervalu 1 hodiny se cizí účty testují 2x a vlastní (lokální) každých 5min. Po dosazení jsem dostal tato čísla:

TA=20, RS=30 TA=50, RS=75 TA=500, RS=750 TA=2000, RS=3000
server organizace 108 0,03 258 0,07 2 508 0,70 10 008 2,78
NREN servery 1 140 0,32 7 350 2,04 748 500 207,92 11 994 000 3 331,67

Čísla v prvním sloupci představují absolutní počet vyřízených dotazů za hodinu, hodnota v druhém sloupci je přepočtena na vteřinu. Je třeba mít na paměti, že množství paketů bude o jeden řád vyšší. V tabulce jsou uvedeny EAP dotazy, což např. v případě PEAP-MSCHAPv2 znamená 10 RADIUS paketů na vyřízení. Chcete-li si s výpočty pohrát, je k dispozici OpenOffice Calc Sheet, který jsem použil.

Z čísel je tedy vidět, že pro koncové servery není monitoring žádným rizikem, problémy se objeví mnohem dříve na NREN RADIUS serverech. Reálné výkonnostní parametry v tento okamžik nemám k dispozici, ale očekávám, že systém je schopen vyřídit alespoň 1000 paketů za vteřinu.

Výše uvedené má zásadní podmínku v tom, že testování musí být v čase rovnoměrně rozprostřeno. To se zhruba daří splnit, jak ukazují grafy počtu testovacích procesů. Další informace o monitoringu jsou k dispozici v samostatném článku.

Služby monitorované na serverech připojených organizací

Služby monitorované na serveru organizace

Na každém serveru organizace je monitorována řada služeb. Jejich význam, závislosti na ostatních službách dalších serverů a vzájemné závislosti jsou popsány dále. Na připojeném obrázku můžete vidět, jak icinga tyto služby vizualizuje.

Čas poslední kontroly

Při rozkliknutí konkrétní služby se dostaneme na detailní informace. Last check Udává, kdy naposledy byla služba kontrolována. Pokud služba nemá splněnu některou ze závislostí, tak vůbec nejsou spouštěny její testy. Například když není povolen přístup pro ping z monitorovacího systému, tak se netestují žádné služby, ale icinga stále zobrazuje poslední známý stav služby.

Historie

V záložce History v detailu služby je zobrazena kompletní historie stavů služby včetně poslední změny stavu. Z poslední změny stavu zle odvodit, jak dlouho je daná služba v současném stavu.

PING

  • testuje se odpověď na ICMP echo request
  • CRITICAL-HARD stav nastává po 10ti pokusech, tj. max po 5+9*1=14 minutách od výpadku
    • normální perioda testování je 5 minut
    • v případě výpadku se testuje každou 1 minutu
    • notifikace se posílají

IPSEC

  • tato služba je testována jen na RADIUS serverech, které tvoří infrastrukturu a jsou připojeny pomocí IPSEC, není k dispozici u serverů sloužících jen pro monitoring
  • testuje se odpověď na ICMP echo request skrz IPSEC tunel
  • test se spouští přes vzdáleně na radius1.eduroam.cz
  • závisí na:
    • PING
  • CRITICAL-HARD stav nastává po 10ti pokusech, tj. max po 5+9*1=14 minutách od výpadku
    • normální perioda testování je 5 minut
    • v případě výpadku se testuje každou 1 minutu
    • notifikace se posílají

RADSEC

  • tato služba je testována jen na RADIUS serverech, které tvoří infrastrukturu a jsou připojeny pomocí RADSEC, není k dispozici u serverů sloužících jen pro monitoring
  • testuje zda jsou navázána RADSEC spojení oběma směry
  • test se spouští přes vzdáleně na radius1.eduroam.cz
  • závisí na:
    • PING
  • CRITICAL-HARD stav nastává po 10ti pokusech, tj. max po 5+9*1=14 minutách od výpadku
    • normální perioda testování je 5 minut
    • v případě výpadku se testuje každou 1 minutu
    • notifikace se posílají

BIG-PACKET

  • test přenosu fragmentovaných UDP paketů
  • závisí na navázaném spojení na národní RADIUS server (IPSEC nebo RADSEC)
  • závisí na HOME-REALM-ALIVE na radius1.cesnet.cz
  • test se provádí s účtem big-packet@cesnet.cz což je specielní účet s velkým Access-Acceptem. Pokud testovaný server zvládne tento paket doručit na ermon, tak to znamená že je schopen přijmnout (z národního RADIUSu) ale i odeslat (na ermon) fragmentový UDP paket.
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 24 hodin
    • v případě výpadku se testuje každé 12 hodin
    • notifikace se posílají

VCELKA-MAJA

  • test přeposílání vnitřní EAP identity, více viz email v eduroam-admin listu, technická zpráva
  • závisí na domácím realmu
  • CRITICAL-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 24 hodin
    • v případě výpadku se testuje každé 12 hodin
    • notifikace se posílají

INSTITUTION-XML

  • test existence souboru institution.xml
  • URL souboru institution.xml se bere z definice realmu organizace v CESNET CAAS
  • testuje se na existenci stringu inst_realm ve staženém dokumentu
  • testuje se na existenci všech aliasů příslušných k realmu ve staženém dokumentu
  • testuje se na neexistenci jakýchkoliv dalších realmů ve staženém dokumentu
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 24 hodin
    • v případě výpadku se testuje každé 3 hodiny
  • notifikace se posílají

COVERAGE-INFO

  • test dostupnosti informací o pokrytí
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 24 hodin
    • v případě výpadku se testuje každé 3 hodiny
  • notifikace se posílají

domácí realm

  • domácí realm je ten, pro který je server koncovým
  • domácích realmů může být na jednom serveru definováno několik
  • služba má dynamické jméno ve tvaru @realm
  • tento test kontroluje, jestli je schopen server autentizovat uživatele domácího realmu
  • závisí na PING
  • CRITICAL-HARD stav nastává po 3 pokusech, tj. max po 5+10*(3-1)=25 minutách od výpadku
    • normální perioda testování je 5 minut
    • v případě výpadku se testuje každých 10 minut
    • notifikace se posílají

realmy ostatních organizací

  • tento test simuluje návštěvu uživatele z cizí organizace
  • služba má dynamické jméno ve tvaru @realm
  • závisí na:
    • domácí realm, tj. jestli na serveru funguje RADIUS (pokud je na serveru více domácích realmů, závisí na všech zároveň)
    • domácí server testovaného realmu/testovaný realm, tj. jestli domácímu serveru příslušnému k tomuto realmu funguje RADIUS
  • CRITICAL-HARD stav nastává po 3 pokusech, tj. max po 180+120*(3-1)=420 minutách = 7 hodinách od výpadku
    • normální perioda testování je 180 minut
    • v případě výpadku se testuje každých 120 minut
    • notifikace se neposílají

CALLING-STATION-ID

  • test že SP posílá vyplněný RADIUS atribut Calling-Station-Id
  • test je implementován na základě dat z logů národního RADIUS serveru, podklady pro sondu se aktualizují jednou za hodinu
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 24 hodin
    • v případě výpadku se testuje každých 12 hodin
    • notifikace se posílají

OPERATOR-NAME

  • test že SP posílá vyplněný RADIUS atribut Operator-Name, testuje se existence a syntaktická správnost
  • test je implementován na základě dat z logů národního RADIUS serveru, podklady pro sondu se aktualizují jednou za hodinu
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 24 hodin
    • v případě výpadku se testuje každých 12 hodin
    • notifikace se neposílají

CHARGEABLE-USER-IDENTITY

  • test že SP posílá vyplněný RADIUS atribut Chargeable-User-Idenity
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 24 hodin
    • v případě výpadku se testuje každé 3 hodiny
    • notifikace se neposílají

FAKE-UID

  • Test že IdP vynucuje shodu vnější a vnitřní identity. Jako vnější (anonymní) identita se použije anonXXX@realm.cz a jako vnitřní pak testovací účet organizace. IdP takový požadavek na ověření nesmí vyhodnotit pozitivně. IdP které nepodporuje Chargeable-User-Identity nesmí povolit žádnou anonymní identitu (tj. ani anonymous@realm.cz), viz Technické požadavky a doporučení pro členy federace eduroam.cz.
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 24 hodin
    • v případě výpadku se testuje každé 3 hodiny
    • notifikace se posílají

COMPROMISED-USERS

  • test je popsán na stránce systému etlog

CONCURRENT-INST

  • test je popsán na stránce systému etlog

CVE-2017-9148

  • test že RADIUS server správně pracuje s obnovením sezení v PEAP a TTLS
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 48 hodin
    • v případě výpadku se testuje každé 3 hodiny
    • notifikace se posílají

HOME-REALM-ALIVE

  • test zda je realm „naživu“ alespoň na nekterém z domácích serverů
  • notifikace se neposílají

VISITORS

  • test agregovaných návštěvnických realmů
  • měl by poskytnout správcům přehled o tom, zda nemají návštěvníci problém s ověřováním
  • stav je OK, pokud je více než 80 % uživatelů návštěvnických realmů úšpěšně ověřováno
  • test je WARNING, pokud je alespoň více než 70 % uživatelů návštěvnických realmů úšpěšně ověřováno
  • v ostatních případech je stav CRITICAL
  • závisí na domácím realmu
  • CRITICAL/WARNING-HARD nastává po 3 neúspěných pokusech
    • normální perioda testování je 3 hodiny
    • v případě výpadku se testuje každé 2 hodiny
    • notifikace se posílají

CAT

  • test přítomnosti organizace v eduroam CAT
  • stav je OK, pokud je organizace registrována v eduroam CAT, má vyplněný profil a je možné stáhnout instalátory
  • pokud je detekován nějaký problém s profilem instituce je stav WARNING
  • v ostatních případech je stav CRITICAL
  • notifikace se neposílají

Skupiny služeb a serverů

Pro snazší orientaci ve značném množství serverů a služeb jsou definovány skupiny, které slučují související objekty a usnadňují navigaci.

Skupiny serverů

Servery jsou seskupeny podle realmu registrovaného v CESNET CAAS.

Skupiny služeb

Služby jsou seskupeny podle svého názvu.

Matice dostupnosti

Matice dostupnosti

Skupiny služeb a serverů sice trochu usnadňují orientaci v množství dat, ale neumožňují vidět aktuální stav sítě najednou. Proto jsem vytvořil na icinze nezávislou matici dostupnosti. V ní jsou na řádcích servery organizací a ve sloupcích jsou uvedeny jednotlivé realmy. Díky tomu lze na téměř první pohled okamžitě zjistit, kde co nefunguje.

K matici je volný přístup, adresa je https://monitor.eduroam.cz/matrix/.

Poslední úprava:: 2019/04/26 11:41