Asterisk antwortet von Port 1025

RcRaCk2k

Mitglied
Mitglied seit
4 Aug 2005
Beiträge
238
Punkte für Reaktionen
1
Punkte
16
Guten Tag liebe Community.

Ich glaub ich muss an meinem Asterisk irgendwas mieserables eingestellt haben!

Mein Client - welcher sich hinter einer Firewall befindet verbindet sich auf Port 5060 zu meinem Server.

Dieser jedoch antwortet auf Port 1025?!?
Natürlich kann das contrack_udp (NAT Table) diese Verbindung nichtmehr nachvollziehen und DROPT das ganze Paket.

Somit leitet die Firewall mein angefragtes Paket zwar an den Server weiter,
die Antwort wird jedoch abgewiesen!

Warum antwortet mein Asterisk auf Port 1025 und nicht auf 5060?

Wie kann ich das umstellen?

Grüße aus Freilassing.
Michael Rack

-------------------------------------------------
edit Rocky512
Werbung entfernt
 
Antwortet Asterisk VON oder AN Port 1025? Wenn Asterisk AN diesen Port antwortet, dann kann es sein, dass dein Client das so haben will. Ein 'sip debug' wäre dann hilfreich.

EDIT: Ich hab das Thema mal noch ins passende Forum verschoben.
 
Oh misst hab mich verschrieben.. Er antwortet von Port 1025

Anfrage sieht so aus:
CLIENT 10.0.0.133:5060 ---> FIREWALL 10.0.0.201 || S-NAT TO 81.223.189.xxx ---> SIP-Server 213.9.61.xxx:5060

Antwort sieht so aus:
SIP-Server 213.9.61.xxx:1025 ---> FIREWALL 81.223.189.xxx ---> (NAT-CONTRACK UDP) ... failed ---> TARGET: DROP

So sieht das SIP-Debug aus
Code:
|-> SENDING TO: 213.9.61.xxx:5060
----------------------------------------------------------------
REGISTER sip:nockstein.de SIP/2.0
To: Michael Rack<sip:[email protected]>
From: Michael Rack<sip:[email protected]>;tag=4d1c3e02
Via: SIP/2.0/UDP 81.223.189.xxx:5060;branch=z9hG4bK-d87543-856361805-1--d87543-;rport
Call-ID: cd6c6f150b735314
CSeq: 2 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 3600
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 3008q stamp 18440
Authorization: Digest username="21",realm="nockstein.de",nonce="3f2b6e26",uri="sip:nockstein.de",response="xxxxxxxxx",algorithm=MD5
Content-Length: 0


|<- RECEIVING FROM: 213.9.61.xxx:1025
---------------------------------------------------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 81.223.189.xxx:5060;branch=z9hG4bK-d87543-856361805-1--d87543-;received=81.223.189.xxx;rport=5063
From: Michael Rack<sip:[email protected]>;tag=4d1c3e02
To: Michael Rack<sip:[email protected]>
Call-ID: cd6c6f150b735314
CSeq: 2 REGISTER
User-Agent: VoIP Gateway nockstein.de runs on Asterisk-PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:[email protected]>
Content-Length: 0


|<- RECEIVING FROM: 213.9.61.xxx:1025
---------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 81.223.189.xxx:5063;branch=z9hG4bK-d87543-856361805-1--d87543-;received=81.223.189.xxx;rport=5063
From: Michael Rack<sip:[email protected]>;tag=4d1c3e02
To: Michael Rack<sip:[email protected]>;tag=as5caa6388
Call-ID: cd6c6f150b735314
CSeq: 2 REGISTER
User-Agent: VoIP Gateway nockstein.de runs on Asterisk-PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Expires: 3600
Contact: <sip:[email protected]:5060>;expires=3600
Date: Wed, 26 Apr 2006 10:34:18 GMT
Content-Length: 0
 
Wenn ich das richtig sehe, sind das die Debug-Ausgaben von deinem Client und da scheinen die Antworten vom Asterisk auch anzukommen. Es wäre interessanter, wenn man du uns sagen könntest, was auf der Asterisk-Seite passiert (am besten 'sip debug' und tcpdump).
 
Ähm ja das war vom Client - er erreicht deshalb die Daten, weil ich einen festen Destination-NAT auf port 5060 gemacht hab.. Also sprich UDP-DST-PORT 5060 -> 10.0.0.133

Hier mal ein SIP DEBUG
Code:
<-- SIP read from 81.223.189.xxx:5060:
REGISTER sip:nockstein.de SIP/2.0
To: Michael Rack<sip:[email protected]>
From: Michael Rack<sip:[email protected]>;tag=6f7fe340
Via: SIP/2.0/UDP 81.223.189.xxx:5060;branch=z9hG4bK-d87543-382539121-1--d87543-;rport
Call-ID: 217d0d20f5730f6e
CSeq: 1 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 3600
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 3008q stamp 18440
Content-Length: 0


