Monitoring

Monitoring eduroam.cz je zajištován ze serveru monitoring.eduroam.cz. Jádro monitorovacího systému je realizováno pomocí nagiosu.

Na základě předchozích zkušeností 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.

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ý stroj. Tento stroj je nezávislý na eduroam infrastruktuře a s jednotlivými RADIUS servery organizací zapojenými do eduroamu komunikuje přímo. Stroj, na kterém je monitoring provozován, vystupuje v podstatě v roli dalšího Access Pointu (klienta). 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 end2end monitoring. Dříve, když bylo méně připojených institucí, bylo testování nastaveno v režimu každý s každým, tento přístup mohl umožnit kompletní test všech a generovat kompletní přehledovou matici. S narůstajícím počtem připojených organizací jsme museli z toho režimu ustoupit a vybrat k testování pouze vybranou skupinou institucí.

Výhodou 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.

Pokud není váš RADIUS a realm v seznamu mezi testovanými v monitoringu, zkontrolujte jestli je váš RADIUS aktivovaný v administrativní aplikaci.

Nevýhodou způsobu monitorování každého s každým bylo, že systém generoval 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 vybraných serverů a seznam vybraných testovacích účtů, a tento výběr testuje na všech institucích.

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á.

Zátěž celé infrastruktury závisí na počtu zapojených organizací. Dalším faktorem je frekvence testů, ale ta je nějak stanovená a není přímo žádoucí, aby se měnila kvůli včasnému podchycení problému.

Celkový počet testů se dá odvodit jako součet (TA * počet připojených) a (počet připojených * RS).

Celkový počet testů ve spodním řádku představuje absolutní počet vyřízených dotazů za dobu frekvence testů. 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í.

Z čísel je tedy vidět, že pro koncové servery není monitoring žádným rizikem.

Výše uvedené má zásadní podmínku v tom, že testování musí být v čase rovnoměrně rozprostřeno.

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.

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, který bude typicky delší než frekvence testu.

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 lze odvodit, jak dlouho je daná služba v současném stavu.

• 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í

