Úvod do konfigurace Expressway serverů

Konfigurace Business-to-Business Communications

Stručný seznam kroků, pro nastavení B2B, je uveden v kapitole Deploy Business-to-Business Communications příručky Cisco Preferred Architecture for Enterprise Collaboration 10.x. Základní popis konfigurace je v příručce Cisco Expressway Basic Configuration Deployment Guide (Cisco Expressway Series - Configuration Guides).

Konfigurační objekty pro nastavení směrování komunikace

Začínáme ve stavu, kdy máme funkční telefonii s jedním nebo více Cisco Unified Communications Manager (CUCM). K tomu máme připravené dva Expressway servery, jeden interní ExpC a jeden v DMZ ExpE. Jde o tři samostatné systémy, mezi kterými zatím není definována žádná komunikace. Naším úkolem nyní je, definovat tuto komunikaci tak, aby bylo možné na zařízení (telefonu) registrovanému k CUCM zadat IP adresu externího videokonferenčního zařízení a došlo ke spojení hlasem i obrazem. Opačně chceme umožnit zavolat na nějakou naši veřejnou IP adresu a tento videohovor směrovat na jedno určité zařízení.

Nejprve si stručně a obecně popíšeme, co potřebujeme definovat, a jaké konfigurační objekty k tomu využijeme.

Jako první vytvoříme spojení mezi oběma Expressway servery, to se provádí pomocí Traversal Zone. Těchto Zone můžeme vytvořit více a pomocí Search Rule určíme, jaký provoz se má kam směrovat. V případě potřeby můžeme přidat (Pre-search) Transform, která provede určitou modifikaci cílového aliasu (volané adresy, čísla). Transformace se provádí dříve, než se použije Search Rule. Pomocí globálního nastavení určíme, jak se má systém chovat k neznámým IP adresám. Obecně se označuje nastavení Presearch Transforms, Search Rules, DNS Search Rules a směrování externích IP adres jako Dial Plan. Vytáčecí plán definuje směrování (chování systému k určitému aliasu) na nějakou zónu.

Podobně vytvoříme spojení ExpC a CUCM pomocí Zone na straně Expressway a Trunk na CUCM. Pomocí Route Pattern určíme, jaké hovory se mají posílat do tohoto Trunku na straně CUCM. A pomocí Search Rule nastavíme směrování na ExpC.

Schéma konfigurace

Osobně mám, pro pochopení či zaznamenání nějakého systému nebo procesu, nejraději obrázky. To, co chceme nyní konfigurovat, je určité workflow definující chování systému na určitý vstup. Na začátku mi dělalo dost problém pochopit, jak Expresway funguje a jaké jsou vztahy mezi jednotlivými konfiguračními částmi. V jedné prezentaci jsem zahlédl krásný a přehledný diagram, který konfiguraci popisoval. Formát diagramu jsem si trochu upravil, aby mi více vyhovoval, a použil k zaznamenání konfigurace.

Níže je tedy můj pokus graficky popsat konfiguraci, kterou budeme dále provádět. Není to úplně přesné, protože ve skutečnosti dochází ke zpracování objektů v daném pořadí (transformace, vyhledávání, přechod na zónu a na ní vyhledávání aliasu). Transforms i Search rules se zpracují všechny podle nastavené priority, takže diagram neukazuje postup zpracování. Ale myslím, že tak člověk získá slušnou představu o probíhající komunikaci a jejím řetězení.

Propojení Expressway serverů

Začneme konfigurací Expressway serverů, kdy vytvoříme jejich propojení a nastavíme směrování určitých hovorů. Důležité je také myslet na bezpečnost, aby někdo nemohl zneužít náš systém a volat na drahá telefonní čísla. Tomu se budeme věnovat v závěru.

Konfigurace Traversal Zone

Na ExpE nejprve vytvoříme uživatele, kterým se budeme připojovat z ExpC. Konfigurace v Configuration - authentication - local database - třeba uživatel expe-auth

Traversal Zone definuje propojení mezi Expressway-C (Traversal client zone) a Expressway-E (Traversal server zone), vytváříme na obou serverech v Configuration - Zones - Zones. Určujeme použité protokoly, porty a další parametry.

