SIP-ALG

[yaro]

Zdravím,
chtěl bych se zeptat, jestli někdo ví, jak je to v routerech KLFREE s nastavením SIP-ALG?

Cituji:
Mnoho dnešních routerů používá funkci SIP ALG (application level gateway), která je ve výchozím stavu zapnuta. I když tato funkce může v mnohém pomoci při natování, v mnohých případech je implementována špatně a závažně poškozuje SIP.
ALG rozumí protokolu díky specifické aplikaci, kterou podporuje (v našem případě SIP) a provádí jeho kontrolu za provozu (při telefonování). Router s aktivním ALG tak může přepisovat informace v SIP zprávách, které odesílá Vaše VoIP zařízení. Přepíše je tak přímo mezi VoIP zařízením a ústřednou.
Hlavním problémem je právě chabá implementace v SIP protokolu většiny routerů na trhu a také skutečnost, že tato funkce by měla (!) být užitečná pro odchozí hovory, nikoli pro ty příchozí.


Diskuzní téma VOIP je v KLFREE už řadu let mrtvé, tak to píšu sem. VOIP používám dlouho, ale v posledních měsících je to fakt hrůza :-(
Trochu jsem pátral po netu a jedním z problémů by mohlo být právě používání SIP-ALG na routerech:
http://www.telefonujeme.cz/viewtopic.php?t=6450&postdays=0&postorder=asc&highlight=sipalg&start=0
Problémy údajně způsobují všechny značky routerů, včetně "značkových" od Cisca...

Asi to nikdo neřešil, ale jestli naše routery ten "prasič paketů" mají a je zapnutý, dalo by se to povypínat?

Dalším problémem údajně bývá connection tracking na routerech - tady jsem mimo mísu...
(má se vyřadit conntrack funkcionalita během bootu routeru, a zapínat conntrack funkcionalitu až po kompletní aktivaci NAT a veřejných IP adres)

[skudlik]

Take zdravim

1) SIP-ALG - mel by byt VYPNUTY na troufam si rict veskerych routerech klfree. Prave diky zminovanym problemum je to ZLO, kteremu je potreba se vyhybat. Na linuxu je to nastesti vec, kterou je potreba rucne zapnout, takze tolik problemu nehrozi (pokud by s tim vylozene nekdo nezacal experimentovat).

Hlavni domenou tady byvaji domaci routery clenu - "levne krabicky" kde naopak toto byva casto zapnute defaultne.. Coz ale predpokladam nebude tento pripad.

2) conntrack .. no tohle je bohuzel narozdil od predchoziho pruserova kapitola. Tady naopak muzu rici, ze conntrack je zapnuty (lepe rici neni rucne vypnuty) na vetsine routeru. Krome hlavniho nat routeru klfree (maggie), kde to samozrejme ani vypnout nejde, tak se pres to minimalne hlida pocet aktivnich spojeni z kazde IP adresy a blokuji se uzivatele s velkym poctem spojeni. S timhle byval problem zejmena v minulosti pri velkem boomu P2P siti a kdy odflakle udelany klienti otvirali obrovske mnozstvi spojeni. Tohle bylo potreba zarezavat co nejdrive = pri vstupu do site, takze conntrack = connection tracking zde byl nutnosti. Otazkou na teto obecne rovine je, jestli diky ustupu P2P siti by neslo toto taky vypustit..

Jinak teda co mam vysledovane (coby taktez uzivatel voipu), tak problemum tady dochazi pri ruznych vypadcich na siti (rozpad routovani, reboot nejakeho serveru cestou). IP telefon, aby si poradil s pruchodem skrz nat, tak pravidelne odesila svoje keep-alive pakety a udrzuje si tak zaznam v conntracku NATu ... Bohuzel v tomto pripade nejen primo na rozhrani klfree/internet, kde probiha NAT, ale i na vsech routrech cestou, kde se conntrack pouziva. Pak (aspon podle mych v tomto smeru temer laickych domenek - bez konkretnich dukazu) se v pripade vypadku "nekde" "nejak" na trase vytvori spatny zaznam v conntracku, a diky tomu, ze telefon i tento zaznam svedomite udrzuje pri zivote, tak bohuzel spojeni se SIP ustrednou prestane fungovat.... Jedinym resenim pak byva telefon vypnout, nechat nekolik minut vypnuty (aby vytimeoutoval ten zaznam), a po naslednem zapnuti vse funguje normalne ..

Vypadku bylo v posledni dobe docela dost (nekolik bourek a spol)....

Jelikoz zatim nikdo u nas na siti nevymyslel jak tohle globalne resit, tak muzu dat jen par rad, ktere by teoreticky mohly pomoci:
- napriklad u 802.cz neni myslim vubec nutne mit na telefonu zaplou funkci posilani keep-alive paketu kvuli natu (ruzne telefony tomu ruzne rikaji). Nevim jak jini poskytovatele, ale 802ka tomuhle pomaha i tim, ze ma nastaveny register interval na 60s, cimz pri techto pravidelnych registracich dochazi k udrzovani conntrack zaznamu na natu
- funkce nat-keep-alive telefonu vetsinou posila pakety v celkem kratkych intervalech = 10s a pod. coz je conntrackova smrt ) - viz timeouty dale.
- dat register interval na 60,  se jevi jako celkem vhodne i diky tomu, ze na klfree routerech (aspon tech linuxovych), je vychozi hodnota pro timeout udp zaznamu (pouziva sip), na 30s pro ty na ktere neprijde odpoved a 180s na zaznamy s odpovedi. Kdyz tedy telefon zkousi kazdych 60s registraci, tak je to tak akorat na to, aby ty zaznamy netimeoutovaly kdyz ustredna odpovida a naopak zmizely kdyz dojde k nejake chybe a pakety behaji tam kam nemaj.
- pokud telefon podporuje extra nastaveni nejakeho retry na register (v pripade neuspechu), tak tady nastavit take hodnotu kolem minuty - i tady kratsi cas by mohl vest k udrzovani chybneho conntrack zaznamu.

[scorpio]

Ahoj,

802.cz už změnil strategii a má Register každých 600s. Tedy je už nutné mít "KEEP ALIVE" zapnuté. Default v SIPURA / LINKSYS krabičkách je 15s.

Na Magii se kdysi dělala úprava, která dočasně shodila conntrack ze 180 na 10s (což je pod keepalive hodnotou), čekala na nahození NATu, načtení exportu z ISka a teprve po stabilizaci sítě vrátila conntrack na 180s.
Když to zafungovalo správně, tak to "vyléčilo" špatné záznamy všeho co se během restartu Maggie nakumulovalo, a tím to zprovoznilo Sipury bez nutnosti rekonfigurace či změny lokálního portu.

Netuším, zda tam tohle udělátko stále je, ani zda se zařazením nějakých těch "superchytrých" HW zařízení tohle nějak neobešlo, ale osobně jsem se zůčastnil testů zmíněného nějaký rok/dva nazpátek.

Pokud čerpáš informace z Telefonujeme.cz, tak tam jsem registrován pod stejným nickem jako tady, a spoustu zkušeností se správou NATu a CONNTRACK pochází ode mě a ze zkušeností na Magii.

A pokud se týká VoIP, používám ho roky a nějaké zásadní či nové problémy v posledních měsících řekněme nepociťuji. Může se to tedy týkat problémů nebo přetížení Tvého připojení.
Navíc, "problémy" jsou velmi široký pojem, když nenapíšeš nic bližšího tak Ti těžko někdo pomůže.