• 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 výsledky dílčích testů IPSEC flr{1,2,3}
• test se spouští vzdáleně na národních RADIUSech (flr{1,2,3}.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 jednoho či více dílčích testů IPSEC flr{1,2,3}
  • normální perioda testování je 5 minut
  • v případě výpadku se testuje každou 1 minutu
  • notifikace se posílají

• 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 spojení
• 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 neposílají

• 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 výsledky dílčích testů RADSEC flr{1,2,3} podle typu připojení:
  • IdP+SP: alespoň jedno spojení musí být navázáno obousměrně, zbylé spojení musejí být navázané alespoň se směru od národních RADIUSů
  • SP: směrem k národnímu RADIUSu musí být navázáno alespoň jedno spojení
  • IdP: směrem od národnímu RADIUSu musí být navázány všechny spojení
• test se spouští vzdáleně na národních RADIUSech (flr{1,2,3}.eduroam.cz)
• test před ověřením spojení odesílá požadavek pod uživatelem status@flr.eduroam.cz, který je záměrně zakončen na národních RADIUSech odpovědí Access-Reject
  • používá se jako impulz pro navázání spojení pro případ, kdy není aktivita na RADIUSu organizace
• 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í

• 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í:
  • IdP+SP: oběma směry
  • SP: směrem k národnímu RADIUSu
  • IdP: směrem od národnímu RADIUSu
• 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 neposílají

• tato služba je testována pouze na RADIUS serverech připojených pomocí RADSEC a v řežimu SP
• testuje se platnost certifikátu pro RADSEC spojení u posledního záznamu
• závisí na:
  • PING
• WARNING stav nastává v případě blízké expirace certifikátu
• CRITICAL-HARD stav nastává při expiraci po 3třech pokusech
  • normální perioda testování je 1 den
  • v případě výpadku se testuje každých 12 hodin
  • notifikace se poposílají

• test ověřuje shodu IP adresy definované v administrativní aplikaci s aktuální IP adresou resolvovanou z DNS jména RADIUSu
• CRITICAL-HARD stav nastává po 3 pokusech, tj. max po 10+2*5=20 minutách od výpadku
  • normální perioda testování je 10 minut
  • v případě výpadku se testuje každých 5 minut
  • notifikace se posílají

• test kontroluje přítomnost NAPTR záznamu v DNS
• aplikuje se u realmů, které nejsou z domény .cz
• CRITICAL-HARD stav nastává po 3 pokusech, tj. max po 6+2*1=8 hodinách od výpadku
  • normální perioda testování je 6 hodin
  • v případě výpadku se testuje každou 1 hodinu
  • notifikace se posílají

• 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í pomocí rad_eap_test s parametrem -f který zajistí že Access-Request je větší než 1500B, tj. k fragmentaci UDP paketu. Navíc se testuje s účtem big-test@cesnet.cz s velkým Access-Acceptem který opět zajistí fragmentaci UDP paketu.
• aplikuje se pouze u "IdP+SP"
• 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 neposílají

• 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
• aplikuje se u role "SP"
• 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í

• test dostupnosti informací o pokrytí
• aplikuje se u role "SP"
• 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 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í

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

• tento test simuluje návštěvu uživatele z cizí organizace
• služba má dynamické jméno ve tvaru VISITORS@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 6+4*(3-1)= 14 hodinách od výpadku
  • normální perioda testování je 6 hodin
  • v případě výpadku se testuje každé 4 hodiny
  • notifikace se neposílají

• 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í

• test agregovaných výsledků autentizací (bez testovacích uživatelů)
• kontroluje minimální počet různých uživatelů pro kontrolu funkčnosti Wi-Fi infrastruktury za poslední týden (168h)
  • stav OK [5+] pokud je více než 5 různých uživatelů
  • stav WARNING [2-5] nastává pokud jsou 2 až 5 uživatelů
  • stav CRITICAL [0-1] pokud žádný uživatel či 1 uživatel
• existuje ve dvou variantách:
  • Wi-Fi-ACTIVITY-USERS-OF-<realm.cz>
    • aplikuje se u role IdP
    • kontroluje minimální počet různých domácích uživatelů na cizích realmech
  • Wi-Fi-ACTIVITY-VISITORS-AT-<realm.cz>
    • aplikuje se u role SP
    • kontroluje minimální počet různých návštěvníků na vlastním realmu

• 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
• aplikuje se u role "SP"
• 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í

• 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
• aplikuje se u role "SP"
• 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í

• test že IdP+SP zpracovává své realmy a neposílá žádný svůj realm zpět na národní RADIUS servery (detekce smyčky)
• test je implementován na základě dat z logů národního RADIUS serveru, podklady pro sondu se aktualizují jednou za hodinu
• aplikuje se u role "IdP+SP"
• 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í

• test že SP posílá vyplněný RADIUS atribut Chargeable-User-Idenity
• aplikuje se u role "SP"
• 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í

• 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.
• více informací
• řešení: FreeRADIUS v2, FreeRADIUS v3
• aplikuje se u role "IdP"
• 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í

• test že RADIUS server správně pracuje s obnovením sezení v PEAP a TTLS
• aplikuje se u role "IdP"
• 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í

• test přítomnosti organizace v eduroam CAT (přítomnost se konroluje na základě shody anglického názvu na pokryti.eduroam.cz a názvu v eduroam CAT)
• aplikuje se u role "IdP"
• 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í

• test certifikátu EAP serveru
• pokud je organizace registrována v systému eduroam CAT, provádí se validace certifitikátu proti zadané certifikační autoritě a validují se zadaná DNS jména EAP serverů
• aplikuje se u role "IdP"
• interval kontroly je stanoven na 2 hodiny
• CRITICAL-HARD stav nastává po 3 pokusech
• informace o změně certifikátu je udržována 1 den od detekce tohoto stavu
• stav je OK, nejsou detekovány žádné problémy s odesílaným certifikátem serveru (platnost, neshodny s CA, nesprávné DNS jméno …)
• stav je CRITICAL pokud vypršela platnost certifikátu (nebo CA z CATu) nebo nebylo možné certifikát získat
• pokud je detekován nějaký jiný problém, je stav WARNING
• notifikace se posílají

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.

Servery jsou seskupeny podle realmu registrovaného v administrativní aplikaci.

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