Porta 5060 bloccata (da chi?)
Fabio Napoleoni
risolvere. Su una macchina che fa da firewall/gateway per la rete
dell'ufficio i pacchetti udp sulla porta 5060 (telefonia voip) vengono
misteriosamente bloccati. Sulla macchina in questione è presente shorewall ma
la causa del blocco non è quella infatti anche disattivandolo completamente i
pacchetti si perdono misteriosamente. Ho controllato anche i
files /etc/hosts.allow ed hosts.deny e sono entrambi vuoti.
Ho fatto vari tipi di prove e da vari host con netcat e l'unica coppia
protocollo porta che non riesco a far funzionare e UDP/5060, con qualsiasi
altra coppia protocollo porta le due istanze di netcat comunicano senza
problemi.
Quale processo/file di configurazione può essere la causa del problema? Che
tipo di prove posso fare?
Grazie per l'aiuto.
--
Fabio Napoleoni
f.nap...@email.it
****************************************************************
"Computer Science is no more about computers than astronomy is
about telescopes"
Edsger W. Dijkstra
****************************************************************
Alessandro De Zorzi
> Salve a tutti, ho un problema di networking con etch che non riesco a
> risolvere. Su una macchina che fa da firewall/gateway per la rete
> dell'ufficio i pacchetti udp sulla porta 5060 (telefonia voip) vengono
> misteriosamente bloccati. Sulla macchina in questione è presente shorewall ma
> la causa del blocco non è quella infatti anche disattivandolo completamente i
> pacchetti si perdono misteriosamente. Ho controllato anche i
> files /etc/hosts.allow ed hosts.deny e sono entrambi vuoti.
>
o client voip configurati, su che porta si registrano su server?
*CLI> sip show peers
La cosa migliore è che si registrino su porte "alte" come 10006
in taluni casi la combinazione "misteriosa" di alcune ADSL e router
portano alla registrazione su 5060 a questo punto un client funzionicchia
al secondo non funziona una mazza perché i pacchetti che ritornano vanno
i conflitto se provengono dallo stesso IP.
Se il problema puoi cercare il modo di vincolare una porta riservata
diversa per ciascun client.
Alessandro
Fabio Napoleoni
> Fabio Napoleoni wrote:
> > Salve a tutti, ho un problema di networking con etch che non riesco a
> > risolvere. Su una macchina che fa da firewall/gateway per la rete
> > dell'ufficio i pacchetti udp sulla porta 5060 (telefonia voip) vengono
> > misteriosamente bloccati. Sulla macchina in questione è presente
> > shorewall ma la causa del blocco non è quella infatti anche
> > disattivandolo completamente i pacchetti si perdono misteriosamente. Ho
> > controllato anche i
> > files /etc/hosts.allow ed hosts.deny e sono entrambi vuoti.
>
> forse il problema non è il firewall, immagino tu abbia telefoni
> o client voip configurati, su che porta si registrano su server?
Il problema penso sia + a monte, nel senso che avendo fatto delle prove
dall'esito negativo con netcat credo che sia a livello network. Per questo
chiedevo se oltre alla configurazione di iptables ed ai files hosts.allow ed
hosts.deny esistono altri meccanismi di blocco su debian.
> *CLI> sip show peers
La configurazione di asterisk e dei client non l'ho fatta io, anche perchè non
sono esperto in materia e non saprei neanche quali sono i comandi da
utilizzare per verificare le impostazioni in questione.
> La cosa migliore è che si registrino su porte "alte" come 10006
> in taluni casi la combinazione "misteriosa" di alcune ADSL e router
> portano alla registrazione su 5060 a questo punto un client funzionicchia
> al secondo non funziona una mazza perché i pacchetti che ritornano vanno
> i conflitto se provengono dallo stesso IP.
>
> Se il problema puoi cercare il modo di vincolare una porta riservata
> diversa per ciascun client.
Questo potrebbe essere il passo successivo, anche se la vedo più come
soluzione d'emergenza.
Cmq grazie per la risposta.
Fabio Napoleoni
> > Quale processo/file di configurazione può essere la causa del problema?
> > Che tipo di prove posso fare?
> >
> > Grazie per l'aiuto.
>
> magari vedere poi con lsof quale processo utilizza quella porta...
Si e non c'è nessun processo in ascolto sulla porta in questione.
Jack Malmostoso
> Che
> tipo di prove posso fare?
# fuser -vvv tcp/5060
O qualcosa del genere, non mi ricordo la sintassi.
--
Best Regards, Jack
Linux User #264449
Powered by Debian GNU/Linux on AMD64
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Davide Corio
> Si e non c'è nessun processo in ascolto sulla porta in questione.
Client e server sono nella stessa rete? o remoti?
Molti provider chiudono la porta 5060 per obbligarti ad acquistare i
loro servizi
--
Davide Corio davide.corio<at>redomino.com
Redomino S.r.l. Largo Valgioie 14 - 10146 Torino - Italy
Tel: +39 011 7499875 - Fax: +39 011 3716911 http://www.redomino.com/
Fabio Napoleoni
> On Tue, 05 Jun 2007 18:30:08 +0200, Fabio Napoleoni wrote:
> > Che
> > tipo di prove posso fare?
>
> # fuser -vvv tcp/5060
>
> O qualcosa del genere, non mi ricordo la sintassi.
La sintassi è corretta, ma sembra funzionare solo su tcp, per farlo funzionare
su udp la sintassi è sembra essere
# fuser -n udp 5060
anche se sulla macchina dalla quale scrivo mi funziona, mentre da quella
server no, boh??
Di seguito un po di prove anche se cmq da quello che ho capito e che già
pensavo dall'output di netstat non c'è niente in ascolto su quella porta.
serveribm:/home/alex# netcat -lu -p 5060 &
[1] 16098
serveribm:/home/alex# netstat -uan | grep 5060
udp 0 0 0.0.0.0:5060 0.0.0.0:*
serveribm:/home/alex# fuser -v 5060/udp
serveribm:/home/alex# netcat -lu -p 5061 &
[2] 16102
serveribm:/home/alex# netstat -uan | grep 5061
udp 0 0 0.0.0.0:5061 0.0.0.0:*
serveribm:/home/alex# fuser -v 5060/udp
serveribm:/home/alex# fuser -vvvv 5060/udp
serveribm:/home/alex# killall netcat
debian-etch:/home/fabio# netcat -lu -p 5060 &
[1] 32355
debian-etch:/home/fabio# fuser 5060/udp
debian-etch:/home/fabio# fuser -v 5060/udp
debian-etch:/home/fabio# netcat -l -p 5060 &
[2] 32358
debian-etch:/home/fabio# fuser -v 5060/tcp
USER PID ACCESS COMMAND
5060/tcp: root 32358 F.... netcat
Fabio Napoleoni
> Il giorno mar, 05/06/2007 alle 19.11 +0200, Fabio Napoleoni ha scritto:
>> Si e non c'è nessun processo in ascolto sulla porta in questione.
>
> Client e server sono nella stessa rete? o remoti?
>
> Molti provider chiudono la porta 5060 per obbligarti ad acquistare i
> loro servizi
Anche io avevo pensato ad una cosa di questo genere, per questo ho fatto
tutti i tipi di prove con netcat su una macchina come server e sull'atra
come client, tra le prove che ho fatto:
server: macchina incriminata
client: in rete locale
server: macchina remota su internet con ip pubblico
client: macchina della lan
server: macchina remota su internet con ip pubblico
client: macchina incriminata
In tutti i casi i pacchetti udp con porta di destinazione 5060
scompaiono, ora faccio un po di prove con tcpdump (anzi, funziona x
udp?) e vedo se almeno ne esiste qualche traccia in kernel space.
Per cui mi sento di escludere l'ipotesi di blocco da parte del provider.
--
Fabio Napoleoni
f.nap...@email.it
****************************************************************
"Computer Science is no more about computers than astronomy is
about telescopes"
Edsger W. Dijkstra
****************************************************************
Fabio Napoleoni
> Quale processo/file di configurazione può essere la causa del problema? Che
> tipo di prove posso fare?
La cosa si fa sempre più misteriosa, ho fatto delle prove con tcpdump e i
pacchetti arrivano alla macchina in questione, solo che non arrivano a
livello applicazione, qualcuno sa spiegarmi questo mistero:
Output macchina client:
fabio@debian-etch:~$ netcat -uvv 192.168.1.100 5060
serveribm.satrico [192.168.1.100] 5060 (sip) open
prova prova prova
ciao ciao ciao
sent 33, rcvd 0
Output macchina incriminata:
serveribm:/home/fabio# netcat -luvvv -p 5060 &
[1] 17788
serveribm:/home/fabio# tcpdump -s 0 -nvv port 5060 and udp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535
bytes
15:36:21.099634 IP (tos 0x0, ttl 64, id 14035, offset 0, flags [DF], proto:
UDP (17), length: 46) 192.168.1.227.32874 > 192.168.1.100.5060: [udp sum ok]
SIP, length: 18
prova prova prova\012
0x0000: 7072 6f76 6120 7072 6f76 6120 7072 6f76
0x0010: 610a
15:36:23.327767 IP (tos 0x0, ttl 64, id 14036, offset 0, flags [DF], proto:
UDP (17), length: 43) 192.168.1.227.32874 > 192.168.1.100.5060: [udp sum ok]
SIP, length: 15
ciao ciao ciao\012
0x0000: 6369 616f 2063 6961 6f20 6369 616f 0a
2 packets captured
2 packets received by filter
0 packets dropped by kernel
serveribm:/home/fabio# killall netcat
sent 0, rcvd 0
[1]+ Exit 1 netcat -luvvv -p 5060
Antonino Di Bella
sudo netstat -lpn | grep 5060
Fabio Napoleoni
> prova a controllare che processo utilizza quella porta con:
> sudo netstat -lpn | grep 5060
Già fatto, nessun risultato né con netstat né con fuser.
Fabio Napoleoni
> On Wed, Jun 06, 2007 at 03:40:55PM +0200, Fabio Napoleoni wrote:
> > pacchetti arrivano alla macchina in questione, solo che non arrivano a
> > livello applicazione, qualcuno sa spiegarmi questo mistero:
> > [1] 17788
> > sent 0, rcvd 0
> > [1]+ Exit 1 netcat -luvvv -p 5060
>
> mandare quello che riceve a standard output ...
Fatto anche questo, in questo esempio era solo per comodità nello scrivere la
mail ma ho fatto tutti i tipi di prove con il server in foreground.
> Altra cosa, puoi verificare anche con iptables dicendo di loggare tutto
> il possibile (ogni combinazione tabella/catena) che coinvolge la porta
> udp incriminata (e magari eventuali icmp related)
Ehm, non conosco così bene iptables, diciamo che ne conosco l'uso base, hai
qualche dritta per farlo?
Fabio Napoleoni
> Alle 18:03, martedì 5 giugno 2007, Fabio Napoleoni ha scritto:
> > Quale processo/file di configurazione può essere la causa del problema?
> > Che tipo di prove posso fare?
>
> La cosa si fa sempre più misteriosa, ho fatto delle prove con tcpdump e i
> pacchetti arrivano alla macchina in questione, solo che non arrivano a
> livello applicazione, qualcuno sa spiegarmi questo mistero:
Una prova interessante è questa, se client e server (sempre con netcat) sono
entrambi sulla macchina incriminata (il cui ip è 192.168.1.100) ottengo
questo:
serveribm:/home/fabio# netcat -luvvv -p 5060 &
[1] 18271
serveribm:/home/fabio# netcat -uvvv 192.168.1.100 5060
serveribm.satrico [192.168.1.100] 5060 (sip) open
ciao prova
too many output retries : Operation not permitted
sent 0, rcvd 0
serveribm:/home/fabio#
Vi dice qualcosa, a me nulla in particolare, però mi sembra un errore un po
strano, ora googlo un po.
Per quanto riguarda invece iptables, non è lui la causa in quanto il
comportamento permane anche con tutte le policy impostate ad ACCEPT e tutte
le catene vuote ovvero con il firewall non configurato.
Fabio Napoleoni
> DA ROOT:
> iptables -L
> iptables -L -t nat
Si, zero assoluto. Nessuna regola impostata e tutte le policy ad ACCEPT
--
Fabio Napoleoni
f.nap...@email.it
****************************************************************
"Computer Science is no more about computers than astronomy is
about telescopes"
Edsger W. Dijkstra
****************************************************************
Gianluca
Hash: SHA1
Fabio Napoleoni ha scritto:
> Salve a tutti, ho un problema di networking con etch che non riesco a
> risolvere. Su una macchina che fa da firewall/gateway per la rete
> dell'ufficio i pacchetti udp sulla porta 5060 (telefonia voip) vengono
> misteriosamente bloccati. Sulla macchina in questione è presente shorewall ma
> la causa del blocco non è quella infatti anche disattivandolo completamente i
> pacchetti si perdono misteriosamente. Ho controllato anche i
> files /etc/hosts.allow ed hosts.deny e sono entrambi vuoti.
>
> Ho fatto vari tipi di prove e da vari host con netcat e l'unica coppia
> protocollo porta che non riesco a far funzionare e UDP/5060, con qualsiasi
> altra coppia protocollo porta le due istanze di netcat comunicano senza
> problemi.
>
> Quale processo/file di configurazione può essere la causa del problema? Che
> tipo di prove posso fare?
>
> Grazie per l'aiuto.
Se la situazione è questa:
[Asterisk]--(lan)--[Gateway]--(Internet)--[Provider]
Non riesci a registrati (sip show registry è vuoto), perché fai NAT e
così com'è iptables non memorizza le sessioni SIP e quindi non riesci
a ricevere chiamate.
Con etch, per ovviare al problema, devi caricare due moduli:
ip_conntrack_sip
ip_nat_sip
Fammi sapere se funziona,
Gianluca
- --
echo aculnaiG | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGaH1lK1z3HmyB2QIRAj6+AJ0XAP3hydrJfGrWBWmRvsmcT8a15ACfZMU0
h9+bFp8Mr9A95KMB4g1HL0o=
=fZvr
-----END PGP SIGNATURE-----
Fabio Napoleoni
> Fabio Napoleoni ha scritto:
>> Quale processo/file di configurazione può essere la causa del problema? Che
>
>> Grazie per l'aiuto.
>
>
> [Asterisk]--(lan)--[Gateway]--(Internet)--[Provider]
>
Si, la situazione è questa, il provider è un provider voip.
> Non riesci a registrati (sip show registry è vuoto), perché fai NAT e
> così com'è iptables non memorizza le sessioni SIP e quindi non riesci
> a ricevere chiamate.
> Con etch, per ovviare al problema, devi caricare due moduli:
>
> ip_conntrack_sip
> ip_nat_sip
Si, sono caricati, ma continua a non andare.
> Fammi sapere se funziona,
Alla fine ho trovato una soluzione accettabile, abbiamo fatto un reboot
della macchina e del modem adsl, dopo di chè ho flushato tutte le regole
di iptables, e lasciato solo quella che fa nat per le macchine interne.
Abbiamo inoltre disattivato temporaneamente asterisk e puntato i
telefoni (sia hardware che software) direttamente sul gateway sip del
provider, almeno in questo modo la telefonia sembra funzionare senza
particolari problemi.
Tanto per la cronaca il comportamento della porta 5060 non è cambiato
neanche di una virgola e continua a darmi tutti i problemi che ho
descritto in questi giorni, però evidentemente il problema della fonia
non è legato direttamente a questa cosa visto che ora i telefoni hanno
ripreso a funzionare.
Per il momento grazie a tutti, quando avrò un po di tempo proverò ad
indagare in maniera più approfondita sulla cosa.
--
Fabio Napoleoni
f.nap...@email.it
****************************************************************
"Computer Science is no more about computers than astronomy is
about telescopes"
Edsger W. Dijkstra
****************************************************************
Gianluca
Hash: SHA1
Fabio Napoleoni ha scritto:
Per caso il provider è EuteliaVoIP (ex Skypho)?
- --
echo aculnaiG | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGbHh4K1z3HmyB2QIRAorVAJ0aB/EUK1FCw9VkcI2Mxq7vdMte8QCfSdBT
RmZgITzExESdKRf22s5gOlk=
=CaqR
-----END PGP SIGNATURE-----
Fabio Napoleoni
> > Per il momento grazie a tutti, quando avrò un po di tempo proverò ad
> > indagare in maniera più approfondita sulla cosa.
>
> Per caso il provider è EuteliaVoIP (ex Skypho)?
No, è unidata.
Ciao.
Gianluca
Hash: SHA1
Fabio Napoleoni ha scritto:
> Alle 00:17, lunedì 11 giugno 2007, Gianluca ha scritto:
>>> Per il momento grazie a tutti, quando avrò un po di tempo proverò ad
>>> indagare in maniera più approfondita sulla cosa.
>> Per caso il provider è EuteliaVoIP (ex Skypho)?
>
> No, è unidata.
>
> Ciao.
Potresti farmi vedere la tua configurazione? Anche in privato se vuoi.
Gianluca
- --
echo aculnaiG | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
printf $i }'; echo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGbRxUK1z3HmyB2QIRAoyGAJ93+USlCjtjaYbWkWIvZOuxx9srnACfZMbI
TVyVezLYb9uTKXulErL6tAM=
=Eot6