}w !"#$%&'()+,-./012345
Masarykova univerzita Fakulta informatiky
Měření VoIP provozu pomocí IP toků Diplomová práce
Jan Vojtěch
Brno, jaro 2014
Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
V Brně dne 8. ledna 2014
Jan Vojtěch
Vedoucí práce: RNDr. Rostislav Vocilka ii
Poděkování Chtěl poděkovat společnosti INVEA-TECH za poskytnutí zkušeností a technického zázemí při vývoji a testování navrženého monitorovacího systému. Mé poděkování si zaslouží také pan Tomáš Koníř, autor programu FlowMon Exportér, který mi poskytl cenné rady a zkušenosti při psaní rozšiřujícího modulu process-voip. Dále děkuji panu Mgr. Petru Velanovi, autorovi programu ipfixcol, za užitečné rady a velmi rychlé opravy chyb. Nakonec bych chtěl poděkovat Ing. Pavlu Čeledovi, Ph.D. a RNDr. Pavlu Minaříkovi, Ph.D. za konzultace během psaní práce, věcné připomínky a korektury textu.
iii
Shrnutí Diplomová práce popisuje principy fungování VoIP telefonů založených na protokolu SIP, vysvětluje způsob činnosti protokolů SIP, SDP, RTP a RTCP a poukazuje na nedostatky tohoto konceptu. Je zde uveden příklad průběhu telefonního hovoru podle RFC 3261 a dále ukázka toho, jak telefonní hovor dnes opravdu probíhá u předních českých VoIP poskytovatelů. Druhá část práce se věnuje problematice monitorování protokolu SIP, RTP a RTCP na vysokorychlostních sítích. Je zde popsána architektura celého systému a vysvětlen způsob začlenění navrženého systému do řešení INVEA-TECH FlowMon. Následuje diskuze implementačních detailů na straně sondy i kolektoru. V závěru je provedeno zhodnocení vytvořeného systému a testy výkonu.
Klíčová slova SIP, SDP, RTP, RTCP, vysokorychlostní sítě, VoIP, FlowMon, NetFlow, IPFIX, Ipfixcol.
iv
Obsah 1 2
3
4
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principy fungování VoIP telefonie . . . . . . . . . . . . . . . 2.1 Komunikační protokoly používané v internetové telefonii . . 2.1.1 Protokol SIP . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Protokol SDP . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Protokol RTP . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Protokol RTCP . . . . . . . . . . . . . . . . . . . . . 2.2 Průběh telefonního hovoru řízeného protokolem SIP . . . . 2.2.1 Hovor podle RFC 3261 . . . . . . . . . . . . . . . . . 2.2.2 Problémy způsobené překladem IP adres . . . . . . . 2.2.3 SIP telefonní hovor v praxi . . . . . . . . . . . . . . 2.2.4 Vyzváněcí tóny . . . . . . . . . . . . . . . . . . . . . 2.2.5 Speciální případy hovoru . . . . . . . . . . . . . . . Monitorování VoIP provozu na vysokorychlostních sítích 3.1 Architektura systému pro sběr NetFlow dat . . . . . . . . . 3.2 Cisco AVC . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Existující nástroje pro monitorování VoIP provozu . . . . . 3.3.1 VoIPmonitor . . . . . . . . . . . . . . . . . . . . . . 3.3.2 PRTG Network Monitor . . . . . . . . . . . . . . . . 3.3.3 VoIP & Network Quality Manager . . . . . . . . . . 3.3.4 Homer . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 nProbe a ntop . . . . . . . . . . . . . . . . . . . . . 3.4 Monitorování VoIP provozu pomocí řešení FlowMon . . . . Programové vybavení síťové sondy . . . . . . . . . . . . . . 4.1 FlowMon Exportér 4.0 . . . . . . . . . . . . . . . . . . . . . 4.1.1 Základní použití . . . . . . . . . . . . . . . . . . . . 4.1.2 Rozšiřující moduly . . . . . . . . . . . . . . . . . . . 4.1.3 Aplikační rozhraní rozšiřujících modulů . . . . . . . 4.2 Procesní plugin process-voip . . . . . . . . . . . . . . . . . . 4.2.1 Implementace pluginu process-voip . . . . . . . . . . 4.2.2 Rozpoznávání protokolu SIP . . . . . . . . . . . . . 4.2.3 Zpracování protokolu SIP . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3 4 4 8 10 11 16 17 19 28 30 31 33 34 34 35 36 36 37 37 38 38 40 40 41 42 43 45 48 51 53 v
4.2.4 Detekce a zpracování protokolů RTP a RTCP 4.2.5 Agregace paketů . . . . . . . . . . . . . . . . 5 Programové vybavení kolektoru . . . . . . . . . . . . 5.1 Instalace programu ipfixcol . . . . . . . . . . . . . . 5.2 Integrace vlastního rozšíření do FlowMon GUI . . . 5.3 VoIP Explorer . . . . . . . . . . . . . . . . . . . . . 5.3.1 Výpis toků . . . . . . . . . . . . . . . . . . . 5.3.2 Poslední hovory . . . . . . . . . . . . . . . . . 5.3.3 Podrobné informace o hovoru . . . . . . . . . 6 Zhodnocení a testy navržených pluginů . . . . . . . 6.1 Agregace statistik a dělení toků . . . . . . . . . . . . 6.2 Měření výkonu . . . . . . . . . . . . . . . . . . . . . 7 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Význam jednotlivých bitů v polích SIP_STATS . . A.1 Typ 1: Servisní požadavky . . . . . . . . . . . . . . . A.2 Typ 2: Odpovědi na servisní požadavky . . . . . . . A.3 Typ 3: Požadavky týkající se hovoru . . . . . . . . . A.4 Typ 4: Odpovědi na požadavky týkající se hovoru . .
vi
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
54 56 58 58 59 61 62 63 64 67 67 68 71 74 74 74 74 75
Kapitola 1
Úvod Internet je fenoménem současné doby. Počet jeho uživatelů neustále roste, vznikají na něm nové mediální služby, a ty staré analogové, například rozhlasové a televizní vysílání, se na něj postupně přesouvají. Pro řadu lidí je počítač prostředkem každodenní komunikace a elektronická pošta se společně s chatem stala běžnou součástí našich životů. V posledních letech zažívá rozmach nejen textová, ale především hlasová komunikace prostřednictvím celosvětové sítě. Tato práce se zabývá měřením technických a kvalitativních parametrů telefonních hovorů uskutečňovaných přes internet. Technologie umožňující přenos hlasu po internetu souhrnně označujeme termínem VoIP (Voice over Internet Protocol). Z těch mezi uživateli nejznámějších jmenujme například program Skype a přenosový protokol SIP (Session Initiation Protocol), který používají jak počítačové programy vytvořené pro přenos hlasu, tak i specializované telefonní přístroje určené pro internetové volání. Díky výrazné úspoře provozních nákladů přešlo na VoIP mnoho významných podniků, univerzit, veřejných institucí i domácností. Současný trh nabízí poměrně širokou škálu dedikovaných přístrojů umožňujících internetové volání, díky jejichž snadné obsluze a podobnosti s běžnými telefony řada uživatelů ani nepozná, že nepoužívá klasickou telefonní síť. Avšak používání VoIP s sebou přináší také řadu nevýhod a rizik. Pro správnou funkci telefonů je nutné připojení k internetu s dostatečnou přenosovou kapacitou, navíc výpadek počítačové sítě zpravidla způsobí také výpadek sítě telefonní. Pokud chceme garantovat dostatečnou kvalitu telefonních hovorů, je nutné preferovat hlasová data před ostatním provozem na síti, což nebývá vždy snadné. Dalším rizikem je možnost odposlechu telefonních hovorů, útok zaměřený na jeden nebo více telefonních uzlů nebo unesení telefonního čísla a volání na cizí účet. Aby bylo možné efektivně řešit problémy související s VoIP technikou, kontrolovat kapacitu síťových spojů, řešit bezpečnostní incidenty, vyhodnocovat kvalitu hovorů a mapovat využití telefonní sítě, je zapotřebí mít kvalitní monitorovací nástroje. 1
1. Úvod Tato diplomová práce se zabývá problematikou monitorování telefonních sítí pracujících s protokolem SIP. V následujících kapitolách vysvětluji princip činnosti tohoto protokolu a zmiňuji se také o protokolech SDP, RTP a RTCP, které se rovněž podílí na telefonních hovorech vedených přes počítačovou síť. Po vysvětlení základních pojmů následuje krátká ukázka průběhu telefonního hovoru a vysvětlení součinnosti výše zmíněných protokolů. Následně zasazuji teoretický koncept do praxe a ukazuji, jakým způsobem se telefonní hovory v dnešní době opravdu navazují. Druhá polovina diplomové práce je více praktická a zabývá se rozšířením monitorovacího systému FlowMon společnosti INVEA-TECH o možnost detailního sledování telefonních sítí založených na protokolu SIP. Po stručné definici požadavků a vysvětlení architektury celého systému představuji rozšiřující moduly vytvořené pro sondu a kolektor. Popsané algoritmy vycházejí z principů činnosti VoIP sítí, které jsou popsány v první části textu. Výsledkem práce je obsáhlé shrnutí principu činnosti VoIP telefonů a dále funkční monitorovací nástroje, které bude možné po menších úpravách začlenit přímo do monitorovacího systému FlowMon.
2
Kapitola 2
Principy fungování VoIP telefonie V současném světě VoIP technologií se vyskytuje celá řada komunikačních protokolů, které umožňují přenášet zvuk nebo i video. Obecně je lze rozdělit do čtyř základních skupin: •
Standardizované protokoly – zejména SIP a starší H.323.
•
Hybridní protokoly, které spojují standardizované protokoly a různá proprietární rozšíření – například program GoogleTalk založený na protokolu XAMPP.
•
Proprietární, ale dobře dokumentované protokoly – například Cisco Skinny.
•
Proprietární uzavřené protokoly – například Skype.
Výhodou standardizovaných protokolů je široká podpora ze strany výrobců programů i specializovaných zařízení, například VoIP telefonů a tzv. VoIP bran umožňujících používat analogové telefony pro internetové volání. Některé specializované směrovače umožňují prioritizovat VoIP provoz, čímž zajišťují kvalitu hovorů i na zatížené síti. Proprietární protokoly se používají téměř výhradně na počítačích a mobilních telefonech a jejich výrobci většinou těží z reklamy, která se zobrazuje v klientské aplikaci. Někteří uživatelé mohou využívat faktu, že struktura těchto protokolů není tak dobře popsána nebo se dokáží maskovat za jiné běžně používané protokoly (HTTP), a proto se v sítích obtížněji detekují a filtrují. Například blokace programu Skype může být na některých typech firewallů poměrně obtížná až nemožná. Největším problémem všech VoIP technologií je, že nezaručují kvalitu hovoru. Velké firmy proto často investují své prostředky do monitorování síťového provozu mimo jiné i za účelem kontroly a zlepšování kvality telefonních hovorů. V těchto podnicích se používají většinou dedikované telefonní přístroje, které komunikují prostřednictvím protokolu SIP. Proto se budu 3
2. Principy fungování VoIP telefonie v následujících kapitolách této diplomové práce věnovat právě tomuto komunikačnímu protokolu.
2.1
Komunikační protokoly používané v internetové telefonii
V diplomové práci se věnuji především protokolu SIP, nicméně ten sám o sobě slouží pouze pro navázání spojení. Aby mohl vzniknout telefonní hovor, je potřeba také dohodnout jeho parametry, k čemuž se používá protokol SDP (Session Description Protocol). Samotná hlasová komunikace se nejčastěji přenáší prostřednictvím protokolu RTP (Real-time Transport Protocol) a je kódována za pomoci určitého kodeku, například PCMA, G.722, G.723.1, G.711a, G.711u nebo G.729a. V této kapitole postupně představím výše zmíněné síťové protokoly tak, aby čtenář získal představu o jejich základní struktuře a možnostech využití. Potom bude následovat praktická ukázka telefonního hovoru vycházející ze znalostí získaných v této kapitole. 2.1.1 Protokol SIP SIP (Session Initiation Protocol) je signalizační protokol, který byl v roce 2002 standardizován dokumentem RFC 3261 [2]. Protokol SIP oficiálně používá port 5060/UDP, nicméně v některých síťových konfiguracích jej můžeme vidět i na jiných portech nebo nad protokolem TCP. Jak již napovídá slovo „signalizační“, nezabývá se samotným přenosem hlasu, nýbrž jen nalezením volaného účastníka, žádostí o hovor a jeho ukončením. Protokol SIP umožňuje následující: •
Nalezení volaného uživatele,
•
zjištění, zda je tento uživatel ochoten komunikovat,
•
dohodu parametrů spojení,
•
sestavení spojení,
•
řízení spojení, změny parametrů a ukončení spojení.
SIP je textový protokol inspirovaný protokolem HTTP. Jeho zprávy můžeme rozdělit na dva základní typy: požadavky a odpovědi – účastník zasílá požadavky jinému uzlu v síti a ten na ně odpovídá. Každý požadavek má na prvním řádku hlavičky uveden název metody, identifikátor adresáta a jméno 4
2. Principy fungování VoIP telefonie protokolu s verzí. Zbylé řádky hlavičky obsahují povinná a volitelná pole, u kterých nezáleží na pořadí ani na velikosti písmen. Jméno každého pole končí dvojtečkou, která uvozuje hodnotu, jež může zabírat jeden nebo i více řádků. Hlavičku odděluje od těla zprávy prázdný řádek. Norma připouští dvě verze názvů polí – dlouhé a jednoznakové. Pro lepší čitelnost budu v této práci používat dlouhou variantu. REGISTER sip : sip . fayn . cz SIP /2.0 CSeq : 23 REGISTER Via : SIP /2.0/ UDP 213.192.10.172:5060; branch = z9hG4bK ; rport User - Agent : Ekiga /3.3.2 From : < sip : jvojtech98@sip . fayn . cz >; tag =9 c6c4a91 Call - ID : 88674 a91 -5861 - e211 -88 be -001 c2594a0d6@milacek To : < sip : jvojtech98@sip . fayn . cz > Contact : < sip : jvojtech98@213 .192.10.172:5060 > Expires : 3600 Content - Length : 0 Max - Forwards : 70
Výpis kódu 2.1: Ukázka SIP požadavku. Odpovědi mají stejný formát jako požadavky, liší se jen prvním řádkem, který obsahuje jméno protokolu, jeho verzi a stavový kód odpovědi následovaný jeho slovním popisem. SIP /2.0 403 Forbidden ( Bad auth ) Via : SIP /2.0/ UDP 213.192.10.172:5060; branch = z9hG4bK ; received =213.192.10.172; rport =5060 From : < sip : jvojtech98@sip . fayn . cz >; tag =9 c6c4a91 To : < sip : jvojtech98@sip . fayn . cz >; tag = as693b0a64 Call - ID : 88674 a91 -5861 - e211 -88 be -001 c2594a0d6@milacek CSeq : 23 REGISTER User - Agent : CANISTEC - MATRIX - T100 Supported : replaces Content - Length : 0
Výpis kódu 2.2: Ukázka SIP odpovědi. Účastníci komunikace na sebe odkazují pomocí tzv. SIP URI (Uniform Resource Identifier), což je jednoznačný identifikátor uživatele, který má následující tvar: sip:
@<server> Identifikátor začíná jménem protokolu, které může být buď sip nebo sips. Druhá varianta se používá pro šifrované spojení. Následuje jméno uživatele a název nebo IP adresa serveru, na němž lze uvedenou osobu kontaktovat. 5
2. Principy fungování VoIP telefonie Každý SIP paket musí povinně obsahovat pole To, From, CSeq, Call-ID, Max-Forwards, a Via. Pole To a From obsahují SIP URI adresáta a odesílatele požadavku, volitelně mohou obsahovat i uživatelsky přívětivé jméno (podobně jako je tomu v hlavičce emailu). Pokud je paket součástí dialogu (viz níže), přidává se k oběma polím ještě parametr tag, který je pro daný dialog jednoznačný. Pole CSeq představuje pořadové číslo požadavku doplněné o jméno metody, která byla předmětem požadavku. Díky němu je možné snadno přiřadit doručené odpovědi k již odeslaným požadavkům. Pole Call-ID je identifikátorem aplikace a společně s tagy v polích From a To jednoznačně určuje SIP komunikaci (telefonní hovor). Pole Max-Forwards definuje maximální počet skoků SIP paketu. S každým přeposláním požadavku se uvedené číslo o jedničku sníží a při dosažení čísla nula se paket zahodí. To zabraňuje SIP paketům, aby do nekonečna bloudily sítí. Poslední povinné pole nese označení Via a používá se k záznamu trasy, kterou prochází požadavek. To je nutné proto, aby bylo možné odesílat odpovědi zpět stejnou cestou, z jaké přišly požadavky. Každý server, který požadavek zpracovává, přidává další pole Via se svou vlastní adresu a portem. Při posílání odpovědi se pole Via odpovídající mezilehlým uzlům opět odebírají. Kromě toho je v poli Via uveden také parametr branch, což je jedinečný identifikátor požadavku. Pomocí protokolu SIP spolu komunikují následující subjekty: •
Uživatelský agent (UA) – libovolný program nebo zařízení (telefon) umožňující uživateli obousměrnou komunikaci prostřednictvím protokolu SIP.
•
SIP proxy – internetový server, který přeposílá žádosti UA dalším SIP proxy nebo UA. Často funguje zároveň jako brána pro volání do běžné telefonní sítě. Využívání SIP proxy podléhá zpravidla autentizaci a bývá zpoplatněno.
•
SIP registrar – internetový server, na který se přihlašují UA a sdělují mu svou aktuální pozici (IP adresu a port). Server si tuto informaci uloží a na vyžádání ji předá například jinému UA nebo SIP proxy. SIP proxy bývají zároveň i SIP registrary.
Jak již bylo řečeno, komunikace je založena na výměně požadavků a odpovědí. Každý požadavek začíná jménem metody, jejichž výčet pro základní protokol SIP bez rozšíření je uveden níže: •
INVITE – Navázání hovoru nebo úprava parametrů spojení.
•
ACK – Potvrzení o přijetí odpovědi na požadavek INVITE.
6
2. Principy fungování VoIP telefonie •
BYE – Ukončení telefonního hovoru.
•
CANCEL – Zrušení probíhajícího požadavku.
•
OPTIONS – Dotaz na seznam podporovaných služeb.
•
REGISTER – Oznámení polohy uživatele SIP registrar serveru.
V dnešní době se používají i další metody, které se definují v různých rozšířeních protokolu. Jedná o metody umožňující oznamování událostí (SUBSCRIBE, NOTIFY, PUBLISH), získávání informací během hovoru (INFO), přepojování hovorů (REFER), předávání textových zpráv (MESSAGE) a úpravu parametrů hovoru (UPDATE). Tyto metody však nejsou pro monitorování SIP provozu, kterému se věnuje tato práce, klíčové, a proto se jim nebudu dále věnovat. Odpovědi na SIP požadavky mají na prvním řádku místo jména metody stavový kód a jeho textový přepis. Jméno metody je uvedeno v povinném poli CSeq. Stavové kódy mají tři cifry a jejich rozdělení je inspirováno protokolem HTTP. První číslice určuje obecný stav požadavku, další dvě pak konkrétní událost nebo chybu. Následuje výčet všech skupin a příklady nejpoužívanějších kódů: •
1xx – informace o průběhu zpracování požadavku. Požadavek nesmí nikdy skončit odpovědí s tímto kódem, vždy musí nakonec přijít zpráva s vyšším kódem, která informuje o výsledku zpracování. Nejčastěji se používají kódy 100 Trying, 180 Ringing a 183 Session Progress.
•
2xx – informují o úspěšném splnění požadavku, nejčastěji můžeme vidět odpověď 200 OK.
•
3xx – informují o nové pozici uživatele nebo o tom, jak ho správně kontaktovat. Často se používají kódy 301 Moved Permanently, 302 Moved Temporarily a 305 Use Proxy.
•
4xx – chyby klienta. Specifikace udává, že po přijetí tohoto chybového kódu by neměl klient nikdy poslat stejný požadavek znovu, protože je v něm chyba. Nejčastěji můžeme vidět kódy 400 Bad Request, 401 Unauthorized, 403 Forbidden, 407 Proxy Authentication Required a 486 Busy Here.
•
5xx – chyby na straně serveru, kvůli kterým není možné splnit požadavek. Nejčastější je 500 Internal Server Error. 7
2. Principy fungování VoIP telefonie •
6xx – globální chyby. Například 603 Decline (uživatel odmítl hovor) nebo 606 Not Acceptable (oba uživatelé se nedokázali shodnout na přijatelných parametrech spojení).
2.1.2 Protokol SDP Protokol SDP (Session Description Protocol) [3] se používá pro dohodu parametrů mediálního spojení mezi dvěma uzly v síti. Sám o sobě neposkytuje žádné prostředky pro vyhledání druhého účastníka, a proto se vkládá do těla zprávy protokolu SIP, který právě tuto chybějící funkcionalitu doplňuje. Příklad protokolu SDP je vidět na výpisu 2.3. Iniciátor spojení nabízí formou tohoto protokolu IP adresu a porty, na kterých očekává připojení druhého účastníka. Může nabídnout jedno nebo i více mediálních spojení (typicky audio a video relaci), ke každému uvádí zvlášť seznam portů a kodeky, které je schopen zpracovat. Oslovený počítač se po obdržení zprávy může připojit k příslušnému portu a posílat data kódovaná jedním z nabídnutých kodeků. v =0 o = - 1358677352 2 IN IP4 213.192.10.172 s = Ekiga /3.3.2 c = IN IP4 213.192.10.172 t =0 0 m = audio 5086 RTP / AVP 8 101 100 a = sendrecv a = rtpmap :8 PCMA /8000/1 a = rtpmap :101 telephone - event /8000 a = fmtp :101 0 -16 ,32 ,36 a = rtpmap :100 NSE /8000 a = fmtp :100 192 -193 a = maxptime :240 m = video 5090 RTP / AVP 31 b = AS :4096 b = TIAS :4096000 a = sendrecv a = rtpmap :31 h261 /90000 a = fmtp :31 CIF =1; QCIF =1
Výpis kódu 2.3: Ukázka protokolu SDP. Z ukázky je zřejmé, že se jedná opět o textový protokol s velmi jednoduchým formátem: Každý řádek obsahuje jeden atribut a jeho hodnotu oddělené znakem rovnítka. Hodnoty některých atributů (např. m) jsou složitější a obsahují více hodnot oddělených mezerou. Atribut v (version) obsahuje číslo verze protokolu, momentálně má vždy hodnotu nula. Atribut o (origin) 8
2. Principy fungování VoIP telefonie obsahuje informace o iniciátorovi spojení a je rozdělen na několik dílčích hodnot: o = < username > < sess - id > < sess - version > < nettype > < addrtype >
Výpis kódu 2.4: Struktura atributu o protokolu SDP. Username je přihlašovací jméno uživatele a v naší ukázce není uvedeno (hodnota -). Pole sess-id je řetězec, který má společně s ostatními poli tvořit jedinečný identifikátor spojení. Náš uživatelský agent použil pro identifikaci spojení aktuální čas. Význam pole sess-version je ponechán na autorovi konkrétní aplikace. Nettype představuje typ zdrojové sítě, IN znamená internet. Addrtype je označení typu adresy (IPv4 nebo IPv6) a IP je samozřejmě adresa iniciátora spojení. Atribut s (session name) obsahuje jméno uživatelského agenta, který spojení navazuje. V našem případě se jedná o program Ekiga. Pole c (connection data) obsahuje typ sítě, protokol a IP adresu, na které očekáváme připojení kontaktovaného uzlu. Jeho formát je obdobný jako v případě pole o, ale obsahuje jen položky nettype, addrtype a IP. V poli t (timing) je uveden čas začátku a konce mediální relace, což by mělo usnadnit uživatelským agentům plánování využití pásma. V praxi toto pole však zůstává často nevyplněno (hodnoty nula) i přesto, že to specifikace protokolu nedoporučuje. Z hlediska monitorování telefonních hovorů je nejdůležitější pole m (media descriptions), které definuje parametry nabízeného mediálního spojení. Má následující formát: m = < media > < port > < protocol > < codecs >
Výpis kódu 2.5: Struktura atributu m protokolu SDP. Media označuje typ dat, která očekáváme. Na výběr jsou následující možnosti: audio, video, text, application. V případě telefonních hovorů se samozřejmě setkáme pouze s prvními dvěma typy. Protocol je označením protokolu, který se použije pro přenos mediálních dat. Nejčastěji se používá protokol RTP popsaný v kapitole 2.1.3, který funguje jako rámec pro kódovaná mediální data. Posledním parametrem je seznam nabízených kodeků. Kodeky se nedefinují pomocí svých názvů, ale používají se jejich číselné kódy. Význam těchto číselných kódů je definován v normě [5]. Některé hodnoty mají pevný význam, zatímco jiné jsou definovány pro tzv. dynamické použití. Aby bylo možné zjistit, jaký kodek se skrývá pod dynamickým označením, je zapotřebí, aby iniciátor spojení explicitně uvedl jeho název. To může učinit po9
2. Principy fungování VoIP telefonie mocí atributu a (attributes), který slouží pro rozšíření protokolu. Pokud chceme uvést jméno kodeku, použijeme syntaxi uvedenou na výpisu 2.6. a = rtpmap : < payload_type > < encoding >/ < clock > [/ < parameters >]
Výpis kódu 2.6: Struktura atributu a protokolu SDP. Payload type je číselný identifikátor kodeku uvedený v atributu m, encoding je jeho slovní popis. Clock odpovídá požadované rychlosti vzorkování dat za sekundu (např. 8000 Hz). Poslední pole je závislé na konkrétním kodeku a není povinné. 2.1.3 Protokol RTP Protokol RTP (Real-time Transport Protocol) [4] se používá jako rámec, do kterého se vkládají multimediální data kódovaná příslušným kodekem. Tento protokol funguje nad protokolem UDP a nepoužívá žádné ustálené číslo portu. Port se alokuje dynamicky při navazování mediálního spojení, a jeho číslo se posílá druhému účastníkovi pomocí protokolu SDP. Protože se jedná o přenos dat v reálném čase, posílá se velké množství malých paketů v pravidelných intervalech. Časový rozestup těchto paketů je dán typem použitého kodeku a požadovanou kvalitou přenosu. Aby se co nejvíc uspořila šířka pásma, je nezbytné, aby hlavička protokolu RTP obsahovala opravdu jen nejnutnější údaje a režijní data se posílala jiným přenosovým kanálem (tím jsou protokoly SIP, SDP a RTCP). 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 V P X CC M PT sequence number timestamp synchronization source (SSRC) identifier contributing source (CSRC) identifiers ... Obrázek 2.1: Hlavička RTP paketu podle [4]. RTP je binární protokol a jeho základní hlavička má velikost 12 B. Obsahuje pole V, které označuje číslo verze a momentálně má vždy hodnotu 2. Nastavený bit P informuje o použití paddingu (tj. paket byl doplněn nulami tak, aby jeho délka byla násobkem 4 bytů). Příznak X indikuje skutečnost, že 10
2. Principy fungování VoIP telefonie za hlavičkou následuje právě jedno její rozšíření. V poli CC je uložena délka seznamu zdrojů, které přispívají do přenášených dat (CSRC). Pole M (Mark) nemá přesně dané využití a je ponecháno konkrétní aplikaci, která pomocí něho může například označovat důležité pakety apod. Z hlediska vyhodnocování kvality hovoru je významné pole PT (payload type), které udává identifikátor použitého kodeku. Seznam kodeků a jejich identifikačních čísel je možné najít v [5]. Neméně důležitým polem je sequence number (pořadové číslo zprávy), pomocí kterého lze snadno detekovat chybějící zprávu nebo seřadit pakety, které se během přenosu promíchaly. Pole SSRC (synchronization source) obsahuje 32bitový identifikátor zdroje dat, který náhodně zvolí vysílající. Komunikace protokolem RTP je jednosměrná, takže se při telefonním hovoru musí vytvořit dva RTP toky. Pokud uživatel požaduje videohovor, je zapotřebí vytvořit toky čtyři. Vzhledem k povaze přenášených dat nemá smysl přeposílat ztracené pakety. Během přenosu dat oba účastníci monitorují kvalitu hovoru a podávají zpětnou vazbu pomocí řídicího protokolu RTCP, který je popsán v následující kapitole. 2.1.4 Protokol RTCP Protokol RTCP (Real-time Transport Control Protocol) se používá pro řízení toku dat, která se přenášejí protokolem RTP. I přesto, že se jedná o zvláštní protokol, je s protokolem RTP velmi úzce spjat a dokonce je oba definuje stejný dokument [4]. Hlavním důvodem oddělení obou protokolů je snaha o maximální jednoduchost a minimální objem RTP paketů. Stejně jako protokol RTP nemá ani RTCP pevně definovaný přenosový port, nicméně zde platí jednoduchá konvence: Pokud se RTP data přenášejí portem číslo x, potom se RTCP data přenášejí pomocí portu x + 1. Protokol RTP využívá sudá čísla portů, zatímco RTCP komunikuje na lichých číslech. Protokol RTCP zajišťuje následující funkcionality: •
Poskytování informací o kvalitě hovoru a zábrana zahlcení sítě,
•
identifikace zdrojů RTP paketů a synchronizace přenosových kanálů,
•
zjištění celkového počtu účastníků komunikace,
•
poskytování dodatečných informací o spojení (volitelně).
Protokol RTCP používá několik typů zpráv, které mají shodnou počáteční hlavičku o délce 8 B (obrázek 2.2). Pole V obsahuje verzi protokolu (zatím vždy 2) a informaci o použití paddingu v bitu P. Počet obsažených 11
2. Principy fungování VoIP telefonie receiver reportů je uveden v poli RC, následuje typ zprávy (payload type) v poli PT a délka zprávy v poli length. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 V P X RC PT length Obrázek 2.2: Společná hlavička RTCP paketu podle [4]. Pro úsporu přenosové režie je možné vložit několik typů zpráv do jednoho paketu, čímž vznikne složený paket. Ve složeném paketu se nepoužívají žádné oddělovače, zprávy jsou naskládány jedna za druhou, což je možné díky informaci o délce zprávy, kterou obsahuje hlavička. Následuje seznam typů zpráv a jejich popis. SR (Sender report) Zpráva obsahuje identifikátor původce dat (SSRC of sender), časové značky potřebné pro synchronizaci příjemců (NTP timestamp, RTP timestamp) a dále počet odeslaných paketů (Sender’s packet count) a bajtů (Sender’s ocetet count), podle něhož si mohou příjemci zkontrolovat, kolik dat se během přenosu ztratilo. Za údaji o odeslaných datech následují statistiky dat přijatých, tzv. receiver reporty. V případě telefonního hovoru zpráva obsahuje většinou jen jediný report, který podává informace o kvalitě dat přicházejících od druhého účastníka. Pokud se jedná o hovor konferenční, může být ve zprávě reportů více. Pokud účastník data pouze odesílá, je tato sekce prázdná. Při monitorování kvality hovoru pro nás může být velmi užitečné měřit počet skutečně přenesených paketů a porovnávat jej s polem Sender’s packet count. Dalšími užitečnými metrikami jsou například rozptyl a počet ztracených paketů, o kterých bude řeč v následující kapitole. RR (Receiver report) Zprávy typu receiver report odesílají všichni účastníci RTP komunikace, kteří do sítě neposílají žádná RTP data. Příkladem takových účastníků mohou být posluchači telekonference nebo dva uživatelé provozující videohovor, z nichž pouze jeden má webkameru. Struktura zprávy je velice podobná zprávě typu sender report, pouze neobsahuje informace o odeslaných datech (tj. druhý 12
2. Principy fungování VoIP telefonie 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 V P X RC PT=SR=200 length SSRC of sender NTP timestamp, most significant bits NTP timestamp, least significant bits RTP timestamp Sender’s packet count Sender’s octet count SSRC_1 of first source Fraction lost Cumulative number of packets lost Extended highest sequence number received Interarrival jitter Last SR Delay since last SR (DSLR) SSRC_2 of second source ... Obrázek 2.3: Zpráva typu sender report protokolu RTCP (převzato z [4]).
blok na obrázku 2.5). Tato kapitola se věnuje pouze vybraným polím z části receiver report, zbytek informací je možné najít v kapitole 2.1.4. O počtu ztracených paketů informují pole Fraction lost a Cumulative number of packets lost. První z nich udává podíl ztracených a očekávaných paketů od posledního reportu vyjádřený jako číslo v rozsahu 0 – 255, zatímco druhá hodnota obsahuje celkový počet ztracených paketů od začátku komunikace. Při diagnostice fungování sítě může být zajímavé právě druhou zmíněnou hodnotu porovnat s vlastním měřením, což může pomoci při hledání místa, kde se ztrácejí pakety. Pole Extended highest sequence number received obsahuje poslední dosud přijaté pořadové číslo paketu. Je užitečné zejména pro odesílatele dat, který na základě něho může například znovu odeslat klíčový snímek videa apod. Interarrival jitter je průměrná odchylka příchodu RTP paketů, tj. jak hodně se liší skutečné časy příchodu paketů od těch očekávaných. Udává se jako celé číslo v jednotkách RTP hodin (jejich perioda závisí na použitém 13
2. Principy fungování VoIP telefonie kodeku). Výpočet hodnoty se provádí podle [4] následovně: Pro každé dva po sobě příchozí RTP pakety i a j se nejprve stanoví rozdíl D na základě časové známky paketu Si a skutečného příchodu paketu Ri:
D(i, j) = (Rj − Ri) − (Sj − Si) = (Rj − Sj) − (Ri − Si)
(2.1)
Získaný výsledek se přičte k celkovému průměru následovně: J(i) = J(i − 1) +
|D(i − 1, i)| − J(i − 1) 16
(2.2)
Při sledování kvality hovoru je užitečné měřit rozptyl RTP paketů na mezilehlém uzlu v síti a porovnávat jej s hodnotami získanými v koncových uzlech. Postup měření je stejný jako na koncovém uzlu, jedinou komplikací může být zjištění převodního vztahu mezi skutečným časem příchodu paketu a RTP hodinami, který je nezbytný pro korektní odečtení hodnot Ri a Si ve vztahu 2.1. Perioda RTP hodin je totiž závislá na použitém kodeku a většinou odpovídá například rychlosti vzorkování posílaného signálu. Protože mezilehlý uzel periodu RTP hodin nezná, je zapotřebí ji určit na základě použitého kodeku, který je uvedený v poli PT (payload type) v hlavičce každého RTP paketu. Například pokud má pole PT hodnotu 8, zjistíme podle tabulky kodeků [5], kterou vydává společnost IANA, že se jedná o kodek PCMA, jenž používá vzorkovací frekvenci 8000 Hz. Periodou RTP hodin je 1 převrácená hodnota frekvence, tedy 8000 s. Receiver report končí poli Last SR a Delay since last SR. První z nich obsahuje časovou známku posledního obdrženého sender reportu, zatímco ve druhém je uvedena prodleva mezi přijetím posledního sender reportu a odesláním tohoto receiver reportu. SDES (Source description) Zpráva typu source description přenáší bližší informace o zdroji RTP dat. Může se jednat jak o hlavní zdroj dat (synchronization source), tak i o zdroj, který jen přispívá daty hlavnímu zdroji (contributing source). Ve zprávě může být nula nebo více popisovačů a jejich počet je uveden v hlavičce, konkrétně v poli SC. Každý popisovač zdroje se skládá z identifikátoru zdroje (pole SSRC/CSRC) a libovolného počtu polí s popisem zdroje (SDES items). Každá položka popisovače začíná svým osmibitovým kódem (pole type) a délkou (pole length). Pak už následují samotná data. 14
2. Principy fungování VoIP telefonie 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 V P SC PT=SDES=202 length CNAME=1 EMAIL=3
SSRC/CSRC_1 length user and domain name length email address ... SSRC/CSRC_2 SDES items ...
Obrázek 2.4: Zpráva typu SD protokolu RTCP (převzato z [4]). 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 type length data Obrázek 2.5: Pole SDES protokolu RTCP (převzato z [4]).
Norma definuje mimo jiné pole pro uložení textového označení zdroje (type = 1), uživatelského jména (type = 2), emailu (type = 3), telefonu (type = 4) a zeměpisných souřadnic (type = 5). Typ číslo 8 je ponechán pro využití v závislosti na aplikaci. I přesto, že protokol RTCP může přenášet poměrně zajímavé informace o zbylých účastnících hovoru, většina komunikačních programů upřednostňuje popisné informace, které poskytuje protokol SIP (například jméno volajícího apod.). Některé VoIP telefony dokonce neposílají SDES zprávy vůbec a nebo je nechávají prázdné. Hlavním důvodem je patrně fakt, že SIP spojení se navazuje dříve než spojení RTP, a proto přicházejí informace z protokolu RTCP až v době, kdy už nejsou potřeba.
BYE Zpráva typu BYE informuje to tom, že jeden nebo více účastníků přestává být aktivní. Za ustálenou hlavičkou následuje seznam zdrojů, kterých se zpráva týká. Volitelně je možné udat i důvod ukončení spojení. 15
2. Principy fungování VoIP telefonie APP Zpráva typu APP nemá definován žádný pevný význam a její využití je ponecháno na konkrétní aplikaci. Za ustálenou hlavičkou následuje pole SSRC označující zdroj dat a name označující jméno aplikace.
2.2
Průběh telefonního hovoru řízeného protokolem SIP
Navazování telefonního hovoru se provádí prostřednictvím protokolu SIP a probíhá v několika krocích. Jak již bylo dříve řečeno, protokol SIP slouží k nalezení druhého účastníka hovoru a dohodě parametrů přenosu dat. Samotný hlas se přenáší zvláštním datovým kanálem, typicky pomocí protokolu RTP. Konkrétní sled zpráv protokolu SIP závisí na tom, zda navazujeme hovor přímo a nebo přes proxy server. SIP proxy může navíc přenášet buď jen signální nebo signální i hlasová data. Ve většině případů probíhá telefonní hovor podle jednoho z následujících scénářů: •
Přímé spojení – nejjednodušší, nicméně nejméně používaná varianta. Navazování spojení probíhá přímo mezi dvěma účastníky, SIP proxy ani registrar servery se zde nepoužívají. Je nutné, aby volající znal IP adresu volaného a tato adresa mu byla přímo dostupná (např. veřejná IP adresa v internetu nebo privátní IP adresa ve stejné síti).
•
Signalizace přes proxy nebo registrar server – parametry telefonního hovoru se domlouvají za účasti SIP registrar/proxy serverů, samotný telefonní hovor se přenáší přímo mezi oběma účastníky (viz obrázek 2.6). S touto variantou primárně počítá dokument RFC 3261 [2], který definuje SIP.
•
Úplné spojení přes proxy server – veškerá komunikace probíhá přes SIP proxy server. To odstraňuje problémy s procházením NATu a na základě provedených měření se jedná o dnes nejpoužívanější schéma.
V následujícím textu bude postupně představen způsob navázání hovoru tak, jak jej definuje RFC 3261 [2], později se budu věnovat nedostatkům tohoto přístupu a vysvětlím, jak v současné době používá protokol SIP většina VoIP poskytovatelů. 16
2. Principy fungování VoIP telefonie 2.2.1 Hovor podle RFC 3261 Obrázek 2.6 ukazuje průběh hovoru mezi Alicí a Bobem. Přenášená data jsou označena šipkami, u každé z nich je uvedeno pořadové číslo a název zprávy, která se přenáší. Předtím, než je možné začít telefonovat, musí se oba účastníci přihlásit k registrar serveru svého poskytovatele (na obrázku jsou znázorněny SIP proxy, které mimo jiné plní také funkci registrar serverů). To se provede posláním zprávy REGISTER. Registrar odpovídá 200 OK a ukládá si IP adresu a port, ze kterého přišel požadavek (zná aktuální polohu uživatele). Samotný hovor začíná zprávou INVITE, kterou posílá Alice na svou proxy. Ve zprávě je napsáno mimo jiné SIP URI volaného účastníka, v našem případě [email protected]. Za hlavičkou SIP zprávy následuje protokol SDP, který popisuje parametry nabízeného spojení. Je zde uveden zejména port a IP adresa, na kterých Alice očekává mediální data od Boba, a dále seznam kodeků, které podporuje Alicin telefon. SIP proxy odpoví stavovým kódem 100 Trying a provede lokalizaci účastníka podle následujícího postupu: •
Pokud je v SIP URI napsáno cizí doménové jméno, předá se zpráva příslušné SIP proxy.
•
Pokud doménové jméno v SIP URI patří této proxy a před zavináčem je platné jméno uživatele této proxy, pak se kontaktuje tento uživatel.
•
Pokud doménové jméno v SIP URI patří této proxy a před zavináčem je platné telefonní číslo, přepojí se hovor do analogové telefonní sítě (pokud SIP proxy tuto funkci podporuje).
•
Jinak hovor skončí s chybou 404 Not Found.
V našem případě proxy zvolí první variantu, pomocí DNS serveru (není na obrázku) získá IP adresu proxy fayn.cz a přepošle jí zprávu INVITE. Do hlavičky zprávy přidá pole Via, do kterého uvede svou IP adresu a port. Díky této informaci se bude moci požadavek vrátit stejnou cestou zpět. Proxy fayn.cz odpoví opět stavovým kódem 100 Trying a pokusí se lokalizovat volaného účastníka. Protože SIP URI obsahuje její doménové jméno a Bob je jejím platným uživatelem, přepošle mu zprávu, do níž i ona vloží pole Via se svou IP adresou a portem. Bobovu IP adresu zná proxy z požadavku REGISTER, který Bob již dříve poslal. Bobův počítač přijímá zprávu INVITE a protože je jejím adresátem, odpoví stavovým kódem 180 Ringing a na displeji zobrazí zprávu o příchozím hovoru. Dříve než si Bob vůbec všimne příchozího volání, přepošle Bobova 17
2. Principy fungování VoIP telefonie SIP proxy ustredna.mikrotech.cz
SIP proxy sip.fayn.cz
5. INVITE [email protected] 6. 100 Trying 9. 180 Ringing 12. 200 OK
.
OK
20 0
10
13 .
ng
18 0
Ri
ng in g
yn .c z
yi
fa
Tr
bo b@
0 10
VI TE
IN 3.
z .c yn
4.
OK
GI S
2.
RE
R
TE
OK
S GI
RE
4.
g in
fa
OK
ng
b@ bo
Ri
0 20
1.
3.
TE VI IN
0
.
18
11
TE R
7. 8.
14. ACK 15. Přenos hlasu pomocí RTP 16. BYE 17. OK
Alice 212.158.128.3
Bob 213.29.17.65
Obrázek 2.6: Průběh telefonního hovoru podle RFC 3261 [2] SIP proxy stavový kód 180 Ringing Alici (přes její proxy), takže Alice vidí, že Bobovi začal vyzvánět telefon, a čeká, až Bob přijme hovor. Po přijetí hovoru odesílá Bobův počítač stavový kód 200 OK, který signalizuje začátek hovoru. Součástí této SIP zprávy jsou také data protokolu SDP (podobně jako u zpávy INVITE), v nichž Bobův počítač informuje o IP adrese a portu, na nichž očekává mediální data. Zpráva se okamžitě přepošle Alici stejně jako předchozí stavové kódy. Alice potvrzuje přijetí stavové zprávy metodou ACK, na kterou Bobův počítač odpovídá 200 OK. Na rozdíl od předchozích zpráv se zpráva ACK již neposílá přes SIP proxy. Oba účastníci totiž už vzájemně znají svou aktuální polohu. Předali si ji ve zprávách SIP tak, že v hlavičce uvedli pole Contact se svou aktuální IP adresou a portem. Po odeslání zprávy ACK se začínají přenášet hlasová data prostřednictvím protokolu RTP mezi IP adresami a porty, které si Alice a Bob dohodli během navazování spojení prostřednictvím protokolu SDP. Hovor končí ve chvíli, kdy jeden z účastníků pošle zprávu BYE. V našem případě tak učiní Alice. Bobův počítač odpovídá stavovým kódem 200 OK a přestává posílat hlasová data. Při ukončení přenosu dat protokolem RTP se posílá také řídicí zpráva BYE protokolem RTCP. 18
2. Principy fungování VoIP telefonie Výše uvedený postup bohužel počítá se skutečností, že Alice i Bob disponují veřejnou IP adresou, což v praxi platí jen málokdy (alespoň v rámci dnes nejvíce používaného protokolu IP verze 4). Díky nutnosti použití veřejných adres se můžeme snadno dostat do situace, kdy se hlasová data posílají korektně jen jedním směrem a nebo se zvuk nepřenáší vůbec. 2.2.2 Problémy způsobené překladem IP adres Aby se podařilo korektně navázat telefonní hovor za použití postupu popsaného v předchozí kapitole, musí oba účastníci vzájemně znát svou IP adresu a port, na němž očekávají příchozí data. Problém může nastat ve chvíli, kdy v síti dochází na mezilehlých směrovačích k nějakým úpravám IP adres a portů v hlavičkách paketů. Nejčastěji se můžeme setkat s tzv. NATem (Network Address Translation), který maskuje za jednu veřejnou IP adresu celou podsíť počítačů s privátními adresami. IP adresa koncového uživatele se přenáší nejen v hlavičce SIP paketu, ale také v datech protokolu SDP. Drtivá většina směrovačů přepíše IP adresu pouze v hlavičce paketu a druhému účastníkovi hovoru tak přijde v protokolu SDP nesmyslná informace, která odkazuje na privátní IP adresu. Na první pohled se může zdát, že by stačilo, aby uživatel ve svém telefonu nastavil jeho veřejnou IP adresu a telefon by ji pak posílal v protokolu SDP místo té privátní. Bohužel stejným způsobem, jako se překládají IP adresy, se mohou měnit i porty. V závislosti na konfiguraci sítě se může toto mapování navíc v čase měnit. Určitým východiskem může být dynamické zjištění aktuální veřejné IP adresy a portu, nicméně ani toto řešení nefunguje na všech typech NATu správně. Z důvodu nedostatečného množství IP verze 4 adres je NAT běžný u velké části tuzemských i zahraničních poskytovatelů internetu, a proto je zapotřebí zajistit, aby se hovor úspěšně navázal i za jeho použití. V následujících kapitolách se budu věnovat řešení problémů spojených s překladem IP adres a portů. Hlavní myšlenky, které se chystám prezentovat, vychází z článku NAT Traversal in SIP [6]. Používané typy NATu V praxi se používají celkem čtyři typy NATu. Všechny mají stejný účel – tj. mapovat privátní IP adresy na jednu nebo více veřejných IP adres. Mapování se provádí tak, že hraniční směrovač přepíše u odchozích paketů zdrojovou adresu na svou vlastní IP adresu a případně změní i číslo zdrojového portu (například pokud dvě stanice za NATem používají stejný zdrojový port). 19
2. Principy fungování VoIP telefonie Poté si do své interní tabulky uloží (nový) zdrojový port a k němu odpovídající privátní IP adresu a port. Díky této tabulce je schopen u příchozích paketů přepsat v hlavičce IP adresu a port na původní hodnoty a paket přeposlat příslušné stanici v privátní síti. Níže uvedené typy NATu se liší především v omezeních, která se týkají přeposílání příchozích zpráv do privátní sítě: •
Plný kužel – Provádí pouze mapování IP adres a portů a neklade žádná omezení přístupu. Jak je vidět na obrázku 2.7, pokud počítač za NATem s IP adresou 10.0.0.1 vyšle požadavek z portu 8000, dorazí k serveru B jako paket s IP adresou 202.123.211.25 a portem 12345. Pokud zná libovolný počítač v internetu toto aktuální mapování (na obrázku počítač A), může poslat data klientovi za NATem na IP adresu 202.123.211.25 a port 12345. Směrovač mapování portu 12345 používá tak dlouho, dokud přes něj chodí data. Pokud port přestane být aktivní, je po vypršení časového limitu (řádově minuty) odstraněn z mapovací tabulky. Počítač A IP: 222.111.99.1 Port: 20202
NAT Klient IP: 10.0.0.1 Port: 8000
IP: 202.123.211.25 Port: 12345
Počítač B IP: 222.111.88.2 Port: 10101
Obrázek 2.7: NAT typu Plný kužel [6] •
Omezený kužel – Provádí mapování stejně jako plný kužel, ale do vnitřní sítě přeposílá jen pakety přicházející od počítačů v internetu, které dříve kontaktoval klient ve vnitřní síti. Například počítač 10.0.0.1 na obrázku 2.7 kontaktoval počítač B, čímž se vytvořilo mapování portu 8000 na port 12345 pro počítač B. Ten může posílat klientovi za NATem data na IP adresu 202.123.211.25 a port 12345. Na rozdíl od plného kuželu, pokud na tu samou adresu a port pošle data počítač A, nebudou doručena. Pokud by chtěl klient přijímat data i od počítače A, musel by mu nejprve nějaká data sám poslat, čímž by se vytvořilo mapování i pro počítač A.
•
Kužel omezený na porty – Funguje velmi podobně jako Omezený kužel, nicméně mapování se nevytváří nejen pro konkrétní počítač
20
2. Principy fungování VoIP telefonie v internetu, ale také pro konkrétní port. Pokud pošle klient na obrázku 2.7 data počítači A na port 80, musí mu počítač A odpovědět přímo ze zdrojového portu 80. Pokud pošle data z jiného portu, nebudou doručena (podobně jako data od jiných počítačů v případě Omezeného kuželu). Pokud chce klient přijímat data z více portů počítače A, musí mu poslat na každý port zvláštní požadavek, kterým „otevře NAT“. •
Symetrický NAT – U předchozích třech typů NATu se pro jeden odchozí port klienta vytvořilo právě jedno mapování privátního portu na veřejný. Pokud klient posílal z jednoho portu požadavky na více serverů, všechny servery zasílaly odpovědi na stejný veřejný port. V případě NATů typu Omezený kužel a Kužel omezený na porty se navíc povolovaly další příchozí adresy resp. porty. Symetrický NAT se liší v tom, že pro každé spojení vytváří zvláštní mapování portů. Například pokud klient na obrázku 2.8 vytvoří z jednoho portu spojení se dvěma servery, bude serveru A přidělen veřejný port 45678 a serveru B veřejný port 12345. Zároveň platí stejná omezení jako u NATu typu Kužel omezený na porty, tj., každý server může používat jen veřejný port, přes který mu klient dříve poslal nějaká data. IP: 202.123.211.25 Port: 45678
Počítač A IP: 222.111.99.1 Port: 20202
NAT Klient IP: 10.0.0.1 Port: 8000
IP: 202.123.211.25 Port: 12345
Počítač B IP: 222.111.88.2 Port: 10101
Obrázek 2.8: Symetrický NAT [6]
Protokol SIP a procházení NATu Protokol SIP nemá většinou s procházením NATu problémy, neboť SIP proxy (podobně jako každá jiná veřejná služba na internetu) má veřejnou IP adresu. Pro správnou funkci protokolu stačí, aby SIP proxy poslala odpověď na stejnou adresu a port, odkud požadavek přišel. Díky tomu se paket dokáže vrátit i do sítí s NATem typu Kužel omezený na porty nebo do sítí se symetrickým NATem (viz kapitola 2.2.2). Jak již bylo řečeno v kapitole 2.2.2, mapování portů na směrovači provádějícím NAT se může v čase měnit. To může způsobovat problémy s přícho21
2. Principy fungování VoIP telefonie zími hovory, neboť SIP proxy má uloženu aktuální IP adresu a port každého uživatele, aby ho mohla v případě potřeby kontaktovat. Pokud se mapování IP adresy nebo portu změní (případně zmizí) bez vědomí SIP proxy, nebude možné informovat uživatelského agenta o příchozím hovoru. Proto většina uživatelských agentů podporuje zasílání tzv. keepalive paketů, které mají mapování NATu udržet. Keepalive paket může být libovolná SIP zpráva (typicky zpráva REGISTER), která se odesílá v pravidelných časových intervalech na SIP proxy. Díky tomu směrovač ví, že se mapování příslušného portu stále používá, a nevymaže ho z paměti ani po desítkách hodin provozu. Dalším důležitým mechanismem průchodu NATu jsou pole Via v hlavičce SIP požadavku. Když uživatelský agent vytváří SIP zprávu, vloží do ní jedno pole Via se svou aktuální IP adresou a portem. Pokud je za NATem, pak vkládá svou privátní IP adresu. Každá proxy, přes kterou požadavek prochází, provádí dva úkony: •
Do posledního pole Via přidá tagy received a rport, do kterých uvede skutečnou IP adresu a port, z nichž jí požadavek přišel.
•
Přidá nové pole Via, do kterého uvede svou vlastní IP adresu a port.
Díky polím Via se může vrátit odpověď na SIP požadavek stejnou cestou zpátky a navíc uživatelský agent zjistí z tagů v poli Via svou IP adresu a port tak, jak je vidí jeho nejbližší SIP proxy. Díky tomu může v příštích požadavcích uvádět správnou IP adresu a port (zejména v poli Contact, které slouží k přímému kontaktování uživatelského agenta). Jedinou nevýhodou tohoto řešení je fakt, že tagy received a rport nejsou normou přímo vyžadovány a některé starší SIP proxy je nepoužívají. Vyplňování těchto tagů může částečně vynutit uživatelský agent tak, že do pole Via přidá prázdný tag rport, ale ne vždy je to respektováno. Naštěstí je používání těchto starých SIP proxy na ústupu a zejména u komerčních VoIP poskytovatelů se může uživatel spolehnout na to, že signalizace protokolem SIP bude fungovat bez problémů i za symetrickým NATem. Protokol RTP a procházení NATu Zatímco protokol SIP funguje za NATem většinou bez problémů, u protokolu RTP je situace mnohem komplikovanější. Je totiž zapotřebí navázat peerto-peer spojení a pokud jsou oba účastníci za NATem, nemusí mít tento problém vůbec řešení. 22
2. Principy fungování VoIP telefonie Při navazování spojení se v těle zprávy INVITE posílá protokolem SDP IP adresa a port, na kterých očekává účastník příchozí hlasová data. Aby bylo možné doručit tato data skrz NAT, je zapotřebí, aby •
účastník sdělil svému protějšku platnou veřejnou IP adresu a port,
•
otevřel NAT tak, aby se k němu příchozí data skutečně doručila.
U některých uživatelských agentů je možné zadat rozsah portů, které mají používat pro příchozí hlasová data. To je užitečné v případě komplikací, protože správce sítě může nastavit směrovač tak, aby daný rozsah portů vždy přeposílal příslušnému VoIP zařízení. Díky tomu není nutné otevírat NAT a porty se mapují 1 : 1. I když toto nastavení často velmi spolehlivě vyřeší problémy s nefunkčním přenosem zvuku, nelze jej použít vždy – například uživatel nemusí mít přístup k nastavení směrovače a nebo si přeje používat VoIP telefon v dané síti jen dočasně a nechce proto měnit její konfiguraci. Ve zbytku textu proto budeme předpokládat, že přeposílání portů na směrovači nemůžeme změnit, a že se porty pro příchozí RTP data volí automaticky, náhodně. V tomto případě je nutné před každým hovorem zjistit, jakou má uživatelský agent veřejnou IP adresu, a jak nastavil hraniční směrovač mapování náhodně zvoleného portu. Do těla zprávy INVITE se poté napíše veřejná IP adresa a port, na který směrovač namapoval privátní port uživatelského agenta. Zjištění veřejné IP adresy je poměrně jednoduché – lze ji získat od SIP proxy, která ji ukládá do tagu received, nebo se zjistí pomocí serveru STUN (Simple Traversal Utilites for NAT), případně ji uživatel zadá ručně. Mnohem složitější je zjištění veřejného portu. Zde se nabízí dvě možnosti: •
zeptat se směrovače, jak bude port mapovat,
•
zeptat se serveru v internetu, jakou vidí zdrojovou adresu a port u požadavku vyslaného uživatelským agentem.
Některé směrovače podporují protokol UPnP (Universal Plug and Play), kterým se může stanice za NATem dotázat, jak se bude mapovat port, na kterém očekává příchozí data. Nevýhodou tohoto řešení je malá rozšířenost podpory protokolu UPnP a zejména fakt, že se na cestě může vyskytovat několik NATů kaskádovitě za sebou. Například pokud poskytovatel internetu používá NAT, aby nemusel dávat všem zákazníkům veřejné IP adresy, a zároveň i samotný zákazník používá domácí router s NATem, aby mohl rozvést jednu internetovou přípojku do více počítačů v domácnosti. Většinou je proto nutné použít druhou metodu a dotázat se na veřejnou IP adresu a port nějakého serveru v internetu. 23
2. Principy fungování VoIP telefonie Principiální schéma dotazu na mapování veřejného portu je znázorněno na obrázku 2.9. Dříve než Alice pošle Bobovi zprávu INVITE obsahující mimo jiné IP adresu a port, na nichž očekává zvuková data od Boba, pošle dotaz NAT sondě, která se nachází ve veřejném internetu (má svou veřejnou IP adresu). Dotaz vychází z portu 3070, který alokoval operační systém Alicina počítače jejímu uživatelskému agentovi pro přenos zvuku. Dotaz prochází skrz hraniční směrovač, který přepisuje jeho IP adresu a port, a k NAT sondě se dostává jako paket se zdrojovou IP adresou 202.123.211.25 a portem 61053. NAT sonda posílá zpět odpověď, do níž napíše zdrojovou IP adresu a port odkud jí přišel požadavek. Díky tomu Alice ví, jak se její privátní IP adresa a port zobrazují světu, a posílá Bobovi zprávu INVITE. Do těla zprávy (protokol SDP) zapisuje IP adresu a port, které obdržela od NAT sondy.
IP: 202.123.211.25 Port: 61053
NAT sonda
Veřejný internet Alice IP: 10.0.0.1
3070
NAT INVITE 61053
5060
IP: 202.123.211.25 Port: 5091
Bob IP: 222.111.88.2 Port: 10101
Obrázek 2.9: Princip zjištění veřejného portu podle [6] Obrázek 2.9 také ukazuje zjednodušený princip činnosti protokolu STUN (Simple Traversal Utilities for NAT), který používá řada SIP klientů pro detekci veřejné adresy a portu. NAT sonda použitá v našem příkladu je zjednodušeným modelem STUN serveru, který zpravidla obsahuje alespoň dvě síťová rozhraní s veřejnými IP adresami nebo je implementován jako dva oddělené servery, které spolupracují. Za použití STUN serveru může Alice pomocí nejvýše 4 dotazů zjistit nejen svou veřejnou IP adresu a port, ale také typ NATu, za kterým se nachází. Toho se docílí tak, že se ptá na obou IP adresách STUN serveru a pak porovnává odpovědi, které dostala. Například pokud jí každá IP adresa STUN serveru vrací jiný veřejný port na dotaz odeslaný ze stejného privátního portu, je jasné, že se nachází za symetrickým NATem (viz kapitola 2.2.2). Pokud uživatelský agent zjistí veřejnou IP adresu a port pomocí STUN serveru, bude přenos zvuku probíhat korektně za splnění následujících podmínek: 24
2. Principy fungování VoIP telefonie •
klient musí posílat a přijímat RTP data na stejném portu,
•
klient musí odeslat SIP zprávu krátce po provedení STUN dotazu, jinak se může změnit mapování portů,
•
v případě, že je klient za NATem typu Omezený kužel nebo Kužel omezený na porty, musí odeslat nejdříve nějaká data druhému účastníkovi, čímž otevře NAT.
Zejména třetí podmínka si zaslouží bližší rozbor: už samotným STUN dotazem se nastaví mapování portů na hraničním směrovači. Například na obrázku 2.9 si hraniční směrovač nastavil mapování portu 3070 na port 61053. Pokud však použitý typ NATu klade omezení na IP adresy nebo dokonce porty (viz kapitola 2.2.2), je zapotřebí poslat alespoň jeden paket také účastníkovi, od kterého se chystáme přijímat data, jinak NAT doručí pouze data od STUN serveru. V našem příkladu by tedy musela Alice poslat před zprávou INVITE ještě jednu zprávu z portu 3070 Bobovi, čímž by se otevřel NAT i pro něho. Obsah této zprávy není důležitý, například SIP klient Ekiga posílá před začátkem RTP komunikace prázdný paket. Pokud by Alice tento krok neučinila, začala by přijímat data od Boba až ve chvíli, kdy by mu nějaká data sama poslala (tím by se otevřel NAT). Bohužel ani za použití STUN serveru nemáme úplnou jistotu, že se podaří přenést zvukový signál bez problémů. Výše uvedené řešení totiž nefunguje na symetrickém NATu. Jak již bylo řečeno v kapitole 2.2.2, symetrický NAT alokuje pro každou cílovou IP adresu jiný port. Na obrázku 2.9 mapuje směrovač port 3070 pro IP adresu NAT sondy na port 61053. Pokud by tento směrovač prováděl symetrický NAT, bylo by mapování tohoto portu pro Bobovu IP adresu jiné. Při použití modelové NAT sondy by Alice o existenci symetrického NATu nevěděla a poslala by Bobovi port, který jí sdělila NAT sonda. Bob by posílal data na port, který je mapován pouze pro NAT sondu a směrovač by tato data zahazoval. Při použití STUN serveru by Alice sice zjistila, že je za symetrickým NATem, nicméně by stejně neměla žádné další prostředky (mimo UPnP), jak by mohla zjistit správné mapování portů. Connection oriented media Connection oriented media je alternativní způsob řešení problému s procházením NATu. Na rozdíl od řešení uvedených v předchozí kapitole se volající nesnaží za každou cenu zjistit mapování IP adresy a portu, na kterých bude 25
2. Principy fungování VoIP telefonie očekávat připojení partnera, nýbrž sám se ujímá navazování spojení a posílá data svému partnerovi jako první, čímž zajistí otevření NATu. Volaný účastník ignoruje IP adresu a port, které mu přišly v protokolu SDP, a místo nich očekává příchod prvního RTP paketu. Kvůli snazšímu procházení NATu se drží všichni uživatelští agenti jednoduché konvence – odesílají RTP data z portu, na kterém očekávají RTP data z opačného směru. Díky této konvenci zjistí uživatelský agent volaného účastníka hned z prvního RTP paketu, kam má posílat data v opačném směru – tj. na IP adresu a port, které jsou v příchozím RTP paketu uvedeny jako zdrojové. Navíc díky použití stejných čísel portů není třeba otevírat NAT (o to se postaral již zmiňovaný první příchozí RTP paket). Aby tento postup fungoval, musí být splněny dvě podmínky: •
druhý účastník musí vědět, že má ignorovat IP adresu a port uvedené v protokolu SDP,
•
druhý účastník nesmí použít stejný způsob navázání spojení.
Aby uživatelský agent věděl, že má ignorovat informaci uvedenou v protokolu SDP, měl by se v protokolu SDP uvést atribut a=direction:active. Bohužel zdaleka ne všichni uživatelští agenti toto podporují. Další možností je poslat protokolem SDP nulovou IP adresu a port, díky čemuž druhému účastníkovi nezbude nic jiného, než čekat na spojení, pokud to podporuje. Tato metoda navazování spojení samozřejmě nefunguje v případě, kdy oba účastníci čekají na to, až se připojí ten druhý. Proto je zapotřebí ji používat jen v nutných případech, zejména když uživatelský agent zjistí, že se nachází za symetrickým NATem. V případě, že se za symetrickým NATem nachází oba účastníci, je tato metoda nepoužitelná. RTP relay RTP relay je internetový server, který zprostředkovává přenos hlasových dat podobně, jako SIP proxy přenáší data signalizační. RTP relay slouží jako prostředník mezi dvěma účastníky, kteří se například díky symetrickým NATům na obou stranách nejsou schopni spojit přímo. Hlavní výhodou RTP relay je veřejná IP adresa, ke které se mohou oba uživatelští agenti snadno připojit a odesílat zvuková data. Pokud se uživatelskému agentovi podaří zjistit veřejnou IP adresu a mapování RTP portu, může uvést tuto informaci v protokolu SDP. RTP relay se k němu připojí a začne mu posílat hlasová data. Pokud se mu to nepodaří, může použít metodu Connection oriented media probranou v předchozí kapitole. Tato metoda funguje vždy, neboť má 26
2. Principy fungování VoIP telefonie RTP relay veřejnou IP adresu. Aby se vytvořilo spojení přes RTP relay, je zapotřebí •
požádat RTP relay o přidělení portů pro hovor,
•
do protokolu SDP uvést přidělený port a IP adresu RTP relay místo svých vlastních.
O obě výše zmíněné funkce se stará většinou SIP proxy, která bývá s RTP relay velmi úzce spjata. Ukázka telefonního hovoru za použití RTP relay je vidět na obrázku 2.10: Alice i Bob používají symetrický NAT, a proto se jejich hovor uskuteční s pomocí RTP relay serveru. Alice posílá zprávu INVITE, v níž uvádí svou privátní IP adresu a port. Její SIP proxy se rozhodne použít RTP relay (například na základě toho, že Alice nabízí pro příchozí data neroutovatelnou IP adresu), a proto posílá žádost RTP relay o vytvoření hovoru. RTP relay vytváří nový hovor a v odpovědi posílá porty 4021 a 4022 vyhrazené pro přenos zvuku. Alicina SIP proxy (ustredna.mikrotech.cz) vkládá vyhrazený port a IP adresu RTP relay do zprávy INVITE namísto původní privátní IP adresy 10.0.0.1 a portu 3000. SIP proxy ustredna.mikrotech.cz
IP: 202.123.211.25 Port: 5062
INVITE 10.0.0.1/3000 Alice IP: 10.0.0.1
5060
200 OK 212.1.2.3/4021
SIP proxy sip.fayn.cz
Setup session OK, 4021, 4022
NAT RTP
3000
INVITE 212.1.2.3/4022
3123
4021
RTP relay IP: 212.1.2.3
IP: 213.128.1.25 Port: 5068
NAT RTP 4022 3873
5060 3700
200 OK 10.1.0.3/3700 Bob IP: 10.1.0.3
Obrázek 2.10: Princip činnosti RTP relay Když zpráva dorazí k Bobovi, vidí v ní port 4022 a IP adresu RTP relay. Oba údaje jsou platné a Bob na ně může začít posílat hlasová data. Bob přijímá hovor a posílá Alici stavový kód 200 OK. I Bob nabízí pro připojení svou privátní IP adresu a port 3700, který po průchodu NATem již nebude platný. Stavová zpráva dojde až k Alicině SIP proxy, která změní její obsah a v protokolu SDP nahradí Bobovu privátní IP adresu a port údaji, které odpovídají RTP relay. Takto změněná zpráva dojde k Alici a hovor může začít. Dejme tomu, že Alice se připojuje k RTP relay první a posílá jí zvuková data pro Boba. RTP relay zatím nezná Bobovu adresu, a proto data pro Boba zahazuje nebo je krátkodobě ukládá do bufferu. Ve chvíli, kdy se připojí Bob, 27
2. Principy fungování VoIP telefonie RTP relay zjistí jeho IP adresu a mapování portů a začne mu přeposílat data od Alice. Stejně tak je možné začít okamžitě posílat hlasová data od Boba Alici, protože RTP relay už zná její IP adresu a mapování portů. RTP relay tedy používá postup, který je principiálně shodný s Connection oriented media. Chování RTP relay není definováno žádným standardem, a proto do značné míry závisí na konkrétní implementaci. Z pozorování prováděných v rámci diplomové práce vyplývá, že některé SIP proxy záměrně ignorují IP adresu a port uvedené v protokolu SDP a všechny hovory automaticky přepojují přes RTP relay. Nevýhodou tohoto řešení je samozřejmě jisté plýtvání šířkou pásma a výkonem RTP relay, neboť data, která by normálně tekla přímo mezi dvěma účastníky, musí procházet navíc přes RTP relay a to i v případě, kdy jsou oba účastníci například ve stejné síti. RTP relay také zanáší do hovoru jisté nepatrné zpoždění. RTP relay servery poskytují vysoký uživatelský komfort (není potřeba složitá konfigurace), vysokou spolehlivost (fungují na všech typech NATu) a navíc umožňují i přesný výpočet ceny hovoru. Pokud by totiž hlasová data netekla přes RTP relay, mohl by jeden z účastníků například poslat své SIP proxy zprávu BYE, čímž by VoIP poskytovatel zastavil účtování hovoru, který by přitom dále pokračoval bez účasti SIP proxy. Kromě procházení NATu lze RTP relay použít také například ke konverzi formátu hlasových dat nebo jako rozhraní mezi VoIP telefonem a běžnou telefonní sítí. 2.2.3 SIP telefonní hovor v praxi V předchozích kapitolách byla probrána různá úskalí navazování telefonního hovoru v sítích, kde dochází k překladu IP adres a portů. Protože je NAT v dnešní době velmi rozšířený, byli komerční VoIP poskytovatelé, kteří se snaží vycházet maximálně vstříc svým zákazníkům, nuceni zareagovat a začít používat protokol SIP trochu jinak, než jak předpokládá dokument RFC 3261 [2] definující SIP. Další motivací ke změně architektury systému byl fakt, že se uživatelé nechtějí omezovat jen na volání v rámci internetu – VoIP operátoři umožňují volat do klasické pevné telefonní sítě i na mobilní telefony. V podání dnešních VoIP operátorů se stal protokol SIP jakýmsi rozhraním pro přístup do globální telefonní sítě, která používá své vlastní způsoby přenosu dat. Protokol SIP ve své klasické podobě zůstává zachován jen ve velkých institucích, které jej používají pro spojování hovorů v rámci budovy (hovory na běžná telefonní čísla se přepojují do globální telefonní sítě). 28
2. Principy fungování VoIP telefonie Průběh telefonního hovoru tak, jak probíhá u předních českých VoIP poskytovatelů v době psaní této práce, je vidět na obrázku 2.11. Předpokládejme, že oba účastníci hovoru již poslali zprávy REGISTER svým SIP proxy, které jejich registrace přijaly. Alice posílá zprávu INVITE své SIP proxy a uvádí v ní Bobovo telefonní číslo ve formátu SIP URI. SIP proxy
Veřejná telefonní síť
fayn.cz
SIP proxy ustredna.mikrotech
OK
(R T
P)
15
K AC
20 0
. 12
8.
BY E
in g ng
OK
Ri
0 20
0 18
.
) TP (R
su hl a os Př en .
1
u as hl
10
0.
5.
7.
fa yn
ng
5@
yi Tr 0
12 34 E
10
VI T
OK
2.
0
1.
. .0 10 5@ 34 12 g E in ng Ri
0
18
OK
IN
4.
T VI
IN
.c z
3.
K
E BY
20
AC
0 20 os en Př
RTP relay
6.
9.
.
. 13
14
. 11
RTP relay
Alice 212.158.128.3
Bob 10.0.0.1
Obrázek 2.11: Skutečně zjištěný průběh hovoru Alice dostává jako odpověď stavový kód 100 Trying a její proxy se připojuje k Bobovi pomocí globální telefonní sítě. Telefonní síť zjistila, že Bobovo číslo spravuje server ustredna.mikrotech.cz a posílá mu požadavek na spojení. Bobova SIP proxy generuje zcela nový požadavek INVITE a ten posílá Bobovi. Bobův počítač zobrazuje hlášení o příchozím hovoru a posílá své proxy stavový kód 180 Ringing, který se přepošle skrz telefonní síť až k Alicině proxy, která vytváří novou stavovou zprávu 180 Ringing a posílá ji Alicině telefonu. Stejným způsobem se doručí i stavový kód 200 OK ve chvíli, kdy Bob zvedne telefon. Hlasová data se posílají přes RTP relay servery, které vlastní oba VoIP poskytovatelé. RTP relay může běžet na stejné IP adrese jako SIP proxy, zpravidla se však jedná o dedikovaný stroj nebo o jeden z několika dedikovaných strojů (v závislosti na počtu zákazníků, které operátor obsluhuje). SIP proxy je s RTP relay servery velmi úzce spojena a přiděluje jim požadavky na přenos jednotlivých hovorů. 29
2. Principy fungování VoIP telefonie Ukončení hovoru probíhá obdobným způsobem jako jeho navázání: Alice posílá zprávu BYE, kterou její proxy přeloží do formátu používaném v telefonní síti. Telefonní síť přepošle informaci Bobově proxy, která vygeneruje novou zprávu BYE, jež pošle Bobovi. Bob odpovídá stavovým kódem 200 OK, který se přenese obdobným způsobem.
2.2.4 Vyzváněcí tóny Už z dob používání analogových telefonů jsou lidé zvyklí, že když začne volanému účastníkovi zvonit telefon, slyší volající ve sluchátku vyzváněcí tón. Stejně tak pokud volaný účastník právě hovoří, ozve se obsazovací tón, a svou zvukovou indikaci má také neplatné telefonní číslo. Všechny tři tóny můžeme samozřejmě slyšet také z VoIP telefonu. Mohou se generovat dvěma různými způsoby: •
přímo na VoIP telefonu,
•
telefonní ústřednou.
První způsob je starší a šetrnější k použité šířce pásma. Vyzváněcí nebo jiný tón generuje přímo telefon, ze kterého voláme. Nevýhodou tohoto řešení je fakt, že v různých zemích se používají různé vyzváněcí tóny. Některé přístroje mají proto tyto tóny nastavitelné – pomocí speciálního zápisu lze definovat výšku tónu, jeho délku i opakování. Druhou možností je generování vyzváněcího tónu přímo na ústředně resp. RTP relay serveru. Pokud se použije tato varianta, nepatrně se změní schéma navazování hovoru: Kromě SIP zprávy 180 Ringing posílá SIP proxy ještě zprávu 183 Session Progress, která má ve svém těle v protokolu SDP napsánu IP adresu a port RTP relay, kam může volající účastník posílat data. Uživatelský agent na tuto zprávu zareaguje tak, že pošle první prázdný RTP paket směrem k RTP relay. Tím se otevře NAT (pokud je třeba) a RTP relay zjistí IP adresu a port volajícího účastníka. Poté mu začne prostřednictvím protokolu RTP posílat vyzváněcí případně jiný tón, podobně jako by se jednalo o běžný telefonní hovor. Když volaný účastník zvedne telefon, volajícímu přichází zpráva 200 OK s popisem spojení, který zpravidla odpovídá tomu ze zprávy 183 Session Progress. Výhodou tohoto řešení je fakt, že se místo vyzváněcího tónu může poslat i složitější melodie nebo například hlášení o nízkém stavu kreditu. 30
2. Principy fungování VoIP telefonie 2.2.5 Speciální případy hovoru Dosud se při popisu telefonního hovoru v této práci počítalo s nejběžnějším případem, když jeden účastník zavolá druhému, ten hovor přijme a po nějaké době jeden z nich hovor ukončí. Nicméně z hlediska monitorování VoIP telefonie, kterým se zabývá tato práce, je důležité znát i ostatní případy, kdy se hovor navázat nepodaří. V této kapitole je uveden jejich stručný přehled: Zavěšení před začátkem hovoru Jedná se o případ, kdy se volající rozhodne položit telefon ještě dříve, než ho volaný účastník vůbec zvedne. V terminologii protokolu SIP to znamená, že chceme zrušit již odeslanou zprávu INVITE dříve, než od volaného účastníka přišel stavový kód 200 OK. V tomto případě uživatelský agent posílá zprávu CANCEL ve které uvádí pořadové číslo (pole CSeq) požadavku INVITE, který chce zrušit. Pokud vše proběhne správně, SIP proxy odpovídá na požadavek CANCEL stavovým kódem 200 OK a na zrušený požadavek INVITE stavovým kódem 487 Request Canceled. Obsazeno Pokud volaný účastník právě hovoří, SIP proxy volitelně posílá stavový kód 183 Session Progress a přehrává zprávu „Volaný účastník právě hovoří“. Po skončení nahrávky posílá stavový kód 486 Busy Here. Volající potvrzuje zprávu metodou ACK a ukončuje hovor. Pokud se volající rozhodne ukončit hovor ještě předtím, než se přehraje celá zpráva, musí jeho uživatelský agent zrušit prováděný požadavek INVITE metodou CANCEL podobně jako v případu Zavěšení před začátkem hovoru. Nedostupné číslo Pokud je zadané číslo nedostupné, SIP proxy volitelně posílá stavový kód 183 Session Progress a přehrává zprávu o nedostupnosti čísla. Po skončení nahrávky „Volané číslo je nedostupné“ posílá stavový kód 500 Service Unavailable. Volající tuto zprávu potvrzuje metodou ACK a ukončuje hovor. Ostatní případy Obecně lze říci, že telefonní hovor začíná stavovým kódem 200 OK, který přichází jako reakce na zprávu INVITE. Pokud dojde k chybě, posílá se stavový kód 400 nebo vyšší. Pokud chce operátor přehrát nějaké sdělení (například 31
2. Principy fungování VoIP telefonie upozornění na nízký stav kreditu), může tak učinit prostřednictvím stavového kódu 183 Session Progress a teprve poté buď začít hovor stavovým kódem 200 OK nebo skončit s nějakým chybovým kódem. Pokud chce volající ukončit hovor dříve než dostane stavový kód 200 nebo vyšší, musí poslat zprávu CANCEL, protože požadavek stále ještě probíhá. Zpráva INVITE se jako jediná zpráva protokolu SIP potvrzuje (zprávou ACK) a to nejen v případě úspěšného navázání hovoru, ale i v případě chyby nebo zrušení požadavku.
32
Kapitola 3
Monitorování VoIP provozu na vysokorychlostních sítích Existují dva základní přístupy k monitorování síťového provozu. První z nich ukládá všechny procházející pakety a jeho hlavní nevýhodou je špatná škálovatelnost. Ukládání celých paketů je na sítích s větším množstvím provozu velmi obtížné nebo i nemožné. Samozřejmě lze zachytávat jen pakety tekoucí na určitých IP adresách a portech, ale tím nezískáme celkovou představu o provozu v síti. Dnes se tato metoda používá především na diagnostiku problémů s nějakou konkrétní síťovou službou nebo aplikací. Pro účel dlouhodobého monitorování sítí se v dnešní době preferuje druhé řešení, které místo celých paketů zaznamenává jen jejich toky v síti. Síťový tok je skupina paketů, které sdílí nějaké společné vlastnosti. Většinou se za tok považují pakety, které mají stejnou zdrojovou a cílovou IP adresu, shodný zdrojový a cílový port, přenášejí data stejného protokolu čtvrté síťové vrstvy (TCP, UDP, ICMP) a vyskytují se přibližně ve stejném čase. Ke každému síťovému toku se ukládají součtové statistiky (například počet přenesených paketů a bajtů) a také agregované statistiky (například příznaky protokolu TCP, které se objevily během přenosu). Koncept měření síťových toků zavedla společnost Cisco v průběhu devadesátých let minulého století při vývoji svých směrovačů, které po příchodu prvního paketu vytvořily tzv. flow record, podle kterého směrovaly všechny následující pakety ze stejného toku. Síťové toky se tedy původně používaly pro interní potřeby síťových prvků, nicméně brzy přibyla podpora jejich exportu za účelem monitorování sítě. Dnes už se síťové toky používají výhradně pro monitorovací účely a kromě aktivních prvků firmy Cisco je umí exportovat i řada dalších zařízení. Pro účely přenosu NetFlow dat (síťových toků) vyvinula společnost Cisco stejnojmenný protokol, který postupně vylepšovala. V dnešní době se používají protokoly NetFlow 5 a NetFlow 9, který byl v roce 2004 standardizován dokumentem RFC 3954. O čtyři roky později se objevuje exportní protokol IPFIX, který vzniká už nezávisle na jmenované společnosti a dále rozšiřuje 33
3. Monitorování VoIP provozu na vysokorychlostních sítích možnosti protokolu NetFlow 9. Protokoly NetFlow 9 a IPFIX nemají pevně danou strukturu přenášených dat, a proto jsou velmi flexibilní.
3.1
Architektura systému pro sběr NetFlow dat
Jak již bylo řečeno, NetFlow data lze generovat přímo na některých síťových směrovačích. Další možností je použití samostatného zařízení, které se nazývá síťová sonda. Sonda je pasivní měřící prvek, který se připojuje na jednu nebo více monitorovaných linek pomocí tzv. TAPu (Test Access Port), který odbočuje přenášená data v obou směrech do sondy. Další možností je použití tzv. Mirror portu umístěném na některém ze switchů v síti. Možná zapojení síťové sondy jsou naznačena na obrázku 3.1. LCD-Pro
CARD READER
PHONE
MIC
LINE-IN
AUDIO
SATA
USB EJECT
DVD-RW POWER
NumLock
F7 F8
~
`
!
F4
F3
F1 F2 Esc
1
@
Tab
2
#
F11 F12 F9 F10 + _
-
ScrollLock PrintScrn SysRq
Pause
|
\
Home
PageUp Delete
}
NumLock
Break
Insert
=
ScrollLock
CapsLock
End
PageDown
/ 7
Shift
9
8
Home
]
) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M < , > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X
Switch
-
*
4
PgUp
+
6
5
1
End
3
2 0
PgDn
Enter Del
.
Ins
Ctrl
Alt Gr
Alt
Shift
Ctrl
TAP Mirror port
LCD-Pro
Mirror port
CARD READER
AUDIO LINE-IN
+
MIC
-
PHONE
SELECT MENU
SATA
USB EJECT
DVD-RW POWER
SELECT
-
+
MENU
NumLock
F7 F8
~
`
!
F4
F3
F1 F2 Esc
1
@
Tab
2
#
F11 F12 F9 F10 + _
-
ScrollLock PrintScrn SysRq
Pause
|
\
Home
NumLock
PageUp Delete
}
CapsLock
Break
Insert
=
ScrollLock
End
Shift Alt Gr
Alt
Shift
Ctrl
LCD-Pro
NetFlow 9
CARD READER
PHONE
MIC
LINE-IN
AUDIO
SATA
USB EJECT
DVD-RW
IPFIX
POWER
SELECT
-
+
MENU
NumLock
F7 F8
~
`
!
F4
F3
F1 F2 Esc
1
@
Tab
2
#
F11 F12 F9 F10 + _
-
ScrollLock PrintScrn SysRq
Pause
=
|
\
Home
NumLock
PageUp Delete
}
ScrollLock
CapsLock
Break
Insert
End
PageDown
7
Shift
9
8
Home
]
) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M < , > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X
-
*
/
4
PgUp
+
6
5
1
End
3
2 0
PgDn
.
Enter Del
Ins
Ctrl
Alt Gr
Alt
Shift
Ctrl
Sonda
Sonda Kolektor
Obrázek 3.1: Architektura sběru NetFlow dat. Sonda může zjištěné síťové toky ukládat do svého interního úložiště (pokud jím disponuje), ale zpravidla je posílá některým ze standardních NetFlow protokolů na tzv. kolektor, což je zařízení určené pro sběr NetFlow statistik. Kolektor většinou disponuje velkokapacitním diskovým úložištěm, přijímá data z několika sond současně a umožňuje tato data agregovat, vyhodnocovat a prezentovat.
3.2
Cisco AVC
Možnosti měření a analýzy síťového provozu neustále rostou, a proto společnost Cisco nezůstala jen u měření síťových toků. V řadě situací může být užitečné kromě hlavičky paketu analyzovat i jeho obsah. Například některé aplikace a viry posílají svá data úmyslně přes port 80, který je určený primárně protokolu HTTP, neboť tento port bývá kvůli prohlížení webu otevřen na drtivé většině firewallů. Při pouhém sledování síťových toků se dá jen těžko odhalit, že na portu 80 tekla jiná dat než WWW stránky. 34
-
*
/
PageDown
7
9
8
Home
]
) 0 { [ ( 9 F5 F6 " ' * 8 O P & 7 L : ; ? ^ 6 U I % 5 J K M < , > . / $ T Y 3 4 E R G H N D F C V B Q W A S CapsLock Z X
Ctrl
4
PgUp
+
6
5
1
End
3
2 0
PgDn Ins
.
Enter Del
3. Monitorování VoIP provozu na vysokorychlostních sítích Proto vznikla technologie Cisco AVC (Application Visibility and Control), která provádí tzv. hloubkovou prohlídku paketu, a z přenášených dat umožňuje určit, jakému protokolu zachycená zpráva odpovídá, nebo dokonce jaká aplikace tento paket odeslala. U řady oblíbených protokolů je možné zjistit i další informace, například URL přenášené WWW stránky u protokolu HTTP. Pro detekci jednotlivých aplikací používá Cisco AVC technologii NBAR (Network Based Application Recognition). Získaná data se exportují společně s NetFlow daty a je možné je dále vyhodnocovat a zpracovávat. Kromě pasivního monitorování umožňuje Cisco AVC na jednotlivé aplikace také odpovídajícím způsobem reagovat – například upřednostňovat programy důležité pro chod podniku, detekovat škodlivý software v síti, vytvářet statistiky používaných služeb apod. Analýza obsahu přenášených paketů je trend, kterým se momentálně ubírají NetFlow monitorovací nástroje. Ostatně i tématem této diplomové práce je v podstatě hloubková analýza paketů protokolu SIP.
3.3
Existující nástroje pro monitorování VoIP provozu
VoIP telefonie se těší stále rostoucí oblibě, a proto není divu, že v současné době existuje celá řada monitorovacích nástrojů určená pro sledování telefonních hovorů a odhalování problémů souvisejících s jejich kvalitou. Tato kapitola shrnuje současný stav monitorování VoIP provozu a představuje nejdůležitější dostupné produkty. Pro všechny z nich platí, že pro vyhodnocování telefonních hovorů používají jednu nebo dvě z následujících metod: •
Ukládání celých paketů týkajících se VoIP provozu.
•
Čtení statistik Cisco IP-SLA.
•
Export síťových toků s informacemi o VoIP provozu.
Nejběžnější je první zmíněná metoda, která na jednu stranu poskytuje maximální množství informací o hovoru, ale na druhou stranu má i svá výkonnostní omezení. Paketů týkajících se VoIP provozu chodí sice i na velkých sítích poměrně málo, ale monitorovací nástroje musí být schopné je včas rozlišit od ostatního provozu. Pakety je sice možné filtrovat například podle portů nebo VLAN tagů, ale tím už sledujeme jen tu část sítě, kde VoIP provoz očekáváme. Druhou možností je čtení IP-SLA (Service Level Agreements) [15] statistik, které umožňují exportovat některé směrovače Cisco. Jedná se o poměrně snadný a přímočarý způsob získávání dat, nicméně statistiky podávají pouze 35
3. Monitorování VoIP provozu na vysokorychlostních sítích obecné informace o ztrátovosti paketů a jejich rozptylu. Informace o průběhu jednotlivých hovorů a volajících stranách jsou tudíž velmi omezené nebo se musejí získávat jiným způsobem. Navíc aby bylo možné použít tuto metodu získávání dat, je zapotřebí mít v síti směrovače, které podporují export IPSLA dat. Poslední možností je rozšířit koncept NetFlow tak, aby umožňoval exportovat informace týkající se telefonních hovorů. Toto řešení nabízí vysoký výkon, ale ani zde se neukládají všechny dostupné údaje. Proto je zapotřebí velmi dobře zvážit, jaká data se budou ukládat, aby z nich získal operátor co nejlepší představu o dění v síti. Zatím jediným zástupcem tohoto postupu je rozšíření sondy nProbe, které implementoval Luca Deri. Tomuto tématu se věnuje také článek SIPFIX: A Scheme For Distributed SIP Monitoring [1], z něhož částečně vychází i tato diplomová práce. 3.3.1 VoIPmonitor VoIPmonitor [11] je komerční nástroj pro sledování VoIP provozu běžící na operačním systému Linux, který je založen na stejnojmenném otevřeném nástroji VoIP monitor [12]. Umožňuje zpracovávat protokoly SIP, RTP, RTCP a Cisco SKINNY (SCCP), vyhodnocovat rozptyl a ztrátovost paketů a určovat kvalitu hovoru podle doporučení ITU-T G.107 [10]. Zachycená data se ukládají do databáze MySQL nebo do jiné SQL databáze s rozhraním ODBC. VoIPmonitor umí uložit celý hovor jako soubor PCAP nebo dekódovat hlasovou komunikaci a uložit ji ve formátu WAV (pouze při použití některého z podporovaných kodeků). Dále je možné zobrazovat statistiky kvality a počtu hovorů, podíl návratových kódů SIP proxy, stav registrací jednotlivých SIP klientů, generovat události při výskytu určité akce (například telefonního hovoru) a posílat pravidelné reporty. VoIPmonitor má příjemnou obsluhu a vyniká rychlou odezvou. Uživatelé, kteří nepotřebují placenou podporu a vyladěné grafické rozhraní, mohou použít originální volně šiřitelnou verzi programu VoIP monitor, která je samozřejmě zdarma i pro komerční použití. 3.3.2 PRTG Network Monitor PRTG Network Monitor [13] je nástroj pro komplexní monitorování sítě. Umožňuje jak pasivní monitorování síťových spojů, tak aktivní kontrolu funkčnosti síťových služeb podobně jako například volně šiřitelný nástroj Nagios. PRTG se instaluje na počítače s operačním systémem Windows a pro své ovládání nabízí jak webové rozhraní, tak textovou konzoli a aplikace 36
3. Monitorování VoIP provozu na vysokorychlostních sítích pro mobilní telefony. Ze stránek výrobce bohužel není patrné, jaké množství síťového provozu je aplikace schopna měřit. Aplikace nabízí dva způsoby měření VoIP provozu: Pokud některý směrovač v síti podporuje technologii Cisco IP-SLA [15], umožňuje načítat informace podávané tímto směrovačem. V opačném případě je nutné použít tzv. QoS Sensor, kterým je možné měřit kvalitu VoIP hovorů v síti přímo. Bohužel aplikace nepodporuje dekódování signálních informací protokolu SIP (alespoň se o tom výrobce na svých stránkách nezmiňuje). Tento fakt pokládám za největší nevýhodu tohoto monitorovacího systému.
3.3.3 VoIP & Network Quality Manager VoIP & Network Quality Manager [14] od společnosti Solarwinds je velmi komplexní nástroj pro sledování sítě, který mimo jiné podporuje i analýzu VoIP provozu. Aplikace běží na systému Microsoft Windows a má poměrně vysoké systémové požadavky. Umožňuje zobrazovat seznamy hovorů pro předem definované regiony, hodnotí kvalitu hovoru na stupnici 1 – 5, zobrazuje statistiky ztracených paketů a jejich rozptyl a umí generovat výstrahy v případě výskytu nějaké definované události. Data o kvalitě hovorů umí získávat i ze směrovačů podporujících IP-SLA [15].
3.3.4 Homer Homer je profesionální nástroj na monitorování VoIP telefonie na bázi protokolu SIP s otevřeným kódem. Na rozdíl od předchozích představovaných řešení umožňuje přijímat data přímo z některých typů SIP serverů (Kamailio, OpenSIPS a FreeSWITCH), takže může být vhodným nástrojem pro správce VoIP telefonních ústředen. Pokud není možné odbočit SIP komunikaci přímo ze serveru, lze ji zachytávat na monitorované síti pomocí knihovny libpcap. Homer běží na operačním systému Linux, data ukládá do databáze MySQL. Umožňuje zobrazovat seznamy uskutečněných hovorů, filtrovat je podle různých kritérií a v případě potřeby dokáže zobrazit celé SIP zprávy týkající se jednoho hovoru v textové i grafické podobě. Jeho součástí jsou i různé funkce pro generování statistik a hodnocení kvality hovoru. Často potřebná zobrazení je možné umístit ve formě widgetů na hlavní uživatelskou stránku. Na programu Homer nejvíce oceňuji řadu podporovaných vstupních rozhraní a dostupnost detailního záznamu a zobrazení informací o telefonním hovoru (včetně stažení celé komunikace ve formátu PCAP). 37
3. Monitorování VoIP provozu na vysokorychlostních sítích 3.3.5 nProbe a ntop nProbe a ntop [18] jsou NetFlow sonda a kolektor s otevřeným kódem, které v rámci své výzkumné práce Open Source VoIP Traffic Monitoring [17] rozšířil italský vývojář Luca Deri o podporu rozpoznávání VoIP provozu. Zatímco všechna předchozí řešení spoléhají na zachytávání a ukládání celých paketů přenášejících VoIP data, rozšířená sonda nProbe ukládá pouze nejnutnější informace, které exportuje jako doplňující pole síťových toků. Kolektor ntop je upraven tak, aby dokázal přijímat tato rozšířená data, a umožňuje zobrazit základní údaje o telefonním hovoru. Bohužel se zdá, že vývoj těchto rozšíření od doby vydání vědeckého článku nijak výrazně nepokračuje, a proto zůstává toto řešení pro koncové uživatele zatím jen obtížně použitelné.
3.4
Monitorování VoIP provozu pomocí řešení FlowMon
Řešení FlowMon vyvíjené českou společností INVEA-TECH je jedním z předních produktů pro záznam a vyhodnocování NetFlow dat v síti. Nabízí síťové sondy FlowMon Probe umožňující monitorovat jednu až čtyři metalické nebo optické linky o rychlosti až 10 Gb/s a zpracovat současně až 4 miliony toků. NetFlow data lze ukládat na vestavěný kolektor o kapacitě 500 GB nebo je exportovat na dedikovaný kolektor. FlowMon Probe podporuje exportní formáty NetFlow 5, NetFlow 9 a IPFIX. FlowMon Collector je zařízení pro sběr a vyhodnocování NetFlow dat o kapacitě až 12 TB. Díky podpoře standardních datových formátů může přijímat data nejen od sond FlowMon Probe, ale i od jiných zařízení generujících síťové toky ve formátech NetFlow nebo IPFIX. Produkty rodiny FlowMon jsou velmi flexibilní a umožňují snadno rozšiřovat funkce sondy i kolektoru pomocí pluginů. Cílem této diplomové práce je navrhnout sadu zásuvných modulů pro sondu a kolektor, které umožní monitorování VoIP telefonie založené na protokolu SIP. Navržený systém by měl mít následující vlastnosti: •
Práce na principu síťových toků.
•
Podpora čtení paketů protokolu SIP, SDP, RTP a RTCP.
•
Získání informací o hovoru – kdo, kdy a komu volal, jak dlouho hovor trval a jestli vůbec proběhl.
•
Schopnost přiřadit RTP tok k telefonnímu hovoru.
38
3. Monitorování VoIP provozu na vysokorychlostních sítích •
Detekce použitého kodeku.
•
Kontrola kvality telefonního hovoru (počet ztracených paketů a jejich rozptyl).
•
Schopnost vyfiltrovat toky týkající se jednoho hovoru.
•
Odlišení VoIP toků od ostatních síťových toků, zobrazení seznamu posledních hovorů.
•
Jednoduché grafické rozhraní pro vyhodnocování naměřených dat.
•
Integrace do řešení INVEA-TECH FlowMon.
Z výše uvedeného výčtu je vidět, že bude potřeba rozšířit funkce síťové sondy tak, aby mimo základních metrik síťového toku zaznamenávala také informace týkající se telefonních hovorů. Tyto informace se budou posílat na kolektor, který umožní jejich další vyhodnocení. Sondová část systému bude implementována jako rozšiřující modul do programu FlowMon Exportér, který se stará o generování NetFlow dat. Hlavní funkcí tohoto modulu bude identifikace a zpracování paketů protokolu SIP a rozšíření množiny NetFlow dat o další exportovaná pole. Uvedený modul umožní také identifikovat hlasová data posílaná protokolem RTP a měřit kvalitu hovoru. Kolektorovou část systému bude tvořit jednoduché uživatelské rozhraní, které se nainstaluje jako zásuvný modul do zařízení FlowMon, a umožní zobrazit rozšířené statistiky týkající se VoIP provozu, filtrovat toky svázané s určitým telefonátem a provádět automatickou analýzu hovorů. Data mezi sondou a kolektorem se budou přenášet pomocí protokolu IPFIX (IP Flow Information eXchange) [8], který je považován za nástupce protokolu NetFlow 9 společnosti Cisco. Na rozdíl od něho umožňuje protokol IPFIX definovat vlastní pole v NetFlow datech, což výrazně usnadní přenos informací o telefonních hovorech ze sondy na kolektor.
39
Kapitola 4
Programové vybavení síťové sondy Síťovou sondou se rozumí zařízení, které je schopné pasivně monitorovat (tj. pouze poslouchat) síťový provoz, zpracovávat a exportovat naměřená data. Export dat se může provádět i do souboru, ale většinou se získaná data ihned odesílají (exportují) na kolektor. Pro účely této práce byla použita sonda FlowMon Probe společnosti INVEA-TECH, která mi poskytla zázemí při psaní této práce. FlowMon sonda se dodává buď ve formě samostatného serveru (procesor Intel Xeon, 4 GB RAM, pevný disk 500 GB) nebo jako virtuální stroj VmWare ESXi. Na zařízení běží upravený operační systém CentOS 5. Každá sonda má jedno síťové rozhraní (eth0) určené pro vzdálenou správu a jedno nebo více monitorovacích rozhraní, která se připojují na měřenou linku. Získaná data lze ukládat buď na vestavěné úložiště o velikosti 500 GB nebo je exportovat na dedikovaný kolektor.
4.1
FlowMon Exportér 4.0
FlowMon Exportér je klíčovou součástí programového vybavení sondy. Umožňuje měřit síťový provoz o vysokých rychlostech (řádově sta tisíce paketů za sekundu) a agregovat ho do síťových toků. Pro výstupní data lze zvolit některý z běžně používaných formátů – např. NetFlow 5, NetFlow 9 nebo IPFIX. Jeho funkčnost lze snadno rozšířit prostřednictvím zásuvných modulů, které používají veřejně dostupné aplikační rozhraní. Aktuální stabilní verze nese označení 3.5, nicméně tato diplomová práce se zabývá novou testovací verzí 4.0, která přináší mnohá vylepšení jak z hlediska funkcí, tak i výkonu. Exportér se spustí nad zvoleným síťovým rozhraním a zpracovává příchozí pakety. Výsledkem jejich zpracování jsou tzv. flow recordy, které obsahují mimo jiné následující údaje: •
Začátek toku,
•
konec toku,
40
4. Programové vybavení síťové sondy •
počet přenesených paketů,
•
počet přenesených bajtů,
•
id vstupního a výstupního zařízení,
•
zdrojovou a cílovou IP adresu,
•
přenosový protokol,
•
zdrojový a cílový port (protokoly TCP a UDP),
•
příznaky protokolu TCP (protokol TCP),
•
typ ICMP zprávy (protokol ICMP).
Získané flow recordy se ukládají do bufferu, který se nazývá flow cache. Pokud dojde k vložení záznamu, který odpovídá nějakému již existujícímu flow recordu (tj. shodují se zdrojová a cílová IP adresa, zdrojový a cílový port a protokol čtvrté síťové vrstvy), dojde k agregaci obou záznamů a to tak, že se aktualizuje původní záznam a ten nový se po dokončení agregace uvolní z paměti. Síťový tok se zdrží ve flow cache maximálně několik minut a opouští ji při splnění některé z následujících podmínek: •
Uplynul časový limit a k toku nepřibyl žádný další paket – tok skončil.
•
Tok trvá moc dlouho – je třeba udělat průběžný export a rozdělit ho.
•
Došlo ke kolizi ve flow cache – je třeba uvolnit místo.
•
Některý zásuvný modul rozhodl o tom, že se má tok ihned exportovat.
Po opuštění flow cache je tok zařazen do fronty toků připravených k exportu. Obsah této fronty se v pravidelných intervalech prochází a exportuje. Cíl a formát výstupu je určen typem exportního pluginu. 4.1.1 Základní použití Aby mohl FlowMon Exportér začít pracovat, potřebuje znát alespoň název vstupního a exportního pluginu a jejich parametry. Jak již název napovídá, vstupní plugin zajišťuje čtení dat ze síťového rozhraní nebo ze souboru, zatímco exportní plugin zodpovídá za kódování výstupu například do formátu NetFlow nebo prostého CSV. Vstupní plugin se zadává pomocí přepínače -I, exportní plugin pomocí přepínače -E. Pokud chceme pluginu předat nějaké 41
4. Programové vybavení síťové sondy parametry, uvedeme za jeho názvem dvojtečku následovanou seznamem parametrů ve formátu parametr1=hodnota,parametr2=jiná_hodnota. Výpis všech dostupných pluginů se získá pomocí přepínače -l. Pokud používáme plugin, který čte data z fyzického síťového rozhraní (ne ze souboru), musíme spustit Exportér pod uživatelem root, aby měl práva přistupovat k požadovanému síťovému rozhraní. V tomto případě bychom neměli zapomenout uvést parametr -u uživatel, který umožní běžet Exportéru pod zadaným uživatelským účtem a oprávnění uživatele root používat jen pro přístup k síťovému rozhraní. Základní spuštění Exportéru může vypadat například takto: # flowmonexp -u flowmon -I rawnetcap : device = eth2 , sampling =2 ,\ cache - size =32768 -E csv
Výpis kódu 4.1: Spuštění FlowMon Exportéru se základními paramtery Uvedený příkaz spustí Exportér nad rozhraním eth2 a bude vypisovat exportované toky na standardní výstup ve formátu CSV. Pokud chceme spustit Exportér na pozadí, použijeme volbu -d. Pomocí přepínače -t a:i lze nastavit časový limit pro export toku v sekundách. Hodnota a odpovídá času pro export toku, který je stále ještě aktivní (průběžný export), zatímco hodnota i odpovídá času, po kterém se exportují toky, které nejsou již dále aktivní. Seznam dalších přepínačů lze zobrazit pomocí přepínače -h. 4.1.2 Rozšiřující moduly Jak již bylo řečeno, základní funkcionalitu Exportéru lze rozšířit pomocí pluginů, které zasahují do různých fází zpracování paketu (viz kapitola 4.1). Existuje celkem pět typů rozšiřujících modulů: •
Input – zodpovídají za vstup paketů do Exportéru.
•
Reflector – umožňují přistupovat k celému obsahu paketu a zpracovávat ho vlastním způsobem (nevytváří flow recordy).
•
Process – dodatečně zpracovávají příchozí pakety, filtrují je a umožňují řídit jejich agregaci.
•
Filter – filtrují data před exportem.
•
Export – zajišťují export dat v určitém formátu.
Rozšiřující moduly mají podobu sdílených knihoven (.so) a mohou implementovat jeden nebo i více typů pluginu najednou. K překladu rozšiřujícího 42
4. Programové vybavení síťové sondy modulu je zapotřebí mít v adresáři /usr/include/flowmonexp hlavičkové soubory Exportéru, které společnost INVEA-TECH poskytuje zdarma členům svého Community programu1 . Aby Exportér začal používat plugin, je zapotřebí příslušný soubor umístit do adresáře /usr/lib/flowmonexp resp. /usr/lib64/flowmonexp (podle architektury systému) nebo při spuštění uvést přepínač -X cesta/k/pluginu. Poté se nový modul zobrazí ve výpisu dostupných pluginů a lze jej používat stejně jako kterékoliv jiné rozšíření. 4.1.3 Aplikační rozhraní rozšiřujících modulů Hlavičky nejdůležitějších funkcí pro rozšiřující moduly najdeme v hlavičkových souborech record.c a plugin.h. První z nich obsahuje definici flow recordu a nabízí pomocné funkce pro práci s touto datovou strukturou. Druhý jmenovaný obsahuje výčet všech typů pluginů a konfigurační struktury. Dále je zapotřebí zmínit hlavičkové soubory pro jednotlivé typy pluginů. Například pokud vytváříme procesní plugin, budeme potřebovat soubor plugin_process.h. Tyto soubory obsahují hlavičky funkcí, které musí programátor pro daný typ pluginu definovat. V neposlední řadě je třeba uvést ještě soubor utils.h obsahující pomocné funkce a soubor debug.h obsahující funkce pro generování ladících výpisů. Každý rozšiřující modul musí obsahovat definici svého typu. Ta se provádí makrem SET_PLUGIN_TYPE, výčet možných hodnot je možné najít v souboru plugin.h. Dále je zapotřebí uvést aktuální verzi API, pro kterou plugin píšeme. Ta se řídí aktuální verzí hlavičkových souborů, které používáme. Proto stačí uvést jen makro pro výpis verze FLOWMON_API_VERSION, které provede definici za nás. Například začátek procesního pluginu by mohl vypadat podobně jako výpis 4.2. ... # include # include ... # include # include # include ...
< stdio .h > < stdlib .h > < flowmonexp / plugin .h > < flowmonexp / plugin_process .h > < flowmonexp / utils .h >
/* Set plugin type : */ SET_PLUGIN_TYPE ( PLUGIN_ TYPE_PROCESS )
1. O registraci do Community programu je možné požádat v kontaktním formuláři na stránce https://www.invea.com/cs/contacts
43
4. Programové vybavení síťové sondy /* Include API version : */ F L OW MON_API_VERSION ...
Výpis kódu 4.2: Ukázka možného začátku procesního pluginu. Dále musí všechny typy pluginů obsahovat funkci desc(), která vrací základní informace o zásuvném modulu zabalené ve struktuře plugin_desc_t (výpis 4.3). Proměnné name a help obsahují jméno pluginu a jeho popis, který se zobrazí v seznamu pluginů při spuštění Exportéru s argumentem -l. Proměnná data_size udává délku privátních dat, která si potřebuje modul uložit do flow recordu. Délka extenze flow recordu musí být vždy konstantní! Poslední položka je obsahuje doplňující nastavení pluginu a liší se pro jednotlivé typy rozšíření. Možné hodnoty jsou k nalezení v hlavičkovém souboru plugin.h a nebudu se jim podrobněji věnovat. typedef struct { char * name ; char * help ; uint16_t data_size ; plugin_flags_t flags ; } plugin_desc_t ;
Výpis kódu 4.3: Struktura plugin_desc_t Každý plugin definuje funkci init(), která se spouští po startu Exportéru (samozřejmě jen pokud je plugin povolen) a ve svých parametrech dostává argumenty z příkazové řádky a případně nějaká další nastavení. Hlavičky funkcí init() nejsou pro všechny pluginy stejné a jsou k nalezení v příslušných hlavičkových souborech. Důležité je, že všechny init() funkce vrací ukazatel na svá privátní data, která si během inicializace vytvoří (například zpracováním argumentů z příkazové řádky). Tento ukazatel je pak dostupný i v jiných funkcích, které se volají během života pluginu. Pokud funkce vrátí NULL, považuje se to za selhání inicializace pluginu. Všechny pluginy definují také funkcishutdown(), která se volá před ukončením Exportéru. U všech typů pluginů má funkce jediný parametr a tím je ukazatel na privátní data, který vrátila funkce init(). Plugin tak dostává před ukončením Exportéru možnost uvolnit alokovaná data a korektně se ukončit. Funkce shutdown() vrací hodnotu typu int, která zatím nemá žádný význam. Dále je třeba implementovat funkce uvedené v hlavičkovém souboru pro typ pluginu, který píšeme. Tato diplomová práce používá FlowMon Exportér k řešení konkrétního problému a neklade si za cíl napsat jeho podrobnou 44
4. Programové vybavení síťové sondy dokumentaci. Dále se proto budu věnovat už jen procesnímu pluginu, který je použit pro vyhodnocování VoIP provozu. Další informace o jednotlivých typech pluginů a jejich API jsou k dispozici členům INVEA-TECH Community programu.
4.2
Procesní plugin process-voip
Rozšiřující modul process-voip představuje sondovou část navrženého systému pro monitorování VoIP telefonie a umožňuje Exportéru analyzovat pakety protokolů SIP, RTP a RTCP. Získaná data je možné zpracovávat stejně jako data získaná jinými pluginy nebo samotným Exportérem. Jistým omezením však může být použitý exportní plugin. Například protokoly NetFlow společnosti Cisco umožňují přenášet jen jistou pevně danou množinu polí, a proto s nimi není možné VoIP statistiky exportovat. Export VoIP metrik funguje bez problémů s výstupem do CSV (vhodný na testování) a s exportním pluginem ipfixx2 , který exportuje NetFlow data prostřednictvím protokolu IPFIX. Aktuální verze pluginu ipfixx 1.2.1 zatím nepodporuje FlowMon Exportér 4.0, a proto doporučuji použít upravenou verzi, která se nachází na přiloženém CD v adresáři bin/flowmon-export-ipfix-1.2.1. Exportovaná data je možné ukládat na libovolném NetFlow kolektoru, který podporuje protokol IPFIX. Kromě nových polí přidává rozšiřující modul také jemnější dělení toků protokolu SIP. Motivací k tomuto kroku byl fakt, že přidaná VoIP pole jsou schopna popsat parametry vždy nejvýše jednoho telefonního hovoru. Pokud by si mezi sebou dva účastníci volali například dvakrát za sebou, mohlo by se stát, že by oba hovory splynuly v jeden tok, čímž by se ztratila informace o druhém hovoru. Proto se toky rozdělují tak, aby jeden SIP tok odpovídal nejvýše jednomu hovoru. Zvláštní skupinu toků pak tvoří SIP provoz, který neodpovídá žádnému konkrétnímu hovoru. Ostatních typů provozu se toto zjemněné dělení toků nijak nedotýká. Zdrojové kódy zásuvného modulu process-voip se nachází na přiloženém CD v adresáři src/process-voip. Pokud chceme spustit Exportér s tímto rozšířením, je třeba jej nejprve přeložit zavoláním příkazu make ve zmíněném adresáři. K překladu jsou zapotřebí hlavičkové soubory programu FlowMon Exportér, které na požádání poskytne společnost INVEA-TECH. Použití pluginu je velmi jednoduché, neboť ke svému spuštění nevyžaduje žádnou konfiguraci. Do parametrů Exportéru stačí přidat jen název pluginu pomocí přepínače -P voip a eventuálně i cestu pomocí přepínače -X (pokud 2. Zdarma ke stažení na adrese http://dior.ics.muni.cz/∼velan/flowmon-export-ipfix/
45
4. Programové vybavení síťové sondy Jméno pole VOIP_PACKET_TYPE
EID 39499
ID 32
SIP_CALL_ID SIP_CALLING_PARTY SIP_CALLED_PARTY SIP_VIA SIP_INVITE_RINGING_TIME SIP_OK_TIME SIP_BYE_TIME SIP_RTP_IPV4 SIP_RTP_IPV6 SIP_RTP_AUDIO SIP_RTP_VIDEO SIP_STATS RTP_CODEC RTP_JITTER
39499 39499 39499 39499 39499
33 34 35 36 37
39499 39499 39499 39499 39499 39499 39499 39499 39499
38 39 40 41 42 43 44 45 46
RTCP_LOST
39499
47
RTCP_PACKETS RTCP_OCTETS RTCP_SOURCE_COUNT
39499 39499 39499
48 49 50
Popis Typ paketu (ne-Voip, přích. hovor, odch. hovor, přích. servisní data, odch. servisní data, RTP, RTCP). ID hovoru. SIP URI volajícího. SIP URI volaného. SIP proxy, přes které šel požadavek. Čas zahájení hovoru/čas, kdy začal vyzvánět telefon. Čas přijetí/odmítnutí hovoru. Čas ukončení hovoru. IPv4 adresa pro RTP data. IPv6 adresa pro RTP data. Port zvukového RTP kanálu. Port obrazového RTP kanálu. Agregované statistiky SIP zpráv. Použitý RTP kodek. Rozptyl RTP paketů – pro RTP měřený sondou, pro RTCP udávaný příjemcem. Počet ztracených paketů nahlášený příjemcem. Počet odeslaných RTP paketů. Počet odeslaných bajtů v RTP datech. Počet zdrojů RTP dat.
Tabulka 4.1: Pole exportovaná pluginem process-voip.
se plugin nenachází v některém z přednastavených adresářů pro zásuvné moduly). Získané podrobnosti o telefonních hovorech se přidávají k základním polím NetFlow dat, která se exportují. Seznam všech přidaných polí je vidět v tabulce 4.1. Sloupce EID (Enterprise ID) a ID (Element ID) obsahují identifikační čísla polí, která se používají pro jejich přenos protokolem IPFIX. Podle této tabulky lze na kolektoru přidělit nově přidaným polím jejich správná jména. Exportovaná pole lze rozdělit do čtyřech skupin podle toho, k jakému protokolu se váží. Pole VOIP_PACKET_TYPE tvoří samostatnou skupinu, exportuje se u všech toků a udává typ paketu z pohledu detekce VoIP provozu. Díky tomuto poli lze za pomoci bitové masky filtrovat i několik typů toků souvisejících s VoIP provozem současně. Může nabývat některé z následujících hodnot: 46
4. Programové vybavení síťové sondy •
0 – Data nesouvisející s VoIP.
•
1 – Servisní požadavky protokolu SIP.
•
2 – Odpovědi na servisní požadavky protokolu SIP.
•
3 – SIP požadavky pro práci s hovorem.
•
4 – Odpovědi na SIP požadavky pro práci s hovorem.
•
8 – Hlasová data přenášená protokolem RTP.
•
16 – Řídicí a statistické zprávy protokolu RTCP.
Pole s předponou SIP se exportují pouze u toků, v nichž se přenášela data protokolem SIP. Protože procesní plugin rozeznává celkem čtyři druhy SIP zpráv, význam některých exportovaných polí se pro jednotlivé typy SIP toků liší a při jejich interpretaci je třeba přihlédnout také k hodnotě pole VOIP_PACKET_TYPE. Seznam těchto polí a jejich význam je uveden v tabulce 4.2. Jméno pole SIP_INVITE_RINGING_TIME SIP_OK_TIME SIP_BYE_TIME SIP_RTP_IPV4 SIP_RTP_IPV6 SIP_RTP_AUDIO SIP_RTP_VIDEO SIP_STATS SIP_STATS SIP_STATS SIP_STATS
Typ 1, 2 3 4 1, 2, 3 4 1, 2, 4 3 1, 2 3, 4 1, 2 3, 4 1, 2 3, 4 1, 2 3, 4 1 2 3 4
Význam – Čas poslání první zprávy INVITE. Čas poslání prvního stavu 180 Ringing. – Čas přijetí nebo odmítnutí hovoru. – Čas ukončení hovoru. – IPv4 adresa pro příjem RTP dat. – IPv6 adresa pro příjem RTP dat. – Port pro příjem zvukových dat protokolem RTP. – Port pro příjem obrazových dat protokolem RTP. Statistiky přenesených zpráv. Viz příloha A.1. Statistiky přenesených zpráv. Viz příloha A.2. Statistiky přenesených zpráv. Viz příloha A.3. Statistiky přenesených zpráv. Viz příloha A.4.
Tabulka 4.2: Rozdílná interpretace některých SIP polí. Zvláštní pozornost si zaslouží zejména pole SIP_STATS, které obsahuje obsahuje počítadla nejčastějších druhů SIP zpráv nebo stavových kódů. Toto 47
4. Programové vybavení síťové sondy pole se exportuje jako 64bitové celé číslo a konkrétní statistiky z něho lze číst pomocí bitové masky. Význam jednotlivých bitů je uveden v příloze A na konci diplomové práce. Další skupinu polí tvoří ta s předponou RTP a týkají se pouze toků vedoucích komunikaci stejnojmenným protokolem. Jistou výjimku zde tvoří pole RTP_JITTER, které se exportuje i u toků protokolu RTCP. Rozdíl je opět ve významu. Zatímco u RTP toků toto pole udává rozptyl paketů měřený FlowMon sondou, u toků protokolu RTCP se do něj ukládá hodnota rozptylu, kterou hlásí příjemce dat. Poslední skupinu polí tvoří ta s předponou RTCP a obsahují statistické údaje vyčtené z paketů protokolu RTCP. 4.2.1 Implementace pluginu process-voip Zdrojový kód rozšiřujícího modulu je pro lepší přehlednost rozčleněn do několika souborů. Základem je soubor process-voip.c, který implementuje všechny povinné funkce pluginu. Hlavičkový soubor process-voip.h obsahuje všechny důležité struktury, které se v rozšiřujícím modulu používají. Při psaní pluginu byl kladen důraz na co možná nejvyšší výkon, a proto jsou v některých místech kódu použity ne zcela čitelné konstrukce přispívající ke zvýšení propustnosti systému. Vzhledem k tomu, že plugin ukládá poměrně velké množství dat, nebylo by je moudré přidávat přímo do základního flow recordu. Pokud by totiž byly flow recordy příliš velké, nemusely by se vejít do vyrovnávacích pamětí a tím by snižovaly výkon systému. Navíc VoIP provoz tvoří pouze malou podmonožinu celkového síťového provozu, a proto by velké množství flow recordů obsahovalo pouze nevyplněná pole pro VoIP data. typedef struct { /* Pointer to sip_data_t , rtp_data_t or rtcp_data_t : */ void * data ; } voip_record_t ;
Výpis kódu 4.4: Struktura voip_record_t. Proto byl nakonec flow record rozšířen jen o strukturu voip_record_t. Jak je vidět na výpisu 4.4, struktura obsahuje pouze ukazatel na data, která se ukládají v dynamicky alokované paměti mimo flow record. Pokud má atribut data hodnotu NULL, nejedná se o VoIP záznam (pole VOIP_PACKET_TYPE bude mít hodnotu nula). V opačném případě ukazatel vede na strukturu sip_data_t, rtp_data_t nebo rtcp_data_t. Všechny tři jmenované struktury začínají 8bitovým atributem packet_type, který odpovídá exportnímu poli VOIP_PACKET_TYPE. Protože má toto pole ve všech třech strukturách 48
4. Programové vybavení síťové sondy stejnou pozici, lze zjistit typ paketu pomocí makra PACKET_TYPE() a teprve podle výsledku ukazatel přetypovat na příslušnou strukturu. Funkce init() Provádění pluginu začíná funkcí plugin_process_init, jejíž prototyp je uveden na výpisu 4.5. Parametr params je ukazatel na řetězec obsahující parametry předané na příkazové řádce. Getter_list je ukazatel na seznam getterů, které bude poskytovat Exportér výstupnímu pluginu. Getterem se rozumí funkce, která vrací hodnotu některého z exportovaných polí. Plugin potřebuje mít k dispozici seznam getterů proto, aby do něho mohl přidat své vlastní gettery pro vrácení VoIP metrik. void * plugin_process_init ( char * params , flow_record_getter_t ** getter_list , int data_offset , int queue_count );
Výpis kódu 4.5: Inicializační funkce pluginu. Dalším důležitým parametrem je data_offset, který udává pozici privátních dat pluginu ve flow recordu. Pro lepší pochopení si lze flow record představit jako strukturu, na za níž se postupně skládají struktury s privátními daty každého pluginu. Pokud chce plugin získat svá vlastní privátní data, musí k adrese flow recordu přičíst právě tento offset, čímž se dostane za hranici základního flow recordu, kde jsou uložena jeho data (v našem případě struktura voip_record_t). Posledním parametrem je queue_count, jenž udává počet front, které paralelně zpracovávají pakety. Funkce vrací ukazatel na privátní data pluginu – v tomto případě se jedná o globální konfiguraci pluginu, nikoliv o extenzi flow recordu. V našem případě plugin registruje gettery pro všechna pole uvedená v tabulce 4.1 pomocí funkce plugin_input_getter_init() a vrací ukazatel na strukturu voip_private_t, jež obsahuje zejména proměnnou data_offset předanou stejnojmenným parametrem. Funkce init_queue() Po globální inicializaci pluginu dochází k volání funkce plugin_process_init_queue uvedené na výpisu 4.6 pro každou frontu na zpracování paketů, která se vytvoří. Funkce přijímá dva parametry: prvním z nich je base_plugin_private, který obsahuje ukazatel na privátní data pluginu, jenž vrátila funkce init(), a druhým je queue_id v němž je 49
4. Programové vybavení síťové sondy napsáno číslo fronty, která se právě inicializuje. Funkce vrací ukazatel na privátní data fronty (mohou být shodná s privátními daty pluginu). void * p l u g i n _ p r o c e s s_ i n i t _ q u e u e ( void * base_plugin_private , int queue_id );
Výpis kódu 4.6: Inicializační funkce pro frontu na zpracování paketů. Funkce init_queue() je vhodným místem pro alokaci zdrojů, které nelze sdílet mezi frontami (protože by se musely zamykat). V našem případě plugin dělá kopii globální konfigurace a poté volá funkci rtptable_create, kterou vytváří instanci tabulky pro zpracování RTP toků (bude probrána později). Funkce filter() Nejvíce zatíženým místem pluginu je funkce filter(), která zpracovává všechny příchozí pakety. Je třeba mít na paměti, že díky paralelnímu zpracování paketů může běžet ve více vláknech najednou. Funkce filter() přijímá dva parametry: plugin_private je ukazatel na privátní data fronty, zatímco packet je ukazatelem na strukturu flow_packet_t. Úkolem funkce je rozhodnout, zda paket prošel filtrem, či nikoliv. Podle toho funkce vrací návratový kód FLOW_FILTER_PASS nebo FLOW_FILTER_DROP. Procesní plugin vytvořený v rámci této práce neprovádí žádnou filtraci paketů, a proto za všech okolností vrací první návratový kód. Funkci ale využívá k analýze paketů, detekci SIP, RTP a RTCP provozu a generování statistik. Podrobný popis těchto činností bude popsán později. int p lugi n_pr ocess _fil ter ( void * plugin_private , flow_packet_t * packet );
Výpis kódu 4.7: Funkce pro filtraci paketů. Na výpisu 4.8 je vidět struktura flow_packet_t (definice v souboru record.h v hlavičkových souborech Exportéru), která si zaslouží hlubší rozbor. Ukazatel record vede na strukturu flow_record_t (k nalezení rovněž v souboru record.h), která obsahuje základní informace o toku – například čas začátku, trvání toku, zdrojovou a cílovou IP adresu, počet přenesených bajtů apod. Tento flow record odpovídá zatím právě jednomu paketu, později bude agregován s jiným flow recordy. Ukazatel packet vede na začátek surového paketu, který byl zachycen na síťovém rozhraní. Jeho délka je uložená v atributu packet_len, zatímco atribut data_offseet udává pozici začátku dat čtvrté síťové vrstvy v rámci paketu. To je velmi užitečné, protože například při analýze protokolu SIP 50
4. Programové vybavení síťové sondy není nutné znovu procházet hlavičky nižších síťových vrstev – stačí pouze přičíst data_offset k ukazateli packet. typedef struct { flow_record_t * record ; unsigned char * packet ; uint16_t packet_len ; uint16_t data_offset ; } __attribute__ (( __packed__ )) flow_packet_t ;
Výpis kódu 4.8: Struktura flow_packet_t. Důležité je si uvědomit, že Exportér kvůli maximalizaci výkonu standardně nepředává filtrační funkci celý obsah paketu, ale pouze flow record. Pokud potřebujeme ve filtrační funkci přistupovat k celému obsahu paketu, musí funkce desc() vrátit v atributu flags struktury plugin_desc_t hodnotu PLUGIN_NEED_FULL_PACKET_INPUT! Funkce update() Funkce update() provádí agregaci síťových toků a volá se ve chvíli, kdy se Exportér pokouší zařadit do flow cache dva stejné toky. Její předpis je vidět na výpisu 4.9. Jejím prvním parametrem je opět ukazatel na privátní data fronty na zpracování paktů. Ukazatel record vede na aktuální verzi flow recordu, která je uložena ve flow cache, zatímco ukazatel packet vede na nový paket, který se do flow cache už nedostane. Úkolem agregační funkce je aktualizovat flow record record daty z nově příchozího paketu. Nový paket je po skončení funkce uvolněn z paměti. void pl ugin _pro cess_ upd a te ( void * plugin_private , flow_record_t * record , flow_packet_t * packet );
Výpis kódu 4.9: Hlavička agregační funkce.
4.2.2 Rozpoznávání protokolu SIP Detekce protokolu SIP probíhá ve filtrační funkci. Protokol SIP používá standardně port 5060/UDP, nicméně v závislosti na konfiguraci může fungovat i na jiných portech nebo i nad protokolem TCP. Proto se při detekci SIP komunikace nehledí na čísla portů a kontroluje se obsah každého paketu. Naštěstí všechny SIP požadavky začínají názvem některé z deseti SIP metod a všechny odpovědi (hlášení stavu požadavku) začínají řetězcem SIP/2.0. 51
4. Programové vybavení síťové sondy Protože SIP pakety tvoří na běžné síti jen naprostou menšinu provozu, je zapotřebí, aby zejména zamítnutí testovaného paketu probíhalo co možná nejrychleji. Pokud chceme co nejefektivněji vyhodnotit, zda paket začíná některou z metod protokolu SIP, můžeme přetypovat začátek tohoto paketu na číslo a porovnat ho s číselnou konstantou, kterou získáme převodem názvu metody na ASCII kódy znaků, z nichž se skládá. Z hlediska počtu znaků jsou nejkratší metody BYE a ACK, které jsou dlouhé 3 znaky a čtvrtým znakem je mezera, která je za názvem metody povinná. Proto je vhodné přetypovat začátek paketu na typ uint32_t. Porovnání dvou čísel je velmi rychlé, procesor ho provádí v jednom nebo dvou taktech. Na detekci SIP paketu by v tomto případě bylo třeba 12 porovnání. Dále si můžeme všimnout, že některé SIP metody mají na určitých pozicích stejné znaky: Například metody REGISTER a INVITE mají obě jako čtvrtý znak písmeno I. Totéž platí i pro metody NOTIFY a OPTIONS. Pokud zjistíme, že začátek paketu nemá na čtvrté pozici písmeno I, nemá smysl testovat jej na metodu REGISTER, INVITE, NOTIFY ani OPTIONS. Podobné úvahy lze udělat i pro další metody protokolu SIP – například metody PUBLISH a SUBSCRIBE mají společné písmeno B na třetí pozici. Pokud bychom pokračovali tímto způsobem dále (vše je popsáno na začátku souboru parser.c mezi definicemi konstant), podaří se nám sloučit všech 10 metod i hlášení o stavu do pouhých dvou konstant uvedených na výpisu 4.10. Je jasné, že pokud se začátek paketu ani na jednom místě neshoduje s předloženou konstantou, nejedná se o SIP paket. # define SIP_TEST_1 # define SIP_TEST_2
0 x49544149 0 x20424953
/* ITAI */ /* BIS */
Výpis kódu 4.10: Vzorky pro detekci SIP paketů. Pokud se konstanta na některém bajtu shoduje s paketem, je třeba přistoupit k příslušné podmnožině z celkových 12 porovnání, které buď SIP paket potvrdí a nebo vyvrátí. Aby bylo toto řešení skutečně efektivnější než první navrhované, je třeba zajistit, aby se prováděl test shody s testovacím vzorkem co nejrychleji – tedy ne po jednotlivých bajtech. K tomuto účelu lze použít podobný trik, jako používá knihovní funkce strlen() pro hledání konce řetězce. Postup je následující: 1.
52
Do proměnné check uložíme exkluzivní součet začátku paketu a testovacího vzorku. Pokud se některý bajt paketu shoduje se vzorkem, bude ve výsledku tento bajt nulový.
4. Programové vybavení síťové sondy 2.
K proměnné check přičteme testovací binární číslo 01111110 11111110 11111110 11111111, které má následující význam: přičteme-li k jeho libovolnému bajtu číslo větší než nula, dojde k přetečení a nejbližší vyšší nulový bit se změní na hodnotu 1.
3.
K výsledku přičteme exkluzivním součtem negovanou proměnnou check, čímž nastavíme na hodnotu 1 bity, které zůstaly po přičtení testovacího binárního čísla nezměněné. Tím zkontrolujeme, zda v testovacím binárním číslu došlo na jednotlivých bajtech k přetečení.
4.
Pokud je logický součin výsledku a negace testovacího binárního čísla větší než nula, začátek paketu se alespoň na jednom místě shoduje s testovaným vzorkem.
Počet instrukcí provedených při hledání shody sice není dramaticky nižší než při běžném porovnání po bajtech, nicméně výše uvedený postup obsahuje pouze jediný skok a právě instrukce skoků jsou při svém provádění nejnáročnější. 1.
49 54 41 49 XOR 58 59 41 87 ---------------2. 11 0 d 00 ce + 7 e fe fe ff ---------------3. 90 Ob ff cd XOR ee f2 ff 31 ---------------4. 7 e f9 00 fc & 81 01 01 00 ---------------00 01 00 00
= vzorek = paket = check = testovaci binarni cislo
= ~ check
= ~ testovaci binarni cislo > 0
Výpis kódu 4.11: Ukázka hledání shodného bajtu ve dvou binárních číslech. Výše uvedený postup se používá nejen pro identifikaci SIP paketů, ale také pro vyhledávání začátků řádků v SIP zprávách. Tam je jeho efektivita ještě o něco vyšší, neboť při práci na 64bitovém procesoru dokáže analyzovat až 8 znaků najednou. 4.2.3 Zpracování protokolu SIP Pokud je paket vyhodnocen jako SIP, je pro něj vytvořena struktura sip_data_t a provádí se jeho detailní analýza. Podle použité SIP metody 53
4. Programové vybavení síťové sondy dojde k rozhodnutí, zda se jedná o servisní požadavek nebo o telefonní hovor (požadavky INVITE, ACK, BYE a CANCEL). Pokud se jedná o stavovou zprávu (nikoliv o požadavek), rozhodnutí padne na základě obsahu pole CSeq, v němž je uvedeno jméno metody, na kterou stavová zpráva odpovídá. V závislosti na použité metodě se také nastaví příslušné počítadlo v poli SIP_STATS (které je interně implementováno jako struktura o délce přesně 64 bitů) na hodnotu 1. Dále se vyhledají pole From, To, Via a Call-ID a jejich hodnoty se zkopírují do vytvořené struktury. Pokud je nalezeno pole Content-Type a má hodnotu SDP, nastaví se příznak, který po skončení hlavičky zajistí zpracování těla SIP zprávy. Tělo SIP zprávy je od hlavičky odděleno prázdným řádkem. Čtení protokolu SDP je méně komplikované než čtení protokolu SIP, protože jednotlivá pole mají vždy jednoznakové názvy a jsou oddělena rovnítkem, před kterým nesmí být bílé znaky. Zásuvný modul hledá pouze pole c=, které obsahuje IP adresu, a dále pole m=, jež obsahují porty pro zvukový nebo obrazový přenos. Protokol SDP umožňuje předat neomezené množství portů nebo i jejich rozsahy. V praxi se však tato možnost nevyužívá a její podpora by komplikovala analýzu protokolu i přenos dat. Proto plugin podporuje pouze jeden port pro zvuk a jeden port pro video. Ostatní porty ignoruje. Pokud vše proběhne správně, uloží se do privátních dat pluginu umístěných ve flow recordu (struktura voip_data_t) odkaz na strukturu sip_data_t, čímž se z běžného toku stává SIP tok. Dále je nutné zaregistrovat callback funkci flow_destroyed_sip_callback, která se po odstranění flow recordu z flow cache postará o uvolnění struktury sip_data_t. Posledním velmi důležitým krokem je úprava CRC flow recordu. Exportér používá CRC jako jednoznačný identifikátor toku, pokud mají dva toky stejné CRC, pokusí se je agregovat. Protože struktura sip_data_t má k dispozici pole pro popis maximálně jednoho telefonního hovoru, je třeba zajistit, aby se každý telefonní hovor ukládal jako zvláštní tok. Toho se docílí tak, že se do existujícího CRC připočítá navíc prvních 8 znaků z pole Call-ID. 4.2.4 Detekce a zpracování protokolů RTP a RTCP Na rozdíl od protokolu SIP nelze pakety protokolů RTP a RTCP snadno detekovat. Protože se jich posílá velké množství, snaží se maximálně uspořit šířku pásma, a proto nepoužívají žádné složité hlavičky. V obou protokolech jsou konstantní pouze první dva bity – mají hodnotou 10 a odpovídají verzi RTP. Bohužel na takto krátkém vzorku nelze postavit identifikaci protokolu. Proto je třeba provádět tzv. connection tracking, tj. sledovat data 54
4. Programové vybavení síťové sondy chodící v protokolu SIP a z nich usuzovat, na jakých adresách portech se dají očekávat RTP a RTCP pakety. Celou situaci navíc komplikuje fakt, že vše musí probíhat co nejrychleji. Za tímto účelem vznikla entita rtptable uložená ve stejnojmenném souboru. Jedná se o hashovací tabulku, která pro výpočet hashe používá číslo portu. Na každé pozici má uložen spojovaný seznam struktur rtptable_item_t (viz výpis 4.12), který obsahuje IP adresu a port, na nichž lze očekávat RTP pakety, a dále počet odkazů count a ukazatele na struktury rtp_data_t a rtcp_data_t. typedef struct rtptable _item_struct { /* Either IPv4 or IPv6 destination address : */ rtp_node_t rtp_node ; /* Destination port : */ uint16_t port ; /* Number of links pointing to this record ( number of * inserts + number of running RTP streams ): */ uint16_t count ; /* Pointer to RTP data record : */ rtp_data_t * rtp_data ; /* Pointer to RTCP data record : */ rtcp_data_t * rtcp_data ; /* Next item ( linear list ): */ struct rtptable_ite m_struct * next ; } rtptable_item_t ;
Výpis kódu 4.12: Struktura rtptable_item_t. Tabulka rtptable se plní během zpracování protokolu SIP. Pokud se objeví SIP paket, který obsahuje IP adresu a porty pro RTP data, vloží se do tabulky. Pokud záznam v tabulce již existuje, dojde jen ke zvýšení hodnoty počítadla odkazů. Ve chvíli, kdy se SIP tok odstraňuje z flow cache, dochází i k vymazání záznamu v rtptable. Pokud je hodnota počítadla odkazů vymazávaného toku větší než 1, dojde pouze ke snížení hodnoty počítadla. Tento mechanismus zajišťuje, že se nebudou v tabulce hromadit staré porty, ale zároveň se žádný port nesmaže, dokud na něj vede alespoň jeden odkaz. Při detekci RTP nebo RTCP paketu dochází nejprve ke kontrole prvních dvou bitů, zda mají hodnotu 10. Pokud ne, paket se ihned zamítá. V opačném případě se zkontroluje, zda paket míří na sudý nebo lichý port. Pokud je číslo portu liché, nastaví se příznak RTCP paketu a číslo se o jedničku sníží. V rtptable se totiž ukládají pouze čísla portů protokolu RTP. Protokol RTCP používá port vždy o jedničku vyšší, proto není důvod tuto informaci explicitně ukládat. Následně se provede hledání v hashovací tabulce. Pokud 55
4. Programové vybavení síťové sondy se nepodaří najít žádný záznam se shodnou IP adresou a portem, paket se zamítá. V opačném případě se předává ukazatel na nalezenou položku v rtptable a vrací se typ paketu (pokud není nastaven příznak RTCP, jedná se o RTP paket a naopak). Jak již bylo řečeno, struktura rtptable_item_t obsahuje mimo jiné i odkazy na struktury rtp_data_t a rtcp_data_t. Pokud je paket identifikován jako protokol RTP nebo RTCP a ukazatel na odpovídající strukturu je prázdný, znamená to, že se jedná o první paket toku. V tom případě se vytvoří nová struktura rtp_data_t resp. rtcp_data_t a uloží se do tohoto ukazatele. Zároveň se ukazatel na ni uloží také do privátních dat pluginu ve flow recordu. Tím se z paketu stává RTP nebo RTCP paket. Dále dochází ke zvýšení hodnoty počítadla odkazů ve struktuře rtptable_item_t. To je nutné proto, aby záznam v rtptable zůstal i v případě, že se z flow cache již odstranily všechny SIP toky, které na něj odkazují. Aby záznam nezůstal v rtptable věčně, je třeba registrovat callback funkci flow_destroyed_rtp_callback, která jej odstraní (nebo sníží počet odkazů) ve chvíli, kdy flow cache opouští RTP tok, do něhož patří právě analyzovaný paket. Samotný rozbor RTP a RTCP paketů je již poměrně jednoduchý a provádí se v souboru rtp.c. Při analýze protokolů stačí jen přetypovat paket na příslušnou datovou strukturu a poté přečíst potřebná data. Pokud se jedná o složený RTCP paket (obsahuje víc zpráv za sebou), poznáme to podle toho, že délka dat paketu je větší než délka přiložené struktury. V tom případě stačí celý postup opakovat tak dlouho, dokud zbývají k přečtení nějaká data. 4.2.5 Agregace paketů Dosud byla řeč jen o zpracování jednotlivých paketů, nicméně tok se skládá málokdy jen z jednoho paketu, a proto je potřeba pakety v toku agregovat tak, aby se uložilo co nejvíc informací. O agregaci paketů se stará funkce update(), která řeší odděleně spojování SIP, RTP a RTCP paketů. Pokud se stane, že ve flow cache ještě nejsou uloženy žádné informace o SIP toku, zkopírují se všechny informace z nově příchozího paketu. Agregace nastává ve chvíli, kdy má u sebe nějaké informace jak tok ve flow cache, tak nově příchozí paket. V tom případě se provede sečtení SIP statistik a případně i aktualizace polí SIP_INVITE_RINGING_TIME, SIP_OK_TIME a SIP_BYE_TIME pokud stále ještě hodnotu nula. Pokud nově příchozí paket obsahuje informaci o RTP portech, prohazuje se tento údaj s informací, která je uložena ve flow cache. Důvodem je fakt, že každý SIP flow record má na sobě navázánu callback funkci, která uvolňuje 56
4. Programové vybavení síťové sondy nejen strukturu sip_data_t, ale i data z rtptable z paměti. Pokud by se údaj o RTP portech pouze zkopíroval z nově příchozího paketu, ihned po skončení agregace by došlo k uvolnění tohoto paketu z paměti a s ním by se zrušil i příslušný záznam v rtptable. Prohozením záznamů se dosáhne nejen zachování nového záznamu v rtptable, ale také odstranění starého záznamu, který byl až dosud uložen ve flow cache. Agregace RTP a RTCP provozu se provádí už ve filtrační funkci, zatímco ve funkci update se pouze předávají odkazy na data v případě, že první paket toku nebyl rozpoznán jako RTP resp. RTCP. Důvodem je fakt, že zejména RTP paketů chodí na síti velké množství, a proto by nebylo efektivní pro každý z nich alokovat novou strukturu rtp_data_t a ihned po agregaci paketů ji opět uvolňovat. Struktura rtp_data_t se proto vytváří jen pro první paket toku a odkaz na ni se ukládá do rtptable. Pokud dojde při analýze paketu k nalezení jeho IP adresy a portu v rtptable, získáme automaticky také ukazatele na struktury rtp_data_t a rtcp_data_t. Agregace dat ve filtrační funkci se proto přímo nabízí. Samotný proces agregace RTP a RTCP dat je poměrně jednoduchý. U protokolu RTCP obnáší sčítání sumárních statistik (počty přenesených paketů a oktetů), počítání průměru u hodnoty rozptylu a výběr maximální hodnoty u počtu zdrojů. U protokolu RTP je třeba průběžně počítat rozptyl paketů podle vztahu 2.1. Aby mohl proběhnout výpočet rozptylu korektně, je třeba znát frekvenci RTP hodin, která se vypočítá podle typu kodeku. Rozšíření process-voip sice neumí pracovat s dynamicky definovanými kodeky, ale podporuje 35 standardních kodeků [5]. U hovorů používajících dynamicky definovaný kodek se výpočet rozptylu neprovádí.
57
Kapitola 5
Programové vybavení kolektoru Součástí této diplomové práce není jen sběr dat o VoIP komunikaci, ale také jejich zpracování a vizualizace. Tyto úkony probíhají na kolektorové části navrženého systému. Pro vizualizaci nasbíraných dat byl vytvořen rozšiřující modul VoIP Explorer, který lze nainstalovat jak na sondu s vestavěným kolektorem, tak i na dedikovaný kolektor společnosti INVEA-TECH.
5.1
Instalace programu ipfixcol
Zařízení společnosti INVEA-TECH standardně používají pro příjem a ukládání NetFlow dat program nfcapd, jehož podpora vlastních polí v protokolu IPFIX je bohužel poměrně omezená. Proto byl pro účely diplomové práce použit volně šiřitelný kolektor ipfixcol, který tímto nedostatkem netrpí. Pro ukládání dat bylo zvoleno úložiště FastBit, které ipfixcol nativně podporuje. Program ipfixcol lze zdarma stáhnout ze stránek sdružení Liberouter1 , nicméně jeho instalace na zařízení FlowMon postavených na systému CentOS 5 je poměrně komplikovaná. Proto doporučuji použít již hotové balíčky, které je možné najít na přiloženém CD v adresáři bin/ipfixcol-centos5. V tomtéž adresáři se nachází i návod na jejich snadnou instalaci. Kolektor nepotřebuje žádnou složitou konfiguraci, pouze je nutné povolit na firewallu port 4739/UDP a v souboru /etc/ipfixcol/elements.xml definovat pole exportovaná pluginem process-voip, aby je kolektor dokázal rozpoznat a uložit. Syntaxe je popsána přímo v konfiguračním souboru, identifikátory polí jsou uvedeny v tabulce 4.1. Podobnou úpravu je zapotřebí udělat také v souboru /usr/share/fbitdump/fbitdump.xml. Ukázky upravených konfiguračních souborů je možné najít rovněž na přiloženém CD v adresáři conf. Pokud se vše podaří správně nastavit, bude možné zobrazit toky rozšířené o VoIP položky pomocí příkazu na výpisu 5.1. Více informací o 1. https://www.liberouter.org/ipfixcol/
58
5. Programové vybavení kolektoru práci s programem fbitdump je možné najít na jeho manuálové stránce. Seznam podporovaných formátovacích řetězců je definován v souboru /usr/shar/fbitdump/fbitdump.xml. fbitdump -R / data / ipfixcol -o sip "% voiptype > 0"
Výpis kódu 5.1: Zobrazení VoIP dat pomocí programu fbitdump.
5.2
Integrace vlastního rozšíření do FlowMon GUI
Zařízení společnosti INVEA-TECH používají pro svou správu webové rozhraní, které se skládá ze dvou základních částí. První z nich tvoří tzv. frontend, což je webová aplikace napsaná v jazyce Javascript. Jejím hlavním úkolem je poskytnout uživatelsky přívětivé prostředí pro konfiguraci zařízení a vizualizaci dat. Frontend používá populární javascriptové knihovny jQuery 2 , Underscore 3 a dále sadu knihoven napsanou přímo pro vývoj webového rozhraní FlowMon. Druhou částí je tzv. backend implementovaný jako webová aplikace v jazyce PHP založená českém MVC frameworku Nette4 . Backend přijímá požadavky od frontendu a dále je zpracovává (například aplikuje změny nastavení, které uživatel zadal ve frontendu apod.). Obě části spolu komunikují prostřednictvím HTTP požadavků, ve kterých přenáší data ve formátu JSON5 . Zdrojové kódy webového rozhraní se nachází v adresáři /var/www a jsou rozděleny do přehledné struktury odpovídající zvyklostem Nette. Kořenový adresář WWW serveru tvoří pouze podsložka /var/www/shtml, díky čemuž jsou ostatní adresáře skrz webové rozhraní nedostupné. Toto opatření zvyšuje bezpečnost systému. Ukázku struktury adresáře /var/www je možné vidět obrázku 5.1. Backendová část uživatelského rozhraní je uložena ve složce /var/www/app, která je dále rozdělena na jednotlivé funkční celky (moduly). Například adresář /var/www/app/FccModule odpovídá FlowMon konfiguračnímu centru apod. Každý modul se dělí na modely, presentery a šablony, které odpovídají standardním součástem MVC frameworku. Modely se starají o tvorbu a zpracování dat, zatímco šablony o jejich správné zobrazení. Presentery tvoří mezivrstvu spojující modely a šablony. 2. 3. 4. 5. na
Knihovna jQuery dostupná na adrese http://jquery.com. Knihovna Underscore dostupná na adrese http://underscorejs.org. Framework Nette je dostupný na adrese http://nette.org. JSON (JavaScript Object Notation) je populární formát výměny dat. Více informací http://www.json.org.
59
5. Programové vybavení kolektoru Frontendovou část uživatelského rozhraní lze najít v již zmíněném adresáři /var/www/shtml. Kromě obrázků a kaskádových stylů ve složkách /var/www/shtml/img a /var/www/shtml/css ji tvoří zejména javascriptové části jednotlivých modulů v adresáři /var/www/shtml/js/app. /var/www ....................Kořenový adresář uživatelského rozhraní app ..................... Zdrojové kódy backendové části aplikace. FccModule ..................Dílčí moduly backendové aplikace. models presenters templates FmcModule HomepageModule locale ....................Soubory s překlady webového rozhraní. log ...................................Adresář pro ukládání chyb. shtml ..........................Kořenový adresář WWW serveru. css ........................ Kaskádové styly webových aplikací img ............................... Obrázky webových aplikací fcc fmc homepage js ....................................Javascriptová část GUI. app ................. Skripty pro konkrétní webové aplikace. fcc fmc fwk .......................Základní stavební prvky aplikací. lib .............................................Knihovny. utils ................... Doplňující skripty pro různé účely. index.php ..........Soubor index.php – vstupní bod aplikace. temp ....................... Adresář pro dočasné soubory a cache. Obrázek 5.1: Adresářová struktura webového rozhraní FlowMon. Při psaní vlastního rozšiřujícího modulu nejprve vytvoříme jeho backendovou část, kterou umístíme do adresáře /var/www/app/*Module (hvězdičku nahradíme jménem modulu). Nette framework provádí automaticky tzv. routování požadavků, což je proces, při kterém se vybírá obslužný kód pro daný požadavek. Pokud se modul jmenuje například VoipModule, pak bude přístupný na URL /voip a všechny požadavky začínající touto cestou bude obsluhovat právě tento modul. Podobným způsobem funguje routování i mezi 60
5. Programové vybavení kolektoru jednotlivými presentery. Tento proces je standardní součástí Nette a nebudu se mu dále věnovat, protože je popsán v oficiální dokumentaci na stránkách frameworku [9]. Vazbu mezi frontendovou a backendovou částí pluginu tvoří šablony v adresáři /var/www/app/*Module/templates, které generují pro daný modul, presenter a akci výslednou HTML stránku. Protože frontendová část rozhraní je založena převážně na Javascriptu, většina těchto šablon se používá hlavně pro definici HTML kontejnerů, do nichž se pak umísťují javascriptové komponenty a formuláře z adresáře /var/www/shtml/js/app. Tvorba rozšiřujícího modulu je poměrně komplexní záležitost, která nespadá do kompetencí této diplomové práce, a proto se jí nebudu dále věnovat. Podrobná příručka o psaní rozšiřujících modulů pro zařízení FlowMon je dostupná členům Community programu společnosti INVEA-TECH, do kterého je možné se bezplatně registrovat na stránkách společnosti https://www.invea.com.
5.3
VoIP Explorer
VoIP Explorer je rozšiřující modul pro grafické rozhraní zařízení FlowMon, který umožňuje vizualizovat data získaná pluginem process-voip popsaným v kapitole 4.2. Zatím se jedná spíše akademickou prací demonstrující funkčnost navrženého řešení, nicméně splňuje všechny náležitosti rozšiřujících modulů společnosti INVEA-TECH, a proto je možné z něho v budoucnu vytvořit samostatný volně dostupný balíček pro zařízení FlowMon.
Obrázek 5.2: VoIP Explorer na rozcestníku FlowMon. Zdrojové kódy pluginu se nachází na přiloženém CD v adresáři src/gui. Instalace VoIP Exploreru je velmi snadná, protože stačí jen zkopírovat obsah 61
5. Programové vybavení kolektoru zmíněného adresáře do složky /var/www a do databáze PostgreSQL na cílovém zařízení přidat odkaz na plugin. Podrobný postup instalace je uveden v souboru src/gui/INSTALL. Po dokončení instalace se rozšíření objeví na úvodní obrazovce uživatelského rozhraní FlowMon (obrázek 5.2). Rozšiřující modul má mimo jiné následující funkce: •
Výpis zachycených toků s grafickým znázorněním těch, které se týkají VoIP provozu.
•
Nalezení souvisejících toků, které se týkají jednoho hovoru.
•
Zobrazení podrobností o telefonním hovoru – SIP URI volajících stran, délka hovoru, kvalita (počet ztracených paketů a jejich rozptyl).
•
Zobrazení seznamu posledních hovorů.
VoIP Explorer nabízí dvě základní zobrazení dat: Prvním z nich je Výpis toků, který ukazuje seznam toků podobně jako FlowMon Monitorovací Centrum, ale navíc u každého z nich zobrazuje rozšířené informace získané pluginem process-voip. Druhé zobrazení se nazývá Poslední hovory a dává k dispozici prostý výpis telefonních hovorů seřazený od nejnovějších telefonátů až po ty nejstarší. V obou režimech výpisu je možné kliknutím na příslušný řádek tabulky zobrazit podrobné informace o hovoru. 5.3.1 Výpis toků Po kliknutí na záložku Výpis toků se zobrazí filtrační formulář, v němž je možné zadat časové rozmezí a maximální počet toků, které chce uživatel zobrazit. Důležitým polem je FastBitDump filtr, kam se zadávají filtrační kritéria za použití syntaxe programu fbitdump6 . Ve filtru lze samozřejmě používat pole exportovaná pluginem process-voip, jejichž aliasy se definují v souboru /usr/share/fbitdump/fbitdump.xml. Výchozí filtr (%voiptype > 2) zobrazuje pouze toky protokolu SIP týkající se telefonních hovorů a dále toky protokoů RTP a RTCP. Po kliknutí na tlačítko Zobrazit data se zobrazí požadovaný výpis obsahující mimo základních informací také SIP URI volajícího a volaného, port použitý pro přenos RTP dat a u protokolu RTP použitý kodek. Toky týkající se VoIP komunikace jsou navíc barevně odlišeny. Více informací lze zobrazit kliknutím na odkaz ve sloupci VOIP packet type. Ukázka výpisu toků je vidět na obrázku 5.3. 6. Syntaxi programu fbitdump lze najít na jeho manuálové stránce (man fbitdump).
62
5. Programové vybavení kolektoru
Obrázek 5.3: VoIP Explorer – výpis toků. 5.3.2 Poslední hovory Ke každému telefonnímu hovoru se váže vždy několik toků. Pokud chceme analyzovat jeden problémový hovor, může být pro tento účel zobrazení na úrovni toků nepohodlné. Zobrazení Posledních hovorů se snaží inteligentně filtrovat toky tak, aby se každý každý hovor zobrazil maximálně jednou. Možnosti filtrace jsou omezené pouze na čas a délku výpisu. Seznam se navíc řadí sestupně, takže se poslední hovory objevují hned na jeho začátku. Po kliknutí na telefonní hovor se zobrazí jeho podrobnosti včetně všech toků, které se hovoru týkají. Ukázku zobrazení posledních hovorů je možné vidět na obrázku 5.4.
Obrázek 5.4: VoIP Explorer – poslední hovory.
63
5. Programové vybavení kolektoru 5.3.3 Podrobné informace o hovoru Nejzajímavější částí rozšíření VoIP Explorer je vyhodnocování naměřených VoIP dat, které se provádí automaticky po kliknutí na libovolný SIP nebo RTP tok. Aby mohlo dojít k vyhodnocení hovoru, je zapotřebí nejprve najít všechny toky, které se ho týkají. Klíčovým pojítkem je zde pole SIP_CALL_ID, které se ukládá u každého SIP toku a společně s časem, IP adresami a porty identifikuje všechny toky hovoru. Použitý postup má několik dílčích kroků: 1.
Pokud je zvolen RTCP tok, sníží se čísla portů o jedničku a použije se postup pro hledání podle RTP toku v bodu 2.
2.
Pokud je zvolen RTP tok, musí se najít SIP tok, který má čas začátku jen o málo menší než vybraný RTP tok, a navíc má v poli SIP_RTP_IP4 nebo SIP_RTP_IP6 cílovou IP adresu RTP toku a v poli SIP_RTP_AUDIO nebo SIP_RTP_VIDEO cílový port RTP toku. Poté se použije postup pro hledání podle SIP_CALL_ID v bodu 3.
3.
Najdou se všechny toky, které mají požadovanou hodnotu v poli SIP_CALL_ID, a navíc jsou nejblíže času začátku hledaného toku.
4.
Z nalezených toků se zjistí IP adresy a porty, na nichž by se mohly nacházet RTP případné toky.
5.
Udělá se nový výběr. Tentokrát je kritériem buď hledané pole SIP_CALL_ID nebo IP adresa a port některého z potenciálních RTP toků zjištěných v předchozím kroku. Získaný seznam se seřadí podle času začátku toku.
6.
Projde se seznam nalezených toků a hledají se v něm SIP toky obsahující metody INVITE a BYE. Pokud se některý RTP tok objeví před odesláním první zprávy INVITE nebo po zprávě BYE, je ze seznamu odstraněn, protože nemůže být součástí hovoru. Totéž platí i pro RTCP toky. Seznam v této podobě se uloží a na konci vyhodnocení se zobrazí uživateli.
7.
Seznam se projde znovu a hledají se SIP toky. Pokud se nenajde žádná zpráva INVITE, je hovor prohlášen za chybný a vyhodnocení končí.
8.
Pokračuje se v procházení seznamu a hledá se ve statistikách zpráva CANCEL. Pokud se najde, je hovor prohlášen za zrušený dříve, než ho volaný účastník stačil přijmout, a vyhodnocení končí.
64
5. Programové vybavení kolektoru 9.
Pokračuje se v procházení seznamu a hledá se možná odpověď na SIP zprávu INVITE. Pokud se nenajde, je hovor prohlášen za chybný a vyhodnocení je u konce. V opačném případě se z této odpovědi určí výsledek hovoru – v případě stavového kódu 200 se jedná o přijatý hovor, v případě stavu 486 se jedná o odmítnutý hovor apod. Zároveň se ukládají i časy jednotlivých akcí – například čas začátku zvonění telefonu, čas přijetí hovoru atd.
10.
Pokračuje se v procházení seznamu a hledá se zpráva BYE. Pokud se najde, přidá se do statistik délka hovoru (čas mezi stavovou zprávou 200 OK a zprávou BYE) a informace o tom, který z účastníků hovor ukončil. V opačném případě se vypíše varování o nekorektním konci hovoru.
11.
Seznam se projde znovu a hledají se toky protokolů RTP a RTCP. Pro oba směry (tj. k volajícímu i k příjemci hovoru) se provádí součet toků, součet ztracených paketů a průměrování rozptylu. Pokud pro některý směr chybí RTP nebo RTCP toky, vypíše se varování.
12.
Vypíší se souhrnné statistiky a data se zobrazí v přehledném formuláři.
Na obrázku 5.5 je vidět formulář zobrazující podrobnosti o hovoru. Nahoře jsou uvedeny informace získané výše uvedeným postupem, zatímco uprostřed se nachází tabulka zobrazující všechny toky, které se týkají analyzovaného hovoru. Po kliknutí na některý ze záznamů v tabulce se ve spodní části formuláře zobrazí podrobné informace o zvoleném toku. Tento výpis je možné použít například pro ruční zkoumání hovoru, neboť jsou v něm uvedeny i statistiky počtu jednotlivých SIP zpráv, které byly v rámci toku odeslány.
65
5. Programové vybavení kolektoru
Obrázek 5.5: VoIP Explorer – podrobnosti hovoru.
66
Kapitola 6
Zhodnocení a testy navržených pluginů Během psaní této práce se podařilo vytvořit a otestovat rozšíření pro FlowMon sondu a kolektor, která umožňují provádět podrobnou analýzu VoIP provozu. Jak již bylo řečeno v kapitole 3.3, většina konkurenčních produktů se vydává jiným směrem a zachytává celé pakety, které dále zpracovává. Během implementačních prací bylo prakticky ověřeno, že začlenění VoIP metrik do konceptu NetFlow je poměrně obtížné a nakonec se musí stejně zvolit jen určitá podmnožina dat, kterou bude umět sonda zpracovat a odeslat na kolektor. To je asi hlavní důvod, proč se ostatní výrobci tomuto řešení vyhýbají. Pokud se ovšem množina exportovaných statistik zvolí správně, mohou být tyto informace vítaným rozšířením spektra dat, která síťové toky nabízejí.
6.1
Agregace statistik a dělení toků
Jak již bylo řečeno, největším problémem je otázka, kam uložit data získaná analýzou protokolu SIP. Zpracované pakety se totiž agregují do jednoho toku a jeho pole pro popis VoIP metrik mají omezenou kapacitu. Vzniklou situaci je možné řešit dvěma způsoby: •
Přidáním agregovaných polí.
•
Rozdělením jednoho toku na dva.
Při implementaci rozšiřujícího modulu process-voip bylo zvoleno kompromisní řešení: Každý tok může obsahovat nejvýše jeden hovor. Díky tomu nemůže nastat situace, kdy by například do polí SIP_CALLING_PARTY a SIP_CALLED_PARTY bylo potřeba uložit jména dvou různých volajících. Nicméně i tak SIP tok odpovídající jednomu telefonnímu hovoru obsahuje několik zpráv, které je zapotřebí agregovat. Aby nebylo nutné dělit tok na jednotlivé pakety, bylo do flow recordu přidáno pole SIP_STATS, které obsahuje počty některých často posílaných zpráv nebo stavových kódů. Nevýhodou tohoto přístupu je fakt, že se ztrácí 67
6. Zhodnocení a testy navržených pluginů informace o tom, v jakém se zprávy vyskytovaly pořadí. Navíc má toto pole jen omezenou kapacitu, takže se v praxi stává, že některé méně časté zprávy není kam přičíst, a proto zůstanou pozorovateli na straně kolektoru skryty. Dalším zvažovaným řešením bylo do pole SIP_STATS uložit přímo číselné kódy SIP zpráv ve stejném pořadí, jako byly přijaty. Stavové kódy protokolu SIP mají rozsah 100 – 606, takže pokud by se před uložením snížily o číslo 99, bylo by možné je uchovat na 9 bitech. To znamená, že by se do pole SIP_STATS vešlo celkem 7 stavových kódů. Pokud by se v jednom toku objevilo více než 7 stavových kódů, musely by se další stavové zprávy zahazovat a nebo by došlo k rozdělení toku. Pokud bychom chtěli kterýkoliv z uvedených postupů rozšířit, je možné přidat další 64bitové pole pro uložení statistik. Dle mého názoru je však správnější navrhnout efektivnější způsob uložení dat. Například stavové kódy protokolu SIP mají mezi sebou poměrně velké rozestupy, takže je určitě možné najít zobrazení, které mapuje číselný prostor stavových kódů do pouhých 6 – 8 bitů. Na základě analýzy toků, které v testovacím období vyprodukoval rozšiřující modul process-voip, se jeví jako nejvhodnější řešení kombinace obou předchozích přístupů. Servisní komunikace (tj. SIP zprávy jiné než INVITE, ACK, CANCEL a BYE) produkuje větší množství zpráv s poměrně nezajímavým obsahem a navíc se toky nerozdělují podle pole SIP_CALL_ID. Proto je pro ni vhodnější sčítat nejčastější stavové kódy (například počet neúspěšných přihlášení k SIP proxy může snadno přesáhnout číslo 7 a není nutné kvůli nim vytvářet nový tok). Naopak u telefonních hovorů je pořadí zpráv podstatné a navíc ne každá SIP proxy používá například při odmítnutí hovoru stejný stavový kód, a proto by bylo lepší zaznamenávat pořadí a konkrétní čísla zpráv, i když jen v omezeném množství.
6.2
Měření výkonu
Po skončení implementačních prací bylo provedeno měření výkonu sondy. Cílem bylo zjistit, o kolik se sníží výkon FlowMon Exportéru se zapnutým rozšířením process-voip. Benchmark byl proveden na testovacím stroji s 2 GB RAM a procesorem Intel Xeon běžícím o frekvenci 3 GHz. Test nebyl prováděn přímo na fyzické síťové kartě, data se předávala FlowMon Exportéru ze souboru PCAP. Výhodou tohoto přístupu je fakt, že při všech testech pracoval program nad identickými daty. Na druhou stranu ale není možné předpokládat, že bude výkon na reálné síti stejný. Výkon Exportéru nebyl stálý, což připisuji aplikacím, které běžely v době testu na pozadí. Proto byl každý testovaný scénář 68
6. Zhodnocení a testy navržených pluginů třikrát zopakován a níže uvedené hodnoty jsou vždy průměry ze tří po sobě jdoucích testů. Byly vyzkoušeny celkem tři případy užití a každý z nich byl testován zvlášť na krátkých a dlouhých paketech. Výkon Exportéru byl odečítán z jeho ladících výpisů v pravidelných časových intervalech a prvních osm výsledků bylo použito pro výpočet průměru. Krátké pakety (maximálně 128 B) Test na krátkých paketech měří rychlost rozpoznání paketů a zpracování jejich hlaviček. •
Výkon Exportéru bez rozšíření process-voip. 5 054 351 paketů/s, 100 %
•
Výkon Exportéru s rozšířením process-voip a se zapnutou optimalizací rozpoznávání SIP paketů. 3 669 176 paketů/s, 72,6 %
•
Výkon Exportéru s rozšířením process-voip a s vypnutou optimalizací rozpoznávání SIP paketů. 3 579 749 paketů/s, 70,8 % 6M 5M
Pakety/s
4M 3M 2M 1M
Vzorek
1
2
3
Základní detekce SIP
4
5
6
Optimalizovaná detekce SIP
7
8 Bez VoIP
Obrázek 6.1: Test výkonu rozšíření process-voip na krátkých paketech.
69
6. Zhodnocení a testy navržených pluginů Dlouhé pakety (maximálně 1 kB) Test na dlouhých paketech se více blíží reálné situaci a testuje zejména rychlost flow cache. •
Výkon Exportéru bez rozšíření process-voip. 3 494 762 paketů/s, 100 %
•
Výkon Exportéru s rozšířením process-voip a se zapnutou optimalizací rozpoznávání SIP paketů popsanou v kapitole 4.2.2. 2 624 947 paketů/s, 75,1 %
•
Výkon Exportéru s rozšířením process-voip a s vypnutou optimalizací rozpoznávání SIP paketů popsanou v kapitole 4.2.2. 2 631 881 paketů/s, 75,3 % 4M 3,5 M 3M
Pakety/s
2,5 M 2M 1,5 M 1M 0,5 M Vzorek
1
2
3
Základní detekce SIP
4
5
6
Optimalizovaná detekce SIP
7
8 Bez VoIP
Obrázek 6.2: Test výkonu rozšíření process-voip na dlouhých paketech. Jak je vidět, rozšíření process-voip sníží rychlost Exportéru asi na 70 % jeho výkonu, což je nepatrně lepší než očekávaný výsledek. Pro zajímavost byl navíc testován účinek optimalizace rozpoznávání SIP paketů, která je popsána v kapitole 4.2.2. Jak je vidět, jistého efektu dosahuje pouze na krátkých paketech, zatímco u dlouhých paketů je její účinek tak malý, že zaniká ve vlivech testovacího prostředí. 70
Kapitola 7
Závěr Tato diplomová práce shrnuje znalosti potřebné k návrhu systému pro monitorování VoIP provozu na bázi síťových toků a zkušenosti získané jeho implementací. Motivací pro vznik první část práce, která se věnuje principu navazování telefonního hovoru a popisu při tom používaných síťových protokolů, bylo zejména mé vlastní zklamání z nedostatku ucelených informačních zdrojů na toto téma. Existuje sice řada článků o protokolu SIP, ale většina z nich končí u vysvětlení postupu navazování hovoru podle v RFC 3261 [2], který například za použití NATu vůbec nemusí fungovat. Pevně věřím, že minimálně tato část diplomové práce přinese užitek i dalším lidem, kteří se zajímají o principy telefonování přes internet. Po skončení obecného popisu VoIP komunikace předkládám základní informace o monitorování vysokorychlostních sítí pomocí NetFlow a věnuji se průzkumu současné situace v oblasti monitorovacích nástrojů zaměřených na VoIP. Jak už jsem v předešlých kapitolách několikrát zmiňoval, tato práce se od ostatních monitorovacích nástrojů liší tím, že provádí měření VoIP provozu na principu síťových toků. Následuje dlouhý popis architektury navrženého systému, charakteristika rozhraní zásuvných modulů pro FlowMon Exportér a ukázky některých zajímavých algoritmů, které jsem při psaní práce použil. V závěru práce se věnuji hodnocení implementovaného systému a vysvětluji, jakým směrem by se nechal dále vylepšovat. V diplomové práci se mi podařilo vytvořit funkční prototyp systému pro měření VoIP komunikace, který už v současné podobě poskytuje poměrně zajímavé výstupy. V budoucnu bych jej rád otestoval na dalších sítích a vylepšil agregaci stavových kódů. Pevně věřím, že se rozšiřující modul process-voip brzy stane pevnou součástí zařízení FlowMon a bude poskytovat užitek správcům sítí na celém světě.
71
Literatura [1] ANDERSON, Sven, Saverio NICCOLINI a Dieter HOGREFE. SIPFIX: A scheme for distributed SIP monitoring. In: Integrated Network Management, 2009. IM ’09. IFIP/IEEE International Symposium [online]. 2009 [cit. 2014-01-06]. ISBN 978-1-4244-3486-2. Dostupné z: http://sven.anderson.de/publications/sipfix.pdf [2] RFC 3261. SIP: Session Initiation Protocol. Fremont, California, USA: The Internet Engineering Task Force, 2002. Dostupné z: http://www.ietf.org/rfc/rfc3261.txt [3] RFC 4566. SDP: Session Description Protocol. Fremont, California, USA: The Internet Engineering Task Force, 2006. Dostupné z: http://tools.ietf.org/html/rfc4566 [4] RFC 3550. RTP: A Transport Protocol for Real-Time Applications. Fremont, California, USA: The Internet Engineering Task Force, 2003. Dostupné z: http://www.ietf.org/rfc/rfc3550.txt [5] Real-Time Transport Protocol (RTP) Parameters. RTP Payload types (PT) for standard audio and video encodings. 18.9.2013. Dostupné z: http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml [6] STERMAN, Baruch a David SCHWARTZ. NAT Traversal in SIP. In: Deltathree VoIP Provider [online]. [cit. 2013-12-23]. Dostupné z: http://alliance.seas.upenn.edu/tcom502-wiki/uploads/Site/SIPNATtraversal.pdf [7] FlowMon - komplexní řešení monitorování sítě. INVEA-TECH – Highc 2007 — 2013 [cit. 2013Speed Networking and FPGA Solutions [online]. 12-28]. Dostupné z: https://www.invea.com/cs/products/flowmon [8] RFC 5101. Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information. 2008. Dostupné z: http://tools.ietf.org/html/rfc5101 72
7. Závěr [9] GRUDL, David. Nette Framework: Rychlý a pohodlný vývoj webových aplikací v PHP [online]. 2008 - 2014 [cit. 2014-01-04]. Dostupné z: http://nette.org [10] ITU-T G.107. The E-model: a computational model for use in transmission planning: SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS. Geneva: ITU Publications, 2012. Dostupné z: http://www.itu.int/rec/T-REC-G.107 [11] VoIPmonitor [online]. 2012 [cit. 2014-01-06]. Dostupné z: http://www.voipmonitor.org/ [12] VoIP monitor [online]. 2012 [cit. 2014-01-06]. Dostupné z: http://sourceforge.net/projects/voipmonitor/ [13] PRTG Network Monitor [online]. 2012 [cit. 2014-01-06]. Dostupné z: http://www.paessler.com/prtg/ [14] VoIP & WAN QoS Management Software [online]. 2012 [cit. 2014-0106]. Dostupné z: http://www.solarwinds.com/voip-network-quality-manager/voip-wanqos-management.aspx [15] IP Service Level Agreements. Cisco Systems, Inc. [online]. 2014 [cit. 2014-01-06]. Dostupné z: http://www.cisco.com/en/US/tech/tk920/tsd_technology_support_subprotocol_home.html c 2011-2012 [cit. [16] DUBOVIKOV, Alexandr. Homer Sipcapture [online]. 2014-01-06]. Dostupné z: http://www.sipcapture.org/ [17] DERI, Luca. Open Source VoIP Traffic Monitoring. In: Open Source VoIP Traffic Monitoring [online]. 2010 [cit. 2014-01-06]. Dostupné z: http://www.sane.nl/sane2006/program/final-papers/R3.pdf c [18] Ntop [online]. http://www.ntop.org/
1998-2014
[cit.
2014-01-06].
Dostupné
z:
73
Příloha A
Význam jednotlivých bitů v polích SIP_STATS Pole SIP_STATS je svým typem 64bitové celé číslo, ale ve skutečnosti se skládá vždy z několika dílčích čísel, která obsahují počty zachycených SIP zpráv určitého typu. Mapování statistik se liší pro každý typ SIPového toku:
A.1 Typ 1: Servisní požadavky 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 INFO PUBLISH NOTIFY SUBSCRIBE OPTIONS REGISTER
A.2 Typ 2: Odpovědi na servisní požadavky 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 OK Bad Request Forbidden Internal Error Not Found Proxy Auth. Req. Unauthorized Trying
A.3 Typ 3: Požadavky týkající se hovoru 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 CANCEL ACK BYE INVITE 74
A. Význam jednotlivých bitů v polích SIP_STATS
A.4 Typ 4: Odpovědi na požadavky týkající se hovoru 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 OK Busy Here Ringing Decline Dialog Establ. Session Progress Proxy Auth. Req. Trying
75