Protokol H.323 většinou nepotřebujeme, pouze zkontrolujeme, že na ExpE máme povolen Configuration - Protocols - Interworking. Expressway pak funguje jako brána, která překládá hovory mezi SIP a H.323. ExpE může přijímat hovory SIP i H.323, ale H.323 dovnitř překládá na SIP, takže uvnitř sítě můžeme udržovat pouze jeden protokol.

Jméno zóny můžeme volit například Traversal Zone for B2B a volíme typ Traversal client. Na ExpE zadáme připraveného uživatele, na ExpC zadáme i jeho heslo. Používáme protokol SIP, defaultní port 7001, TLS (v tomto případě může být bez ověření certifikátu), další hodnoty můžeme ponechat ve výchozím stavu. Jako Location Peer na ExpC zadáme veřejné DNS jméno ExpE serveru, které se ale překládá na DMZ adresu interního rozhraní (popsáno v minulém díle).

Po vytvoření zóny dojde ke kontrole komunikace, pokud již máme vytvořeny zóny na obou Expressway a povolenu komunikaci na Firewallu (což si popíšeme až na konci článku), tak by měl být stav (State) Active a vidíme zde různé informace.

Konfigurace Traversal Zone Search rule

Vytvořili jsme propojení mezi Expressway servery, které povolí komunikaci určitým protokolem. Nyní musíme určit, jaký provoz se má do tohoto spojení posílat. Definujeme tedy pravidlo - Search rule, které zařídí směrování hovoru do vytvořené Traversal Zone. Na obou serverech vytváříme (v tomto případě) vzájemné směrování všech aliasů (volaných čísel a adres, toto nastavení neřeší IP adresy).

Configuration - Dial plan - Search rules

Jméno můžeme zadat Traversal zone B2B search rule, defaultní priorita 100 (nižší číslo se zpracovává dříve), protokoly musíme volit oba (i když jsme H.323 nepovolili v Traversal Zone, tak teprve po vyhledání dojde k převodu na SIP), Mode můžeme dát Any alias (to znamená vše mimo IP adresy), pokud dojde ke shodě tohoto pravidla, tak se nepokračuje s dalšími On successful match rovno Stop, tedy pokud by alias nebyl nalezen skrze tuto cestu, tak již nevyzkouší jinou, pokud je alias nalezen, tak se nikdy nepokračuje dalším pravidlem, a jako cíl Target zvolíme naši Traversal Zone for B2B.

Doplněno: Časem jsem narazil na to, že můžeme vyhledávání ještě omezit pouze na komunikaci přicházející skrze určitou zónu. Jde o položku Source, kterou můžeme nastavit na Named a pak v Source name zvolit zónu. Na ExpC můžeme nastavit Neighbor zone to CUCM, tedy pouze volání, která přijdou z CUCM (tuto zónu budeme teprve vytvářet). A na ExpE zvolit Default zone, ta obsahuje příchozí volání, která nepatří do žádné existující zóny, tedy zde příchozí hovory z internetu. Na ExpE také můžeme nastavit, aby se na ExpC neposílaly všechny aliasy, ale pouze ty, které budeme dále posílat na CUCM, tedy třeba aliasy s naší doménou. Nastavíme Mode na Alias pattern match, Pattern type na Suffix a Pattern string na @firma.cz.

Konfigurace External (Unknown) IP Address Routing

Máme definované základní spojení mezi ExpE a ExpC. Naším cílem je dovolat se na veřejnou (externí) IP adresu, proto nyní určíme chování serverů k cizím IP adresám. Jde o jednoduché nastavení, které definuje, jak se mají směrovat hovory na externí IP adresy. To jsou adresy, které Expressway nezná a považuje za veřejně směrovatelné adresy. Na ExpC nastavíme nepřímé směrování, a pomocí Search rule definujeme, že vše odchází na ExpE. Pro ExpE určíme přímé směrování, takže se pokusí spojit přímo na danou IP adresu.

Configuration - Dial plan - Configuration

Ke globálnímu nastavení musíme na ExpC přidat Search rules, která posílá všechny IP adresy do Traversal zone směrující na ExpE.

Configuration - Dial plan - Search rules

Doplněno: Také zde můžeme nastavit Source na Neighbor zone to CUCM.

