Prek SSH-odjemalca najprej vzpostavimo povezavo s strežnikom in v sistemski ukazni vrstici vnesimo niz /etc/init.d/snmpd status. Če nismo še ničesar spreminjali, SNMP ni aktiven (to je privzeto stanje v večini distribucij), zato vnesimo /etc/init.d/snmpd start. S tem ukaznim nizom smo aktivirali SNMP-agenta na našem strežniku. Delovanje preverimo z enim od SNMP-orodij. V našem primeru smo uporabili brezplačni MIB Browser Personal Edition (http://www.ireasoning.com/). Uporaba MIB Browserja ni zahtevna – v polje Address vpišemo IP-naslov strežnika z Asteriskom (v našem primeru 192.168.178.10), v polju Operations izberemo možnost Get Bulk ali Walk in pritisnemo gumb Go. Čez nekaj trenutkov se nam v polju Result table izpišejo podatki, ki jih je posredoval strežnik. Če z drsnikom preverimo rezultat oziroma posredovane informacije, že dobimo nekaj koristnih informacij o strežniku. Določene privzete podatke/informacije moramo še spremeniti (na primer SysContact, SysLocation), prav tako nikjer niso vidne informacije, povezane z delovanjem Asteriska. Če želimo spremeniti parametra syslocation in syscontact, v datoteki /etc/init.d/snmpd.conf poiščemo definicijo obeh parametrov (področje System contact information) in ju s pomočjo urejevalnika (na primer vi) spremenimo. V našem primeru smo namesto Unknown napisali mojMikro (in hkrati izbrisali nadaljevanje vrstice), namesto Root pa EA evan.ambroz@mojmikro.si (in izbrisali nadaljevanje vrstice). Po teh spremembah smo datoteko shranili in izvedli osvežitev nastavitev s pomočjo niza /etc/init.d/snmpd restart. Če MIB Browser zaženemo še enkrat, vidimo, da naš strežnik že posreduje nove podatke.

Namesto ročnega spreminjanja datoteke snmpd.conf bi lahko uporabili tudi orodje net-snmp-utils, ki ga lahko namestimo prek interneta s pomočjo ukaza yum install net-snmp oziroma yum install net-snmp-utils. Konfiguracijo agenta izvedemo s pomočjo ukaza snmpconf in izborom možnosti spremembe datoteke snmpd.conf. Uporaba omenjenih orodij je dobrodošla zaradi dejstva, da z omenjenimi orodji definiramo tudi pravice za dostop. Če SNMP Browserja nismo namestili, lahko po namestitvi net-snmp-utils poskusimo tudi z vnosom ukaznega niza snmpwalk localhost -c public -v 2c na našem strežniku, ki nam prav tako izpiše vrednosti OID-parametrov.

Problem vpisa oziroma prikaza želenih parametrov SNMP za strežnik smo že rešili, še vedno pa nimamo prikazanih podatkov o delovanju Asteriska, ki nas najbolj zanimajo. Razlog je, da Asterisk še ni »povezan« tako, da bi komuniciral s SNMP-agentom in bi prek njega pošiljal želene podatke nadzornemu sistemu. Ročno bomo zato naredili še nekaj popravkov. V datoteki /etc/asterisk/res_snmp.conf omogočimo komunikacijo s SNMP (izbrišemo znak # pred vrstico enabled=yes in subagent =yes). Na koncu datoteke snmpd.conf dodamo vrstice:

master agentx
agentXSocket /var/agentx/master
agentXPerms 0660 0550 nobody asterisk

Ker podpora delovanja Asteriska ni del standardnih MIB-definicij, moramo dodati še zasebni MIB-datoteki. Definiciji najdemo na spletnih straneh https://wiki.asterisk.org/wiki/display/AST/Digium+MIB+Definitions in https://wiki.asterisk.org/wiki/display/AST/Asterisk+MIB+Definitions. Vsebino prekopiramo v tekstovni datoteki in ju shranimo v imeniku /usr/share/snmp/mibs ter izvedemo restart SNMP (/etc/init.d/snmpd restart). V ukazno vrstico vnesemo še chmod 755 /var/agentx in ponovno izvedemo restart SNMP. Za konec izvedemo še ponoven zagon AMP-portala (amportal restart) in zadnjo »osvežitev« SNMP (/etc/init.d/snmpd restart). S pomočjo opisanega postopka smo vzpostavili povezavo Asteriskovega »procesa« z lokalnim SNMP-agentom na strežniku.

Za dostop do informacij bomo tako ponovno uporabili MIB Browser, zato vsebino obeh MIB-definicij prekopiramo tudi v tekstovni datoteki (na primer DigiumMIB.txt in AsteriskMIB.txt) in ju dodajmo v MIB Explorer (File – LoadMIBs). Če zdaj v MIB-drevesu pogledamo pod standardne parametre (OID .1.3.6.1.2.1.1 – .iso.org.dod.internet.mgmt.mib-2.system), dobimo izpisane podatke o samem strežniku, sprehod po zasebnih Digiumovih parametrih (OID .1.3.6.1.4.1.22736.1.0 – iso.org.dod.internet.private.enerprises.digium.asterisk) pa nam odpre dostop do Asteriskovih parametrov. Omenimo le nekatere najzanimivejše parametre. Parameter AstVersionString (.1.3.6.1.4.1.22736.1.1.1.0) nam izpiše različico Asteriska (v našem primeru (1.8.17.10). AstConfigUpTime in AstConfigReloadTime nam izpišeta čas od zadnjega zagona Asterisk »procesa« oziroma informacijo o osvežitvi konfiguracije. S stališča nadzora delovanja samega Asteriska je zanimiv AstConfigPid (.1.3.6.1.4.1.22736.1.2.3.0), ki nam izpiše vrednost procesa na enak način, kot bi jo v ukazni vrstici prebrali s pomočjo ukaza ps -ax | grep asterisk. Če vrednost ni definirana, Asterisk ni aktiven – zelo koristna informacija za nadzorni sistem, ki lahko aktivira ustrezno akcijo (na primer izvede zagon Asteriska, pošlje ustrezno obvestilo). Tu sta še dve zanimivi informaciji: AstConfigCallsActive (.1.3.6.1.4.1.22736.1.2.5.0) in AstConfigCallsProcesed (.1.3.6.1.4.1.22736.1.2.6.0). Kot že ime samo pove, nam prvi poda število trenutno aktivnih klicev v času posredovanja informacije SNMP-agenta, drugi parameter pa nam posreduje informacijo o celotnem številu obdelanih klicev od zadnjega zagona Asteriska. Z uporabo SNMP Walk/Get po drevesni strukturi lahko najdemo še druge uporabne parametre, ki jih lahko koristno uporabimo.

DUDE V VLOGI VELIKEGA BRATA

Aktivacija SNMP in poznavanje parametrov nam omogočata vključitev strežnika z Asteriskom v nadzorni sistem. Ogledali si bomo preprost primer in uporabili brezplačni Dude (http://www.mikrotik.com/thedude) v trenutno aktualni stabilni različici 3.6.

Po namestitvi in zagonu lahko naš strežnik dodamo med nadzorovane naprave na dva načina. Dude lahko sam preišče omrežje (pogoj je, da je naš strežnik v definiranem omrežju), strežnik pa lahko vedno dodamo tudi ročno, kot smo storili v našem primeru. V področju Contents izvedemo dvoklik na Devices in dodamo novo napravo (klik na rdeči +). V oknu Add Device izberemo polje Address in vnesemo IP-naslov našega strežnika Asterisk (tokrat 192.168.178.11, saj imamo več strežnikov). Ostala polja lahko pustimo nespremenjena, vnos pa potrdimo s klikom na gumb Next. Ker drugih naprav za zdaj ne bomo dodali, vnos končamo s klikom na gumb Finish.

V segmentu Contents nato izberemo Network Maps – Local, ki nam pokaže ikono, na kateri so izpisani IP-naslov strežnika, trenutna obremenitev procesorja ter zasedenost pomnilnika in diska. Če postavimo miško na to ikono, nam Dude prikaže še dodatne informacije (MAC-naslov, ime naprave oziroma SNMP-parametre, ime sistema, ime skrbnika sistema, lokacijo sistema, čas aktivnosti strežnika – up time …).

Dvoklik na ikono strežnika nam omogoči dostop do novih možnosti. V polje Name namesto IP-naslova vpišemo Asterisk mojMikro. Izberemo zavihek Pooling in zaradi preverjanja odziva spremenimo privzete vrednosti intervalov na 2 in 5 sekund ter števec na vrednost 2. V zavihku Services (s klikom na +) dodamo nadzor nad delovanjem strežnika Apache (http). To naredimo s klikom na Probe (cpu) in izberemo http, izbor pa potrdimo s kliki na gumba Apply in OK. Pogled na ikono naprave pokaže, da se je spremenil opis naše naprave in obarvanost (iz vijoličaste v modro-zeleno oziroma zeleno). Če na nadzorovani napravi izvedemo zaustavitev http strežnika (/etc/init.d/httpd stop), se bo čez nekaj trenutkov na zaslonu spremenila obarvanost ikone iz zelene v oranžno, na ikoni te naprave pa se izpiše tudi ime storitve, ki ne deluje (http). Po ponovnem zagonu strežnika (/etc/init.d/httpd start) se obarvanost ikone spremeni nazaj v zeleno. Dodali bi lahko še možnosti obveščanja (na primer zvočno, zapisovanje v dnevnik, pošiljanje sporočila na strežnik Syslog …).

Kot že omenjeno, pa nas zanima delovanje Elastixa oziroma njegovih komponent. Ena od njih je strežnik MySQL, ki uporablja vrata 3306. Na podoben način, kot smo izbrali http, dodajmo zdaj nadzor nove storitve. Namesto na polje Probe oziroma cpu kliknemo na gumb s tremi pikami, ki nam odpre okno Probes. S klikom na »+« dodamo novo storitev tako, da vnesemo v polje Name – MySQL, v polje Type – TCP in v polje Port – 3306. Vnos še potrdimo s kliki na gumba Apply in OK. Zdaj lahko nadzor MySQL-strežnika dodamo še ikoni naše naprave, tako kot v primeru http strežnika. Če zdaj izvedemo zaustavitev MySQL, bo Dude kot napako izpisal ime tega strežnika.

Pri definiranju nadzora MySQL-strežnika smo v polju Type izbrali možnost TCP. Med možnostmi pa lahko najdemo tudi SNMP. Ustvarili bomo novo funkcijo, ki bo nadzorovala aktivnost modula Asterisk. V Dude zato najprej dodajmo Digiumove oziroma Asteriskove MIB-datoteke. Izberemo Contents – Files – »+« in dodamo MIB-datoteki. Ko obe datoteki dodamo, lahko definiramo želeno. V oknu New Probe določimo v polju Name ime (na primer Asterisk core), Type SNMP, v polje OID pa vnesemo iso.org.dod.internet.private.enterprises.digium.asterisk.asteriskConfiguration.astConfigPid.0 (izberemo s pomočjo gumba in izbire ustreznega parametra). V polju Compare Method izberemo možnost not equal (kot normalno delovanje je definirano, da je vrednost Pid parametra različna od »0«). Enako kot pri obeh prejšnjih primerih lahko poskusimo z zaustavitvijo (/etc/init.d/asterisk stop). V zadnjem primeru pa gre za pomembno razliko – če sta začasno ustavljena http strežnik ali MySQL, bo Asterisk v večini primerov še vedno deloval, če pa ustavimo sam Asterisk, ne bo delovalo popolnoma nič, kar je povezano z njegovo funkcionalnostjo.

NE LE ZA NAPAKE

V opisanih primerih smo SNMP uporabljali le za nadzor delovanja posamezne komponente. Uporabimo pa ga lahko tudi za prikaz informacij, povezanih z normalnim delovanjem sistema. Dodajmo nov »nadzor«, le da bomo tokrat nadzorovali parameter, ki nam poda informacijo o trenutno aktivnih klicih. Enako kot prej definiramo novo ime (na primer Aktivni klici), sprememba pa je v polju OID, ki ima zdaj vrednost iso.org.dod.internet.private.enterprises.digium.asterisk.asteriskConfiguration.astConfigCallsActive.0. Polje Compare Method mora imeti vrednost equal (normalno delovanje pomeni vrednost »0«). Če prek strežnika vzpostavimo klic, se bo zaradi spremembe parametra (ne ustreza več definiranemu pogoju) ikona strežnika obarvala enako kot v primeru napake. Ker takšen prikaz ne ustreza stanju napake med nadzorovanimi storitvami, izberemo (rdeče obarvani) Aktivni klici in kliknemo na gumb Ack. V primeru novega klica se bo v času klica ikona strežnika namesto v oranžno obarvala v modro barvo. Tako lahko ugotovimo normalno stanje mirovanja in ga ločimo od normalnega aktivnega stanja oziroma stanja napak na posameznih modulih. Na podoben način lahko dosežemo tudi prikaz stanja na posameznih povezavah (trunkih), izpis klicne in klicane številke … Lep dokaz, da ne potrebujemo komercialnega sistema, če želimo pridobiti informacije, povezane z delovanjem. Gre torej bolj za vprašanje domišljije in znanja, ki ga lahko uporabite tudi za vključitev drugih naprav v vaš nadzorni sistem. Če opisano presega vaše potrebe po nadzoru, še vedno pa želite v realnem času nadzorovati osnovne parametre, povezane z uporabo virov strežnika, lahko uporabite enega od pripomočkov za tovrsten nadzor (na primer Qkrellm, ki je na voljo za različna okolja).

RAZPLETANJE VOZLOV

V večini primerov nas bo pravilno zasnovan nadzorni sistem opozoril na bližajočo se težavo (na primer kritična obremenitev procesorja, pomanjkanje prostora na trdem disku) ali že odkrito motnjo oziroma napako pri delovanju. Tako kot pri podobnih primerih lahko izvedemo ponovni zagon problematičnega »servisa« oziroma skupine povezanih modulov. Če tak poseg ne zadošča, lahko poskusimo tudi s ponovnim zagonom celotnega strežnika. Običajno to zadošča, vedno pa žal ne. Če ste takšne posege prisiljeni izvajati (pre)pogosto, je smiselno odkriti vzrok za takšno stanje. Vzroki so lahko različni: morebitna napaka v programski opremi, ki jo lahko reši že posodobitev, neustrezna konfiguracija virov strojne opreme ali napaka v konfiguracijskih datotekah … Vzrok pa je lahko tudi v sistemu, s katerim se vaš strežnik povezuje, oziroma v povezavi do drugih strežnikov ali uporabnikov.

Odkrivanje kompleksnejših napak zahteva uporabo problemom primernih pripomočkov. Eden najpomembnejših je »vohljač« prometa oziroma sniffer. Za zajem in analizo prometa, povezanega z Asteriskom, je zelo uporaben brezplačni Wireshark (http://www.wireshark.org). O njem in možnostih njegove uporabe smo v naši reviji že pisali (http://www.mojmikro.si/v_praksi/mojster/vohljaci_in_prepovedane_skrivnos...), zato tokrat na to temo ne bomo izgubljali preveč besed. Wireshark omogoča tudi manj izkušenemu uporabniku pridobivanje podatkov, ki jih potrebuje za analizo VoIP-prometa in z njim povezanih protokolov (na primer SIP). Dejstvo pa je, da se marsikdo uporabe tovrstnih orodij izogiba, saj nima »rutine«, potrebne za analizo pridobljenih podatkov, in uporablja tovrstno orodje le takrat, ko res ne gre drugače.

Zajemanje prometa s pomočjo vohljača pa se lahko izkaže tudi kot »neučinkovito«, še zlasti v primerih, ko lahko informacijo pridobimo na lažji, uporabniku prijaznejši, predvsem pa hitrejši način. Asterisk ima kar nekaj uporabnih pripomočkov, s pomočjo katerih lahko ugotovimo vzroke za težave oziroma nedelovanje strežnika. V preteklih besedilih smo že spoznali, da lahko pravilnost delovanja posameznih scenarijev upravljanja s klici ugotovimo s pomočjo Asteriskove ukazne vrstice. Ustreznost delovanja pa lahko ugotovimo tudi na drugih segmentih. Zaradi širokega spektra možnih povezav si oglejmo možnosti na ravni SIP-protokola.

PRIPOMOČKI

Razhroščevanje najlažje izvajamo na ravni, ki nas zanima – v našem primeru SIP. Vključimo ga v Asteriskovi ukazni vrstici s pomočjo ukaznega niza »sip set debug on«. Takoj po potrditvi vnosa Asteriskova konzola v realnem času izpiše vsa SIP-sporočila, ki se prenašajo med strežnikom Asterisk in drugimi SIP-strežniki oziroma SIP-agenti. Če je sporočil na zaslonu preveč in nas motijo, zanima pa nas konkreten uporabnik, lahko izpis omejimo z dodatnim parametrom (na primer sip set debug peer 192.168.178.22). Če razhroščevanja ne potrebujemo več, ga izključimo z vrstico »sip set debug off«. Včasih želimo imeti podatek o vseh fazah določenega klica. V tem primeru je zelo uporabno beleženje zgodovine. Vključimo ga z ukazom »sip set history on«. Ukaz uporabljamo tako, da v času trajanja klica vnesemo »sip show history« in pritisnemo tipko »tab«, ki nam izpiše informacijo o zabeleženih klicih. Beleženje zgodovine izključimo z vrstico »sip set history off«.

Koristne podatke nam izpiše niz »sip show …«, ki mu dodamo parameter, ki nas zanima. Komunikacijski kanali, ki so trenutno aktivni, so v času trajanja klicev vidni z ukazom »sip show channels«. Posamezni kanal pa izberemo z ukazom »sip show channel (v času aktivnih klicev) +« in pritiskom na tipko »tab«.

Če sistem načelno deluje, uporabniki pa zaznajo motnje (na primer popačen govor), lahko uporabimo niz »sip show channelstats«, ki nam v času trajanja klica izpiše parametre, ki vplivajo na kakovost (na primer izgubljeni paketi, podrhtavanje). Vzroki za težave so lahko povezani tudi s stanjem registracij. »Sip show peers« nam izpiše statuse prijavljenih SIP-agentov in trunkov, »sip show registry« pa izpiše status stanj registracij našega strežnika Asterisk na druge SIP-strežnike. Podobno informacijo kot »sip show peers« nam prikaže tudi »sip show subscriptions« (prijavljeni SIP-agenti na strežnik Asterisk). Podobne možnosti kot »sip show …« nam ponuja tudi »core show …«, ki se skupaj s parametrom, ki sledi, nanaša na parametre strežnika (settings, sysinfo, uptime). Na podoben način kot za SIP lahko dobimo tudi informacije za IAX2 (»iax2 set debug on«, »iax2 show peers«, »iax2 show channels« …).

ŠE PA ŠE

Asterisk smo v besedilih obravnavali kot zmogljivo platformo za telekomunikacijske storitve. Moderne telekomunikacijske storitve pa so bistveno več kot le prenos govora in faksiranih sporočil oziroma videa. Našemu strežniku bomo zato dodali strežnik za prenos pisnih sporočil (IM – Instant messaging). V Elastixovem grafičnem vmesniku je že pripravljen dostop do strežnika Openfire (http://www.igniterealtime.org/projects/openfire/), ki ga namestimo s pomočjo Elastixovega grafičnega vmesnika v zavihku IM. Sama namestitev strežnika Openfire za naše potrebe še ne zadošča, zato moramo po namestitvi dodati še ustrezni vtičnik (Asterisk – IM Openfire Plugin), ki ga najdemo v Openfirovem zavihku Plugins. Več o strežniku Openfire morda v kakšni od naslednjih številk.

Na Elastixovi domači strani lahko najdemo tudi povezavo do brezplačnih in plačljivih dodatkov, namenjenih Elastixu (http://addons.elastix.org/). Če želenega dodatka ne najdemo, lahko poskusimo z namestitvijo »standardnih« dodatkov prek vmesnika FreePBX (PBX-Unembedded FreePBX). Najdemo jih na spletni straneh http://svn.freepbx.org/modules/release/ oziroma http://www.freepbx.org/support/documentation/module-documentation/third-.... Paziti moramo le, da ne namestimo modula, ki bi moteče vplival na delovanje sistema oziroma grafičnega vmesnika.

POD ČRTO

Asterisk je brez dvoma zmogljivo okolje za razvoj telekomunikacijskih storitev. Namestimo ga lahko na različne platforme – od virtualnega okolja, modificiranih usmerjevalnikov in kartičnih malčkov (na primer Raspberry Pi – http://www.uelastix.org/) pa vse do visokozmogljivih strežnikov.

Iz opisanih primerov je razvidno, da lahko hitro zagotovimo funkcionalnosti, ki so »običajne« (na primer funkcionalnost hišne telefonske centrale). Sorazmerno hitro pa lahko naletimo na omejitve na ravni privzetih grafičnih vmesnikov, zato je nujno dobro poznavanje delovanja sistema oziroma gradnikov, ki jih želimo uporabiti. Le to nam omogoča prilagajanje sistema v skladu z našimi potrebami. V nasprotnem primeru bo naš sistem lahko sicer deloval, nikoli pa ne bomo prepričani, ali nas ne bo pustil na cedilu in kaj bodo vzroki za to, kaj šele, da bi naredili korak naprej.

Na osnovi Asteriska lahko zgradimo visoko zanesljiv sistem, precej energije pa bo moral razvijalec vložiti v okviru posameznih distribucij v zagotavljanje varnostnih mehanizmov. Standardni gradniki (na primer uporabljena baza MySQL) omogočajo v primeru vdora preprosto spremembo podatkov, vprašanje pa je, ali boste to ugotovili, saj za to nimate zagotovljenih ustreznih revizijskih sledi. Podobno velja za posnetke (pogovori, sporočila govorne pošte), saj so ti zapisani v standardnem zapisu in jih lahko vsak z ustreznim dostopom do strežnika posluša ali izvozi. Morda je vse skupaj na prvi pogled videti pretirano paranoično, a zavedajte se, da bo vaš strežnik priključen na lokalno omrežje, to pa na internet – tu pa boste vsekakor našli nekoga, ki je na področju varnosti (z drugimi besedami vdorov) boljši od vas, še zlasti če mu pustite vsaj »priprta« vrata prek AMI-vmesnika.