Bei mir kann man mit einem Packetdump feststellen, daß der voipd tatsächlich seine eigenen DNS-Abfragen macht und damit wohl nicht auf den Resolver-Cache des multid zurückgreifen wird. Diese DNS-Abfragen erfolgen auch an den DNS-Server, der vom Provider zugewiesen wurde (an meinem DSL-Anschluß), obwohl in der Box ein DNS-Server im LAN konfiguriert ist.
Das läßt mich
vermuten (nicht mit wissen verwechseln), daß der voipd diese DNS-Abfrage auf dem Interface absetzt, das er als zuständig für die Verbindung zum Registrar ansieht. In gewisser Weise würde das auch Sinn ergeben, denn es gibt bekanntermaßen FRITZ!Boxen, die mehrere logische Interfaces verwalten und da kann dann auch für solche Interfaces durchaus ein anderer DNS-Server zuständig sein. Es gibt ja einige Provider, die davon ausgiebig Gebrauch machen und die Namensauflösung für die SIP-Server ihrer Kunden nur in ihrem eigenen Netz richtig machen, bei externen Abfragen landet man dann in der Pampa.
Auch die Tatsache, daß AVM für solche DNS-Abfragen einen festen Port als Quelle verwendet (in der voip.cfg als "dnsport" konfiguriert) und daß es gesonderte QoS-Regeln genau für diesen Traffic (mit dem SIPDNS-Port als Absender) gibt, spricht für eine Sonderbehandlung, genauso wie die QoS-Chain, die sich hinter dieser Regel (aus der 7490) verbirgt:
Code:
root@FB7490:/var/media/ftp $ cat /proc/kdsld/nqos/lanset
lan:
0: ip.proto 17 ip.tos 0xfc / 0x60 udp.dport 123 => 7
0: ip.proto 6 ip.tos 0xfc / 0x60 tcp.dport 80 => 7
0: ip.proto 17 => 8
1: ip.tos 0xfc / 0x60 udp.dport 43962 => 8
1: ip.tos 0xfc / 0x60 udp.dport 47806 => 8
0: ip.proto 1 => 4
0: ip.proto 58 => 4
0: ip.proto 17 => 4
1: udp.dport 53 => 4
[COLOR="#FF0000"] 1: udp.dport 5060 packetmatch *sip:*@tel.t-online.de* (sip) => 9[/COLOR]
1: udp.dport 5060 (sip) => 10
0: => 12
Ich müßte das aber auch erst aufdröseln, welche Regeln jetzt genau für 9 als Ziel gelten:
Code:
root@FB7490:/var/media/ftp $ cat /proc/kdsld/nqos/results
results:
0: queue 5
1: queue 2 tos 184 vlan_prio 6
2: queue 2 tos 0
3: queue 2 tos 192
4: queue 1 tos 0
5: queue 0 tos 128 vlan_prio 4
6: queue 0 tos 0 vlan_prio 0
7: queue 1 tos 128
8: queue 1 tos 96
[COLOR="#FF0000"] 9: queue 2 tos 192 appl sip[/COLOR]
10: queue 2 tos 0 appl sip
11: queue 6 tos 0
12: queue 5 tos 0
Aber das könnte auch gut die Ursache sein, daß es irgendwie klemmt mit aktiviertem VPN, wobei das m.E. nur die zweite Wahl bei der möglichen Ursache wäre.
Ich würde in diesem Falle einfach darauf tippen, daß der voipd nach der Aktivierung des OpenVPN die falsche Bindung für das Interface wählt, das sollte man aber mit einem "showshringbuf sip" relativ leicht feststellen können:
Code:
root@FB7490:/var/media/ftp $ showshringbuf sip
2016-03-31 13:39:14.947 - IN: my=192.168.130.1%13:5060 peer=85.214.XXX.XXX port=5060 UDP, sipiface=none:
[...]
2016-03-31 13:39:14.952 - OUT: my=192.168.130.1%13:5060 peer=85.214.XXX.XXX port=5060 UDP, [COLOR="#FF0000"]sipiface=internet tcclass=sip_internet[/COLOR], netmark=0:
[...]
2016-03-31 13:41:14.993 - IN: my=192.168.130.1%13:5060 peer=85.214.XXX.XXX port=5060 UDP, sipiface=none:
[...]
2016-03-31 13:41:14.998 - OUT: my=192.168.130.1%13:5060 peer=85.214.XXX.XXX port=5060 UDP, [COLOR="#FF0000"]sipiface=voip tcclass=sip[/COLOR], netmark=0:
Sollte das am Ende das falsche Interface sein bzw. steht in der voip.cfg die Auswahl bei den SIP-Accounts auf "sipiface_automatic", würde ich es mal mit einer etwas gezielteren Festlegung probieren, z.B. "sipiface_internet". Mögliche Werte sind:
Code:
sipiface_automatic
sipiface_internet
sipiface_voip
sipiface_mta
sipiface_homenet
sipiface_vpn
sipiface_tunnel
, wobei der größte Teil davon eher an den DOCSIS-Anschlüssen der KNB von Interesse ist. Wenn dann die SIP-Accounts alle auf "sipiface_internet" stehen sollten und trotzdem nichts geht, wenn der OpenVPN-Tunnel aktiviert wurde, braucht es den Blick in einen Packetdump und in die Support-Daten (in erster Linie in die zum SIP, aber auch generell zur Interface-Konfiguration) und natürlich wirklich mal die OpenVPN-Konfiguration, weil da am Ende jede Kleinigkeit entscheidend sein kann.
Aber (s. die Spezialbehandlung für "tel.t-online.de" oben) es kann genauso gut sein, daß es ein generelles Problem ist, glaube ich aber eher nicht ... dafür gibt es zu viele Telekom-Kunden und zuviele Freetz-/OpenVPN-Benutzer, da muß es eine größere Schnittmenge geben und so viele Problembeschreibungen dazu haben wir nun auch wieder nicht in diesem Forum.