Propojení Expressway a CUCM

Pokračujeme s konfigurací propojení ExpC a CUCM a nastavení potřebných směrování. Odchozí hovory na IP adresu směrujeme přes Expressway, příchozí hovory posíláme na CUCM. Popis je v oficiální příručce Cisco Expressway SIP Trunk to Unified CM Deployment Guide (Cisco Expressway Series - Configuration Guides).

Konfigurace Expressway-C

Nejprve provedeme konfiguraci na straně Expressway serveru v pár krocích. Musíme vytvořit zónu, vyhledávací pravidlo a pak nějaké transformace.

Vytvoření Neighbor Zone pro CUCM

Podobně, jako pro propojení Expressway serverů, se napojení na další systém, v tomto případě Cisco Unified Communications Manager (CUCM), provádí pomocí zóny. Jde o typ Neighbor Zone a vytváříme ji na ExpC. Musíme se rozmyslet, zda pro komunikaci využijeme šifrované spojení pomocí TLS (defaultní port 5061) či pouze TCP (defaultní port 5060). Aby mohlo nastat méně problémů, tak zde nejprve využijeme TCP.

Jméno zóny můžeme volit například Neighbor zone to CUCM. Používáme protokol SIP, defaultní port 5060, transportní protokol TCP, další hodnoty můžeme ponechat ve výchozím stavu. Jako Location Peer zadáme IP adresu či DNS jméno jednoho nebo více CUCM serverů. Pokračujeme do sekce Advanced, kde zvolíme Zone profile Custom (pro CUCM 9 a vyšší). A přepneme Call signaling routed mode na Always, ostatní necháme v defaultu.

Configuration - Zones - Zones

Konfigurace Neighbor Zone Search rule

Jak již víme, tak musíme k vytvořené zóně definovat provoz, který do ní budeme posílat. Nemůžeme posílat všechny aliasy, ale pouze ty, které mají přicházet. Ty můžeme určit například pomocí SIP adresy s naší doménou firma.cz (tedy třeba 100@firma.cz) a v pravidle využít Suffix @firma.cz. Kvůli bezpečnosti můžeme i přesněji vybírat provoz, třeba pouze tříčíselné linky pomocí Regexu (\d{3})@firma.cz nebo pouze jedno číslo (viz popis příchozích hovorů na IP adresu dále) pomocí Exact 100@firma.cz.

Doplněno: Můžeme nastavit omezení na Source na Traversal Zone for B2B, aby se pravidlo uplatnilo jen na hovory přicházející z ExpE.

Transformace aliasu číslo@IP-adresa-CUCM na číslo@firma.cz

Odchozí hovory z CUCM na Expressway používají formát číslo@IP-adresa-CUCM pro volající adresu (nepoužívají doménu). Když se hovor vrací zpět, tak potřebujeme tento alias standardizovat a převést na podobu domény (pak zafunguje Search rule pro směrování na CUCM). Definujeme Transform na ExpE, třeba s názvem Transform CUCM IP address to domain name využívající Regex (.*)@10.5.0.[2|3]((:|;).*)? převádějící na \1@firma.cz\2.

Transformace aliasů na SIP URI - konzistentní URI formát

Pro směrování používáme aliasy číslo@firma.cz, pokud v příchozím hovoru není obsažena doména, ale pouze číslo, tak počítáme, že jde o správný hovor k nám a doménu doplníme (případně můžeme řešit pouze čísla z našeho rozsahu, apod.). Vytváříme na ExpE, jméno třeba Add domain where none exists, Regex ([^@]*) přepisující na \1@firma.cz.

Pozn.: Transformace se uplatňují na odchozí i příchozí hovory. V našem případě jsou zatím odchozí hovory pouze na IP adresu a transformace se na IP adresy neuplatňují, takže nám toto pravidlo nepokazí volání na IP adresy.

Konfigurace CUCM

Další nastavení je na straně Cisco Unified Communications Manager (CUCM), kde musíme vytvořit Trunk a směrování.

SIP Profile

V Device - Device Settings - SIP Profile zkontrolujeme, že existuje Standard SIP Profile For Cisco VCS

Nastavení Region video bitrate

System > Region Information > Region