--- (12 headers 0 lines)---
Using latest REGISTER request as basis request
Sending to 81.223.189.xxx : 5060 (NAT)
Transmitting (no NAT) to 81.223.189.xxx:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 81.223.189.xxx:5060;branch=z9hG4bK-d87543-382539121-1--d87543-;rport;received=81.223.189.xxx
From: Michael Rack<sip:[email protected]>;tag=6f7fe340
To: Michael Rack<sip:[email protected]>
Call-ID: 217d0d20f5730f6e
CSeq: 1 REGISTER
User-Agent: VoIP Gateway nockstein.de runs on Asterisk-PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:[email protected]>
Content-Length: 0


---
Transmitting (no NAT) to 81.223.189.xxx:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 81.223.189.xxx:5060;branch=z9hG4bK-d87543-382539121-1--d87543-;rport;received=81.223.189.xxx
From: Michael Rack<sip:[email protected]>;tag=6f7fe340
To: Michael Rack<sip:[email protected]>;tag=as78631d6f
Call-ID: 217d0d20f5730f6e
CSeq: 1 REGISTER
User-Agent: VoIP Gateway nockstein.de runs on Asterisk-PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:[email protected]>
WWW-Authenticate: Digest realm="nockstein.de", nonce="xxxx"
Content-Length: 0


---
Scheduling destruction of call '217d0d20f5730f6e' in 15000 ms
storage*CLI>
<-- SIP read from 81.223.189.xxx:5060:
REGISTER sip:nockstein.de SIP/2.0
To: Michael Rack<sip:[email protected]>
From: Michael Rack<sip:[email protected]>;tag=6f7fe340
Via: SIP/2.0/UDP 81.223.189.xxx:5060;branch=z9hG4bK-d87543-830890731-1--d87543-;rport
Call-ID: 217d0d20f5730f6e
CSeq: 2 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 3600
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 3008q stamp 18440
Authorization: Digest username="22",realm="nockstein.de",nonce="xxxx",uri="sip:nockstein.de",response="xxxx",algorithm=MD5
Content-Length: 0


--- (13 headers 0 lines)---
Using latest REGISTER request as basis request
Sending to 81.223.189.xxx : 5060 (NAT)
Transmitting (no NAT) to 81.223.189.xxx:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 81.223.189.xxx:5060;branch=z9hG4bK-d87543-830890731-1--d87543-;rport;received=81.223.189.xxx
From: Michael Rack<sip:[email protected]>;tag=6f7fe340
To: Michael Rack<sip:[email protected]>
Call-ID: 217d0d20f5730f6e
CSeq: 2 REGISTER
User-Agent: VoIP Gateway nockstein.de runs on Asterisk-PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:[email protected]>
Content-Length: 0


---
    -- Registered SIP '22' at 81.223.189.xxx port 5060 expires 3600
    -- Saved useragent "eyeBeam release 3008q stamp 18440" for peer 22
Transmitting (no NAT) to 81.223.189.xxx:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 81.223.189.xxx:5060;branch=z9hG4bK-d87543-830890731-1--d87543-;rport;received=81.223.189.xxx
From: Michael Rack<sip:[email protected]>;tag=6f7fe340
To: Michael Rack<sip:[email protected]>;tag=as78631d6f
Call-ID: 217d0d20f5730f6e
CSeq: 2 REGISTER
User-Agent: VoIP Gateway nockstein.de runs on Asterisk-PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Expires: 3600
Contact: <sip:[email protected]:5060>;expires=3600
Date: Wed, 26 Apr 2006 12:45:17 GMT
Content-Length: 0


---

Sieht ja eigentlich recht gut aus.... Man sieht dass es an die 5060 von 81.223.189.xxx gesendet wird. Der Source geht leider nicht hervor. Aber dafür gibts jetzt mal noch ein tcpdump....

Mein TCPDUMP
Und hier sieht man auch genau, dass Asterisk über Port 1025 raus sendet...

Code:
14:57:48.471342 IP mrack.gw2-sbg.xxxx.com.5060 > servers.gw1-frlg.nockstein.de.5060: SIP, length: 504
14:57:48.471573 IP servers.gw1-frlg.nockstein.de.1025 > mrack.gw2-sbg.xxxx.com.5060: SIP, length: 470
14:57:48.471610 IP servers.gw1-frlg.nockstein.de.1025 > mrack.gw2-sbg.xxxx.com.5060: SIP, length: 563
14:57:48.753912 IP mrack.gw2-sbg.xxxx.com.5060 > servers.gw1-frlg.nockstein.de.5060: SIP, length: 674
14:57:48.754213 IP servers.gw1-frlg.nockstein.de.1025 > mrack.gw2-sbg.xxxx.com.5060: SIP, length: 470
14:57:48.774594 IP servers.gw1-frlg.nockstein.de.1025 > mrack.gw2-sbg.xxxx.com.5060: SIP, length: 554

