Well SIP-T26P - nejde se na nej dovolat (NAT?)

[tuxmartin]

Dobry den,

pred casem jsem tady na foru resil schovani IP telefonu za VPN.
Nyni mam rozbehnuty IPsec VPN server a u kazdeho pracovnika mikrotik, ktery dela IPSec vpn klienta a za nim VoIP telefon.

Bohuzel jsem byl nuceny pouzit stare uz nakoupene telefony Well SIP-T26P.

Touto dobou uz to cele melo fungovat a doufal jsem, ze budu resit s Odorikem nakup SIP trunku.
Jenze je problem se dovolat

Zde je schema site:

sip_ipsec.png (48.1 KiB) Zobrazeno 4781 x

Z telefonu A ve stejne LAN se sip serverem se na telefon B za VPN a naty NEdovolam.
Ze telefonu B se vsak na telefon A zavolat da. Tipuju to na problem natu.

Po nabootovani mikrotiku a telefonu B vidim ve webadminu telefonu B, ze byl uspesne pripojen k SIP serveru. Take v asterisku na SIP serveru vidim jeho uspesne pripojeni v logu.

Zkousel jsem na mikrotiku tri kombinace (vzdy s rebootem routeru):

Kód: Vybrat vše

/ip firewall service-port set sip ports=5060,5061 sip-direct-media=yes sip-timeout=01:00:00 disabled=no
/ip firewall service-port set sip ports=5060,5061 sip-direct-media=no sip-timeout=01:00:00 disabled=no
/ip firewall service-port set sip ports=5060,5061 sip-direct-media=no sip-timeout=01:00:00 disabled=yes

a nepomohlo to.

Podle https://mum.mikrotik.com/presentations/ ... 084451.pdf by mel byt v Mikrotiku treba NAT SIP helper - ale to je myslim prave "/ip firewall service-port set sip".

Jestli tu prednasku dobre chapu, tak mam spatnou IP v SIP hlavickach. Se vsemi kombinacemi "/ip firewall service-port set sip" mam porad vnitrni LAN IP u telefonu v hlavickach, jako je na obrazku vlevo:


Napada nekoho, co delam spatne a jak to vyresit?

Dekuji za pomoc!

[Kabek]

Nastavte expiraci registrace na telefonech místo 3600 na cca 100 sec., respektive na čas, při kterém zůstane NAT otevřený.

[xsouku04]

Problém s tím, co je v SIP hlavičách, určitě nebude. Tam bývají nesmysly naprosto běžně, protože prostě SIP nefunguje tak, jak jeho autoři plánovali. A to kvůli NATu, na který autoři tak nějak úplně zapomněli.
Komunikace se v praxi neposílá na ip adresy a porty uvedené v hlavičkách ale na ip adresu a port, odkud se telefon hlásí. Stejně tak RTP - zvuk. Prostě to, odkud pakety opravdu chodí, má vždy přednost před tím, co je napsáno v hlavičkách, a hlavičky se použijí, jen pokud druhá strana ještě nic neposílá.

Nerozumím tomu, kde přesně a proč je tam ten NAT. Není možné se díky ipsec NATU vyhnout tak, aby byly všechny telefony virtuálně v jedné lokální síti?

Průchod paketů přes NAT a registrace na dobu jako jedna hodina je možný díky NAT keep alive, kdy se cca každou minutu pošlou pakety jen proto, aby se průchod přes NAT udržel otevřený. Jedině tak může telefon začít zvonit, když někdo volá.
To keep alive může posílat telefon, ústředna nebo oba (zbytečné). Nejlepší je, když to posílá telefon.
Máte na telefonu nastaveno, aby posílal keep alive pakety?

Pokud je telefon dovolatelný cca minutu po restartu, kromě zapnutí keep alive je možné zkrátit expiraci registrace také na tu cca minutu nebo nepatrně méně. Pomůže tohle?

Řešením by také mohlo být místo UDP použít TCP. TCP spojení obvykle drží i bez posílání keep alive paketů, navíc otevřené spojení by měly ctít všechny prvky po cestě.

Co se týče různých NAT helperů a SIPu tomu je lepší se vyhnout. Jmenuje se to SIP ALG a je to záškodník k ničemu. Může to být i důvod, proč to nejde. Je dobré nic takového nepoužívat.
Co se týče NAT helperů pro IPsec, s tím nemám žádnou zkušenost. Obecně pokud potřebuje nějaký protokol NAT helper, je zpravidla špatně navržen.

Tedy vše funguje až na to, že telefony jsou nedovolatelné? A to vždy nebo až po nějaké době? Pokud by to bylo keep alive, tak by měl být telefon vždy nedovolatelný až po několika desítkách sekund po registraci, kdy se uzavře NAT.

A opravdu se mu snaží Asterisk poslat INVITE, nebo se na to vykašle ani to nezkusí? Tato funkce "vykašlat se ani to nezkusit" se Asterisku nazývá qualify. Pokud telefon neodpovídá na keep alive pakety (třeba proto, že k němu vůbec nedojdou) a nebo je zpoždění příliš velké, tak je Asterisk ani nezkouší volat a rovnou to vzdá. Bylo by proto dobré se podívat, jestli se INVITE vůbec pošle.
Jak ladit SIP přímo z asterisku nebo příkazové řádky je zde: http://forum.odorik.cz/viewtopic.php?f=29&t=3513

[Kabek]

"Keep alive" v některých sítích při použití protokolu UDP nemá očekávaný efekt, nevím proč. Zřejmě je to otázka konfigurace NATu jako takového. U některých telefonů Well je tato funkce schovaná pod názvem (překladem) "Zpráva pro ověření UDP". Vždy je třeba nastavit kratší čas než je platná doba otevření NATu.
Ještě jeden poznatek. U Well (Yealink) telefonů a Panasonic KX-TGP500 keep alive je funkční pouze při protokolu UDP. Je-li zapnut TCP a expirace je dlouhá (obvyklých 3600 s.), nastavení keep alive nezajistí průchodnost přes NAT. Pak je nezbytné nastavit expiraci registrace na kratší dobu, aby se nezavřel NAT. Rovněž z vlastní zkušenosti doporučuji nastavit port na příchodu na libovolné číslo mimo 5060 - 5070 nebo rozsah portů s vyloučením uvedených.
Tolik moje postřehy a zkušenosti. Možná Vám to pomůže.

[alfi]

Řešením by také mohlo být místo UDP použít TCP. TCP spojení obvykle drží i bez posílání keep alive paketů, navíc otevřené spojení by měli ctít všechny prvky po cestě.

Taky bych zkusil TCP nebo ještě lépe TLS - různé SIP helpery na routerech pak do provozu nevidí a nemění jej. I TCP timeouty pro NAT bývají delší (ani jsem nečekal, že výchozí TCP hodnota je až takhle dlouhá)

Kód: Vybrat vše

nf_conntrack_tcp_timeout_established - INTEGER (seconds)
	default 432000 (5 days)
nf_conntrack_udp_timeout - INTEGER (seconds)
	default 30

viz https://www.kernel.org/doc/Documentatio ... sysctl.txt