Zde se nachází omezení na maximální datový tok, což nastavuje maximální možné rozlišení videa. Defaultně je nastavena dost nízká hodnota. Otevřeme region (ten který používáme, i když je v něm nastaveno Use System Default, tak to nemusí brát z Regionu Default) a nastavíme Maximum Session Bit Rate for Video Calls na 6000 kbps. Potvrdíme Save, Apply Config.

Nastavení FQDN pro CUCM cluster

Aby se mohl využít SIP formát adres (adresa@firma.cz), a v případě CUCM clusteru, aby Expressway mohl posílat komunikaci na všechny členy, tak potřebujeme definovat Fully Qualified Domain Name (FQDN).

V System - Enterprise parameters najdeme sekci Clusterwide Domain Configuration a zde nastavíme Cluster Fully Qualified Domain Name.

Zvětšení limitu na velikost SIP zpráv

Pro video se používají větší zprávy než pro audio, takže ve většině případů potřebujeme navýšit maximální povolenou velikost SIP zprávy.

V System - Service Parameters, zvolíme primární server a Cisco CallManager(Active), klikneme na tlačítko Advanced a v sekci Clusterwide Parameters (Device - SIP) nastavíme hodnotu SIP Max Incoming Message Size na 11000.

Konfigurace SIP Trunk Security Profile

System - Security - SIP Trunk Security Profile

Zkontrolujeme, že existuje Non Secure SIP Trunk Profile, případně vytvoříme nový Non Secure SIP Trunk Profile For VCS. Důležitý je TCP port, standardně 5060 (nastavujeme jej na ExpC), pokud jej používáme pro MRA, tak musíme použít jiný.

Vytvoření SIP Trunk

Device - Trunk

Vytvoříme nový Trunk, který nám CUCM napojí na ExpC. V sekci SIP Information zadáme IP adresu (nebo FQDN) ExpC, zvolíme náš SIP Trunk Security Profile a SIP Profile

Vytvoření Route Pattern

Stejně jako jsme na Expressway serveru určovali, pomocí Search rule, jaký provoz se má poslat do zóny směrující na CUCM, tak musíme na CUCM serveru definovat provoz, který má odejít na Trunk směrující na ExpC. K tomu se využívá Route Pattern. Pomocí Expressway chceme do internetu směrovat volání na zadané (vytočené) IP adresy.

CUCM nepodporuje vytáčení IP adres, takže na připojených zařízeních (telefonech) musíme použít nějaký alternativní zápis. Zde budeme IP adresu vytáčet jako řetězec *1*2*3*4, proto musíme vytvořit nový Route Pattern *.!*!*!*!. Mohli bychom použít také tvar 1*2*3*4 nebo třeba 1.2.3.4@ip, ale v obou případech by byl problém s rozlišením interní linky a jejich vytáčení by se zpomalilo, protože by se uplatnil InterDigit Timeout.

Call Routing - Route/Hunt - Route Pattern

Zadáme Route Pattern *.!*!*!*! a jako Gateway/Route List vybereme Trunk-Expressway, v sekci Called Party Transformations zvolíme Discard Digits na PreDot pro odstranění úvodní hvězdičky.

Odchozí hovory na IP adresu

Pro odchozí hovory máme téměř vše připravené. V minulém bodě jsme si popsali, že na CUCM nelze vytáčet přímo IP adresy, takže se IP adresa nějakého vzdáleného videokonferenčního zařízení musí vytáčet alternativním zápisem. Zvolili jsme náhradu teček hvězdičkami a pro rychlejší zpracování přidali hvězdičku i na začátek. Na ExpC se tedy volání dostane s cílovým aliasem 1*2*3*4. Expressway již s IP adresami normálně pracuje, takže nejjednodušší je provést transformaci aliasu na IP adresu.

Transformace řetězce 1*2*3*4 na IP adresu

Na ExpC potřebujeme vytvořit transformaci aliasu, aby se přicházející volání z CUCM, při volání IP adresy ve tvaru 1*2*3*4, převedlo na 1.2.3.4. Pro transformaci využijeme regulární výraz. Pro přesnější popis volaný alias přichází z CUCM jako SIP adresa, kde CUCM doplňuje IP adresu ExpC a port, takže to vypadá sip:1*2*3*4@10.0.0.100:5060. Naše transformace zajistí i odstranění zavináče a všeho dále.