Grüße
Michael.
 
Sowas hab ich bisher noch nicht gesehen. Kann es sein, dass auf dem Rechner irgendwelche Firewall-Regeln gesetzt sind, die das Paket verändern?
 
Nö, nicht wirklich... Müsste ja im NAT-Postrouting sein...

Code:
Chain PREROUTING (policy ACCEPT 1376K packets, 121M bytes)
 pkts bytes target     prot opt in     out     source               destination
23556 2039K wireless   all  --  wlan   *       0.0.0.0/0            0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 408K packets, 33M bytes)
 pkts bytes target     prot opt in     out     source               destination
5652K  475M SNAT       all  --  *      dsl     192.168.0.2          0.0.0.0/0           to:213.9.61.xxx
   19  1338 SNAT       all  --  *      dsl     10.10.10.0/24        0.0.0.0/0           to:213.9.61.xxx
13438 1214K SNAT       all  --  *      dsl     10.10.200.0/24       0.0.0.0/0           to:213.9.61.xxx
  104  3904 SNAT       all  --  *      *       0.0.0.0/0            10.10.0.201         to:10.10.0.1

Chain OUTPUT (policy ACCEPT 5724K packets, 484M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain wireless (1 references)
 pkts bytes target     prot opt in     out     source               destination
  414 28139 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 to:145.253.2.11
 1368 65712 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 to:10.10.200.1

Wie gesagt - ich verstehs auch nicht .... Ist natürlich eine saudoofe Sache, weil kein einziger NAT-Router ohne fixxe Portweiterleitungen des packt..

Echt derbe Angelegenheit.
 
Hmm ich habe mir gerade meine offenen Ports angesehen:
Code:
udp        0      0 10.10.10.1:137          0.0.0.0:*                           7835/nmbd           off (0.00/0/0)
udp        0      0 10.10.200.1:137         0.0.0.0:*                           7835/nmbd           off (0.00/0/0)
udp        0      0 10.10.0.1:137           0.0.0.0:*                           7835/nmbd           off (0.00/0/0)
udp        0      0 0.0.0.0:137             0.0.0.0:*                           7835/nmbd           off (0.00/0/0)
udp        0      0 10.10.10.1:138          0.0.0.0:*                           7835/nmbd           off (0.00/0/0)
udp        0      0 10.10.200.1:138         0.0.0.0:*                           7835/nmbd           off (0.00/0/0)
udp        0      0 10.10.0.1:138           0.0.0.0:*                           7835/nmbd           off (0.00/0/0)
udp        0      0 0.0.0.0:138             0.0.0.0:*                           7835/nmbd           off (0.00/0/0)
udp        0      0 0.0.0.0:2727            0.0.0.0:*                           10189/asterisk      off (0.00/0/0)
udp        0      0 0.0.0.0:4520            0.0.0.0:*                           10189/asterisk      off (0.00/0/0)
udp        0      0 0.0.0.0:67              0.0.0.0:*                           14856/dhcpd         off (0.00/0/0)
udp        0      0 0.0.0.0:5060            0.0.0.0:*                           10189/asterisk      off (0.00/0/0)
udp        0      0 0.0.0.0:4569            0.0.0.0:*                           10189/asterisk      off (0.00/0/0)
raw        0      0 0.0.0.0:1               0.0.0.0:*               7           14856/dhcpd         off (0.00/0/0)
raw        0      0 0.0.0.0:1               0.0.0.0:*               7           6723/ping           off (0.00/0/0)

Es gibt keinen Service der auf Port UDP 1025 lauschen würde.

Ich denke, dass es sich um einen ip_contrack_sip handeln muss. Obwohl dieser WEDER im Kernel einkompiliert, NOCH als Module geladen wäre.

Irgendein NAT-Handler muss diese Verbindung verändern.

Grüße
Michael.
 
Wenn ich die manpage von iptables richtig deute, sind die SNAT-Regeln für das Mapping verantwortlich.

SNAT

This target is only valid in the nat table, in the POSTROUTING chain.
It specifies that the source address of the packet should be modified
(and all future packets in this connection will also be mangled), and
rules should cease being examined. It takes one type of option:

--to-source [noparse]ipaddr[-ipaddr][:port-port][/noparse]
which can specify a single new source IP address, an inclusive
range of IP addresses, and optionally, a port range (which is
only valid if the rule also specifies -p tcp or -p udp). If no
port range is specified, then source ports below 512 will be
mapped to other ports below 512: those between 512 and 1023
inclusive will be mapped to ports below 1024, and other ports
will be mapped to 1024 or above. Where possible, no port alter-
ation will occur.
 
Kostenlos!

Statistik des Forums

Themen
248,868
Beiträge
2,303,369
Mitglieder
378,528
Neuestes Mitglied
Fullyrealized