>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/