Configuration - Dial Plan - Transforms

Pravidlo můžeme pojmenovat Transform to modify * to . for IP address dialing a použijeme pattern (\d{1,3})\*(\d{1,3})\*(\d{1,3})\*(\d{1,3})(.*) a nahrazení replace \1\.\2\.\3\.\4.

Tím bychom měli mít hotovo vše pro odchozí volání na veřejnou IP adresu.

Příchozí hovory na IP adresu

Přípravu pro zpracování příchozích hovorů jsme již provedli, když jsme definovali Search rule, která směrují hovory do zóny z ExpE na ExpC a z ExpC na CUCM. Nyní chceme řešit situaci, aby bylo možno zavolat naši veřejnou IP adresu (která je na externím FW směrována na ExpE) a hovor byl směrován na určité zařízení (třeba videokonferenční místnost), což znamená linku (či SIP adresu). Realizace je velice jednoduchá (ale můžeme ji použít pouze pro jedno zařízení).

Na ExpE nakonfigurujeme Fallback alias, takže se pak volání na IP adresu nebo doménové jméno Expressway převedou na tento zadaný alias, může jít o číslo nebo SIP URI. Ostatní již máme nastavené, takže se tento hovor dostane až na CUCM a ten spojí patřičné zařízení.

Configuration - Dial plan - Configuration

Zabezpečení (zablokování) přístupu na ISDN bránu (do PSTN) - ochrana proti toll-fraud

Dříve, než povolíme připojení Expressway do internetu, musíme celé prostředí dobře zabezpečit proti zneužití. V praxi mi během pár dnů začaly útoky s pokusem o volání na speciálně zpoplatněná zahraniční čísla skrze moji infrastrukturu. A i když jsem si na počátku myslel, že mám hovory hodně omezené a tímto způsobem mne nemohou ohrozit, tak se to jednou povedlo. Útoky jsou vidět v logu stále a pravidelně, i když jsou všechny tyto hovory hned odmítnuty.

Je tedy potřeba dobře nastavit směrování, aby se až na CUCM nedostaly hovory, které jsou na veřejná telefonní čísla. Ten je totiž standardně začne spojovat skrze ISDN či SIP bránu (přesněji podle naší topologie). V konfiguraci výše jsme používali nejjednodušší řešení, kdy jsou všechny aliasy směrovány dále dovnitř sítě, takže tento útok může proběhnout.

Máme řadu možností, jak bezpečnost řešit. Můžeme například upravit Traversal Zone Search Rule, aby se neuplatňovala na Any alias, ale pomocí regulárního výrazu definovat pouze interní čísla/SIP adresy. Nebo můžeme vytvořit novou Search Rule, která bude blokovat adresy, které by CUCM směroval mimo firmu. Například, když vytáčená čísla mimo firmu musí začínat 0, tak takové aliasy nepřijmeme.

Cisco popisuje příklad zabezpečení v příručce Cisco Expressway Basic Configuration Deployment Guide (Cisco Expressway Series - Configuration Guides), kapitola Task 14: Restricting Access to ISDN Gateways (optional).

V další kapitolce si popíšeme toto řešení, které uvádí Cisco v příručce. Když jsem dále studoval různé možnosti zabezpečení, tak jsem narazil na Call Policy, které mi přijdou pro aktuální požadavky mnohem lepší. Umožňují opravdu odmítnout hovor a ne jej směrovat na nesmyslný alias. Takže to uvádí kapitola následující.

Blokování čísel začínajících nulou pomocí Search Rule

Obecné (Cisco) doporučení je vytvořit dvě pravidla, která používají jako pattern stejný regulární výraz. První pravidlo nastavíme jako Source (zdroj) All zones, což povolí tato volání z lokálně registrovaných zařízení a také neighbor nebo traversal zones. Druhému pravidlu nastavíme Source Any, což zahrnuje také neregistrovaná zařízení, a zastavíme volání pomocí Replace string s hodnotou třeba do-not-route-this-call. Tedy vlastně alias, který se nedá zavolat, takže nedojde k jeho vyhledání. Nepřijde mi to moc ideální, čekal bych nějakou možnost přímo odmítnout hovor nebo blokovat. U obou pravidel nastavíme On successful match = Stop, aby se nepoužila další pravidla. Výsledkem je blokování těchto hovorů z venku, ale povolení například na zařízeních registrovaných k VCS. Otázka je, jestli v našem případě první pravidlo potřebujeme (zda takové hovory chceme povolovat nebo zda vůbec mohou existovat) nebo vystačíme pouze s druhým.

