Helló! Bocs, hogy ide beírok, de az én problémám is kapcsolódik ide. Telekom telepített pár cisco ip phone 303 készüléket és érdekes módon a vonal 3-5 perc telefonálás után megszakad. Router egy cisco (linksys) RV042 vpn router. Azért ez a router van mert van egy másik telephely ahol van szintén egy RV042 és a 2 telephely között vpn kapcsolat van. Valaki találkozott ilyen hibával? Telekom azt mondja biztos a helyi hálóban van a hiba. Most addig eljutottam, hogy az egyik routert kicseréltem egy mezei tp-linkre amivel nem produkálja a hibát. Nem hinném, hogy egy ilyen egyszerű routerrel megy másikkal meg nem? Köszi Zoli
2017. augusztus 21. 22:17 Sándor Fehér írta, < [email protected]>: > >szerintem a kliens-kliens forgalmat nem tereled vpn-be, ez a hiba, igy a > kovetkezo ket dolog tortenik. > Ez kizárt, a push redirect gateway opció van használatban a > "client-to-client" mellett. > Traceroute, speedtest és szerver oldalon iptraf programokkal megerősítve. > > >szoval szerintem nezd at a klienseid IP cimeit, hogyan kapcsolodnak > egymashoz, ellenorizd tcpdumppal, hogy milyen cimrol milyen cimre megy az > RTP, valoban ervenyre jut-e a directmedia (vagy ezzel ekvivalens > beallitas). mert ertem en, hogy a beallitas ott van es ugy >kellene > mukodnie, de lassunk bizonyitekot, hogy valoban ugy is mukodik. > Szerintem a freepbx os (gányolt centos 7) lesz a ludas. >>> nagy kalap xar > az egész, véleményem szerint, mert semmi nem úgy működik benne, mint valami > normális debian/ubuntu -ban. > > MEGUNTAM a szórakozást: > Feltelepítettem a debian 8.8 -at és manuális telepítéssel ráraktam a > freepbx gui-t ma délután. >>> egy kicsit pilótavizsgás a történet :) > > Szerintem igazad volt mindvégig a router/tűzfal hibával, ugyanis a > freepbx os gyári tűzfala enyhén szólva is xar és ezért telepítettem fel az > egészet a debian-ra. > pl: az állapotok felismerése igencsak nem jól működik (-m state > established/related , iptables-nél) > > Debian alatt most egyelőre úgy tűnik, hogy MINDEN OK. > Köszönöm a segítséget! > > > > > 2017. 08. 21. 13:09 keltezéssel, [email protected] írta: > >> On 2017-08-19 16:51, Sándor Fehér wrote: >> >>> Amit legutobb lattam, abban konkretan directmedia volt a beallitas neve >>>> >>> A freepbx os-t használom, asterisk 13. verzióval ( latest v.13.17.0) >>> A freepbx nem teszt különbséget a reinvite és directmedia lehetőség >>> között, a kettő ugyanaz. >>> Az exten-ek nél és a gyökérben, a sip.conf -ban is globálisan tiltva >>> van a "reinvite/directmedia" ezt most le is ellenőriztem újra. >>> >>> >> vegigolvastam megint. ertem, hogy a beallitas megvan, a tcpdump is ezt >> mutatja? >> >> Amugy az eredeti problema mi volt? >>>> >>> Van két sp3102 : A és B >>> "A" hívó ( sip/11 "caller") és "B" hívott ( sip/12 "callee") >>> Ha "A" hívja "B" -t a kapcsolat kiépül, csörög "B". A hívás fogadás is >>> sikerül és "A" hangja hallható "B" -nél, de "B" nem tud beszélni "A" >>> val. :) 10 másodprec elteltével, pedig a hívás megszűnik magától. >>> >> >> nem derult ki, hogy ezek egy halozatban vannak-e. a multkori leveledben >> frankon lerajzoltad ascii-ban a telefonkozpont fele meno utat, de igazabol >> nem azzal van gondod, hanem a kliensek fele meno forgalommal - azt viszont >> nem rajzoltad le. >> >> tcpdump: a hívás kiépül rendesen, majd vpn-en KÍVÜL mennek/mennének az >>> rtp csomagok ( udp 10.000 és udp 20.000 között). Ha kikapcsolom a >>> >> >> felteszem ez a direkt forgalom a kliensek kozott. az, ami az elso >> bekezes szerint ki van kapcsolva, tehat ennek a szerver ip cimere kellene, >> hogy menjenek. >> >> de ha arra mennenek, akkor nem tudnanak a vpn-en kivul menni, hiszen ez >> L4 forgalom, a vpn pedig L3-ban van. >> >> >> tűzfalat, akkor jó a hívás mindkét irányban és nem szakad le a hívás, >>> de NEM vpn-ben zajlik a kommunikáció( rtp csomagok) >>> >> >> ez normalis mukodes, pontosabban mindket fele a mondatnak normalis >> mukodes egy hibas beallitas eseten. >> >> szerintem a kliens-kliens forgalmat nem tereled vpn-be, ez a hiba, igy a >> kovetkezo ket dolog tortenik. >> >> 1) a tuzfal meg ha tudna is intelligens lenni, es 'related' forgalomnak >> felismerne az RTP streamet, nem tudja, mert titkositottan megy a >> hivasfelepites, igy nincs mihez tarsitani az RTP-t. vagy ez, vagy primitiv >> a tuzfal es nem tudja akkor sem a kettot osszerendelni, ha a >> hivasfelepitest meg latna is. >> >> 2) mivel az RTP stream egyiranyu, az egyik fel megunja a timeout utan es >> lebontja a kapcsolatot szabalyos SIP uzenetetkkel. ebben semmi rendkivuli >> nincs, ez kovetkezmeny, nem ok. es nyilvan, ha a tuzfal nincs a kepben, >> megy a titkositatlan RTP stream, hiszen routing problemad van, nem vpn es >> nem tuzfal. >> >> A vpn "routed"-ként van konfigurálva és NEM "bridge" ként. >>> >>> ez mind rendben, de csak a kliens-szerver kapcsolatra fokuszalsz, a >> beszelgetes pedig kliens-kliens a leirasod alapjan >> >> Az új vlan segítségével egy új hálózati interfészt hoznák létre, ami >>> >> hoznek, de mindegy. szoval szerintem egy eleg egyszeru vpn konfiguralasi >> / routing hibad van, kar lenne ezt tovabb bonyolitani. >> >> szoval szerintem nezd at a klienseid IP cimeit, hogyan kapcsolodnak >> egymashoz, ellenorizd tcpdumppal, hogy milyen cimrol milyen cimre megy az >> RTP, valoban ervenyre jut-e a directmedia (vagy ezzel ekvivalens >> beallitas). mert ertem en, hogy a beallitas ott van es ugy kellene >> mukodnie, de lassunk bizonyitekot, hogy valoban ugy is mukodik. >> >> ha valoban csak vpn es routing hiba, aug 31-en (varhatoan nem modosul a >> datum) a kovetkezo eloadasban pont ilyesmiket fogok reszletezni. >> >> udv >> adam >> >> >> _______________________________________________ >> Techinfo mailing list >> [email protected] >> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo >> Illemtan: http://www.szag.hu/illemtan.html >> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/ >> > > > _______________________________________________ > Techinfo mailing list > [email protected] > Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo > Illemtan: http://www.szag.hu/illemtan.html > Ügyfélszolgálat FAQ: http://sulinet.niif.hu/ >
_______________________________________________ Techinfo mailing list [email protected] Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo Illemtan: http://www.szag.hu/illemtan.html Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