Regulární výraz může vypadat třeba (0\d+)(.*)(@firma.cz).

Blokování (odmítání) hovorů pomocí Call Policy

Blokování čísel začínajících nulou, stejně jako blokování libovolných jiných aliasů, které můžeme popsat regulárním výrazem, můžeme jednodušeji (a pro mnoho situací lépe) provést pomocí Call Policy Rules. Oficiální popis těchto nastavené je v příručce Cisco Expressway Administrator Guide (Cisco Expressway Series - Configuration Guides). Složité politiky můžeme definovat pomocí CPL souboru, což si ukážeme v další kapitole. Ale mnoho základních věcí můžeme nadefinovat pomocí jednoduchých pravidel Call Policy Rules.

Celou konfiguraci budeme provádět na ExpE, abychom příchozí hovory odmítali co nejdříve. Defaultně je využití Call Policy vypnuté a musíme jej tedy povolit. Menu Configuration - Call Policy - Configuration v Call Policy mode zvolíme Local CPL a klikneme na Save.

Potom již můžeme vytvářet pravidla. Můžeme volit akci Allow pro povolení dané komunikace a Reject pro odmítnutí. Jako Destination pattern zadáme regulární výraz pro volaný alias, pro předchozí příklad (0\d+)(.*)(@firma.cz). Volitelně můžeme použít Source pattern, který se ale použije pouze pro autentizované uživatele.

Configuration - Call Policy - Rules

Pomocí pravidel můžeme ošetřit řadu situací. Pravidla se uplatňují postupně odshora dolů, takže nahoru můžeme zadat nějaké povolené aliasy pomocí jednoho nebo více pravidel. A dolů umístit pravidlo, které odmítá vše (ostatní), Destination pattern .*. Přijde mi škoda, že nejde v pravidle určit, zda jde o příchozí nebo odchozí hovor. Stejně jako na jiných místech, se politika uplatňuje na všechna volání, takže musíme myslet i na naše odchozí volání (můžeme využít domény).

Call Policy file pro blokování nechtěného provozu

Na ExpC můžeme pomocí Call Policy zablokovat hovory, které přichází z CUCM a ExpC by je směroval zpět na CUCM jako veřejné volání. Využijeme k tomu textový XML soubor označovaný jako CPL (Call Process Language) soubor. Příklad z Cisco materiálů využívá jméno zóny Neighbor zone to CUCM, odkud přichází hovor, a cílový pattern 0.*.

<?xml version="1.0" encoding="UTF-8" ?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:taa="http://www.tandberg.net/cpl-extensions"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd">
<taa:routed>
  <taa:rule-switch>
    <!--Check that gateway is not hairpinning call - Neighbor zone -->
    <taa:rule originating-zone="Neighbor zone to CUCM" destination="0.*">
      <!-- Calls coming from the gateway may not send calls back out of this gateway -->
      <!-- Reject call with a status code of 403 (Forbidden) -->
      <reject status="403" reason="ISDN hairpin call denied"/>
    </taa:rule>
    <taa:rule origin=".*" destination=".*">
      <!-- All other calls allowed -->
      <proxy/>
    </taa:rule>
  </taa:rule-switch>
</taa:routed>
</cpl>

Tento soubor nastavíme na ExpC v Configuration - Call Policy - Configuration. Pomocí tlačítka Browse přidáme soubor z disku a klikneme na Upload file. Poté Call Policy mode nastavíme na Local CPL a uložíme.

Komunikace (porty a protokoly) a jejich povolení na Firewallu

Potřebné porty pro komunikaci docela podrobně popisuje oficiální příručka Cisco Expressway IP Port Usage for Firewall Traversal Deployment Guide (Cisco Expressway Series - Configuration Guides), přesto bych v ní uvítal nějaká podrobnější vysvětlení. Jsou zde popsány komunikace jak pro B2B, tak pro MRA. Já jsem se pokusil vytáhnout potřebné údaje pro zde řešený B2B příklad a níže souhrnně popsat. Samozřejmě záleží na použitých protokolech a aktuálních nastaveních na Expressway serverech.

Pozn.: Správné nastavení FW je samozřejmě zásadní a většina problémů může být zde. Mě po první konfiguraci fungovalo navázání hovoru, ale nepřenášela se média. Na FW jsem v logu rychle nalezl pokusy o komunikaci pomocí portů, které jsem zapomněl povolit. Poté jsem zjistil (podrobně jsem popisoval minule), že opravdu musím směřovat komunikaci na veřejnou adresu ExpE při využití jednoho rozhraní. Můj FW patrně podporuje to, čemu Cisco říká NAT Reflection. Ale musel jsem na něm (externí FW) povolit komunikaci z ExpC, aby odešla z firmy (na veřejnou adresu ExpE) a opět se vrátila z veřejné adresy (ale také z DMZ adresy ExpE, což úplně nechápu). FW mi špatně loguje provoz, který odchází a hned se vrací, takže mi ukazoval, že je povolen, i když byl blokován při příchodu.

V minulém díle jsme si popsali dvě možné topologie. Pro informaci si nejprve uvedeme schéma zapojení, kde má DMZ síť jeden subnet a ExpE je připojen pomocí jednoho síťového rozhraní (LAN1). Je zde naznačeno, že komunikace z ExpC jde na veřejnou adresu ExpE (a skrze externí FW prochází na tento server).

Dále se budeme věnovat doporučované topologii, která je zobrazena na následujícím schématu. DMZ síť máme rozdělenu na dva subnety a ExpE je připojen pomocí dvou síťových rozhraní. LAN1 směrem k internímu firewallu, a na toto rozhraní přichází komunikace z ExpC, a LAN2 směrem k externímu firewallu, zde je brána do internetu a také NATovaná veřejná adresa.

Obecně Cisco striktně doporučuje vypnout inspekci SIP a H.323 provozu na Firewallu, protože by mohl blokovat nebo nesprávně modifikovat určitý provoz (různé modifikace, hlavně v případě NATu, provádí ExpE).

Pozn.: Na Expressway serverech je užitečná vlastnost, podívat se na používané odchozí a příchozí porty, pomocí Maintenance - Tools - Port usage - Local inbound ports a Local outbound ports.

Dále si popíšeme jednotlivé typy komunikace, které musíme na FW povolit. Je to rozděleno do kapitol podle komunikujících systémů a směru komunikace (neřešíme zde komunikaci v interní síti, tedy ExpC a CUCM) a také dle protokolu.

Komunikace z ExpC na ExpE

Komunikace z interní sítě do DMZ mezi dvěma Expressway servery. Konfigurace, která je popsána v tomto článku, používá mezi ExpC a ExpE pouze SIP protokol. Pro informaci je zde popsán i H.323 protokol využívající Assent, ten můžeme přeskočit. Navíc, pokud nastavíme na Traversal zone využití H.460.18 místo Assent, tak jsou potřeba jiné porty.

Pozn.: V případě zapojení ExpE s jedním interfacem nesmíme zapomenout, že tato komunikace jde na veřejnou adresu, takže musíme nastavit nejen interní firewall, ale také externí (a tam povolit vše, co dále nepovolíme obecně z internetu, tzn. vše mimo UDP/36000-1).

SIP Traversal Call

• SIP signaling TCP/7001 (port nastavený na Traversal zone pro SIP)
• RTP/RTCP (media) UDP/36000-1 (nastavení v Configuration - Traversal Subzone) nebo UDP/2776-7 (nastavení v Configuration - Traversal - Ports)

H.323 Traversal Call pomocí Assent

• H.323 UDP/6001 (port nastavený na Traversal zone pro H.323)
• Q 931/H.225/H.245 TCP/2776 (nastavení v Configuration - Traversal - Ports)
• RTP/RTCP (media) UDP/36000-1 (nastavení v Configuration - Traversal Subzone)

Komunikace z ExpE do internetu (out)

Odchozí komunikace z DMZ do internetu, kde komunikuje Expressway server s externími servery nebo klienty. Tentokrát využíváme oba protokoly SIP i H.323. Ve zde popsané konfiguraci nepoužíváme TURN server, který je potřeba pro Interactive Connectivity Establishment (ICE), což se používá pro řešení problémů s NATem u SIP protokolu. Přesto je zde tato komunikace uvedena.

SIP call

• SIP signaling UDP/TCP >= 1024 (standardně UDP/5060)
• RTP/RTCP (media) UDP >= 1024
• TURN server media UDP >= 1024 (záleží na povolení ICE v Traversal zone)

H.323 call

• Q 931/H.225 signaling TCP >= 1024 (standardně TCP/1720)
• H.245 TCP >= 1024
• RTP/RTCP (media) UDP >= 1024

Komunikace z internetu na ExpE (in)

Příchozí komunikace z internetu do DMZ, kde komunikují externí servery nebo klienti s Expressway serverem. Opět používáme oba protokoly SIP i H.323 a opět je pro přehled uvedena i komunikace případného TURN serveru.

SIP call

• SIP signaling TCP/UDP/5060, TCP(TLS)/5061 (nastavení v Configuration - Protocols - SIP)
• RTP/RTCP (media) UDP/36002-59999 (nastavení v Configuration - Traversal Subzone)
• TURN server control UDP/3478 (záleží na povolení ICE v Traversal zone)
• TURN server media UDP/24000-24999 (záleží na povolení ICE v Traversal zone)

H.323 call

• Q 931/H.225 signaling TCP/1720 (nastavení v Configuration - Protocols - H.323)
• H.245 TCP/15000 - 19999 (nastavení v Configuration - Protocols - H.323)
• RTP/RTCP (media) UDP/36000-59999 (nastavení v Configuration - Traversal Subzone)

Problém s blokovaným příchozím RTP na FW

Narazil jsem na zvláštní problém při použití Microsoft Forefront Threat Management Gateway (TMG) a publikaci RTP portů na ExpE. Při některých hovorech se nenavázala příchozí média (nebyl vidět obraz). V logu TMG bylo vidět, že blokuje navázání spojení na některých RTP portech, ale jiné povoluje. Logovala se podivná chyba:

Status: You were not connected because a duplicate name exists on the network. If joining a domain, go to System in Control
 Panel to change the computer name and try again. If joining a workgroup, choose another workgroup name. 

Nakonec se ukázalo, že problém byl v definici UDP protokolu, kde se pro Publish Rule může použít pouze směr Receive a ne Receive Send.

Testovací videohovory

Abychom ověřili, že jsme vše správně nastavili a můžeme navázat audio-video hovor na veřejnou IP či SIP adresu (případně i obráceně hovor přijmout), tak je nejlepší provést zkušební hovor. Často nemusíme mít k dispozici jinou stranu, s kterou bychom test provedli. Pak se hodí veřejně dostupné testovací služby. Na internetu se dá nalézt řada takových systémů, které jsou dostupné pomocí IP adresy nebo SIP adresy. Některé jsem otestoval a pár, které mi vyhovovaly, uvádím níže.

Testovací servery

Polycom poskytuje řadu adres Video Test Numbers. Můžeme se připojit na LAN IP: 140.242.46.49, 140.242.46.50, kde je přehráváno video se zvukem.

Spoustu testovacích serverů nalezneme na stránce Verified Videoconferencing Test Sites: 2016 Edition. Je zde například zajímavý VTCTest pro protokol H.323 s IP 71.14.2.158, 71.14.2.157, který po připojení přehrává hlasové informace, po určité době zobrazí video a na konci provádí Callback pro ověření příchozího hovoru.

Další je Cisco Loopback Site, která podporuje protokol H.323 i SIP a volá se URI loopback@rtp.ciscotac.net.

Údaje o hovorech

Po provedení hovoru (nebo v jeho průběhu) si můžeme zobrazit řadu důležitých informací pro statistiky nebo řešení problémů. Třeba

• Status - Calls - Calls
• Status - Calls - History
• Status - Search history
• Status - Logs - Event Log