Hallo, kennt hier jemand eine Möglichkeit DPI zu umgehen? Mir ist schon klar was und wofür DPI genutzt wird aber es muss doch einen Weg geben dies zu umgehen. Ich habe das Problem das ich meinen VoIP Server mit allen Providern bis auf T-Mobile nutzen kann. Mir kam sodann die Idee das ganze einfach durch einen VPN zu leiten, klappt jedoch auch nicht. Ich kann meinen VoIP somit nur mit WLAN (also Internetanschluß), D2 und o2 verwenden. T-Mobile will nicht. Da ein jittern bei T-Mobile (mit und ohne VPN) auftritt gehe ich von einem DPI aus dem T-Mobile nutzt. Jemand Ideen wie ich VoIP trotzdem nutzen kann? Also über T-Mobile? Klar ich könnte nun auch T-Moble anrufen, VoIP extra buchen und bezahlen aber es geht ja nun nicht nur um VoIP. Wenn die schon VoIP Filtern (mit und ohne VPN) dann will ich nicht wissen was die noch so "prüfen".
Markus J. schrieb: > Ich habe das Problem das ich meinen VoIP Server mit allen > Providern bis auf T-Mobile nutzen kann. [...] > T-Mobile will nicht. Da ein jittern bei T-Mobile (mit und > ohne VPN) auftritt "will nicht" bedeutet, Du kannst Dich am SIP registrieren, einen Anruf aufbauen, nur die Sprache kommt dann unsauber durch? Oder was geht genau nicht? Nimm mal ein Softphone oder Asterisk mit sauberem Logging und schließe das z.B. per Tethering an Deine Mobilfunkverbindung an. Baue die Verbindung einmal mit T-Mobile auf und dann nochmal mit einem Mobilfunkprovider bei dem es geht. Wie unterscheiden sich die Logs? Was für einen VoIP-Server sprichst Du da an? Irgendeinen der größeren VoIP-Provider (wie Sipgate, Easybell,...) oder ist das wirklich Dein eigener Server? Es könnte nämlich sein daß die die Sperren einfach anhand der IPs machen. Wenn es Dein eigener Server ist, könntest Du noch auf beiden Seiten ein tcpdump/wireshark laufen lassen und die Paketdumps genau vergleichen. Da fallen dann alle Filtermaßnahmen klar auf.
Du fragst nach Mitteln - aber was ist der eigentliche Zweck? Geht es nur um Telefonie? Willst du nur den Inhalt verbergen, oder muss auch die Erfassung von Metadaten (wer mit wem) ausgeschlossen sein? Geschlossene Benutzergruppe, oder Standard? ...
:
Bearbeitet durch User
Gerd E. schrieb: > "will nicht" bedeutet, Du kannst Dich am SIP registrieren, einen Anruf > aufbauen, nur die Sprache kommt dann unsauber durch? Genau, ich kann mich anmelden, und auch wählen, dann ertönt jedoch kein Rufton o.ä. Beim angerufenen klingelt es allerdings, dieser kann das Gespräch auch abnehmen, hört aber nichts. Ich höre auch nichts. Werde ich angerufen ertönt der Rufton, bei mir klingelt es auch, aber ich höre dann nach dem abnehmen nichts. Leite ich das Gespräch dann an einen anderen Client (NICHT T-Mobile) um (auf der Asterisk Console) und nehme das Gespräch dann an kann ich telefonieren Gerd E. schrieb: > ........ > Mobilfunkprovider bei dem es geht. Wie unterscheiden sich die Logs? Das ist es ja eben, in den Logs taucht nichts auf. Also die Logs sagen "es geht" genau so wie bei anderen Clienten auch Gerd E. schrieb: > Was für einen VoIP-Server sprichst Du da an? Irgendeinen der größeren > VoIP-Provider (wie Sipgate, Easybell,...) oder ist das wirklich Dein > eigener Server? Ist mein eigener Asterisk Server. Der läuft auf einem kimsufi von OVH (KS-01) . Auf diesem läuft auch der OpenVPN im TAP Modus (streaming). Völlig ausreichend. Der Registrar ist PortUnity. Gerd E. schrieb: > Wenn es Dein eigener Server ist, könntest Du noch auf beiden Seiten ein > tcpdump/wireshark laufen lassen und die Paketdumps genau vergleichen. Da > fallen dann alle Filtermaßnahmen klar auf. Das werde ich mir mal ansehen. A. K. schrieb: > Du fragst nach Mitteln - aber was ist der eigentliche Zweck? Geht es nur > um Telefonie? Willst du nur den Inhalt verbergen, oder muss auch die > Erfassung von Metadaten (wer mit wem) ausgeschlossen sein? Geschlossene > Benutzergruppe, oder Standard? ... Ich sage es mal so "dreist" wie ich es auch meine. Ich sehe nicht ein eine "extra" Option bei T-Mobile zu buchen und dafür extra zu zahlen. Ich habe ein gewissen Datenvolumen und dies möchte ich UNEINGESCHRÄNKT nutzen können. Da T-Mobile hier aber aktiv das VoIP unterbindet um so "extra" Geld zu kassieren suche ich eben eine möglichkeit dies zu umgehen. Das ganze tritt eben nur bei T-Mobile auf. Bei einem anderen Anbieter. Ich habe mich durch den ganzen Bekannten/Verwandten Kreis durchgefragt und ich denke so ziemlich alle ISP durch. Lediglich über das T-Mobile Netz funktioniert es eben nicht. Auch ein tcp_low_latency = 1 brachte keinerlei Erfolg. Da der OpenVPN mit 2048 Bit läuft müsste meines Wissens nach jedoch die Telekom/T-Mobile wie auch immer, die Crypto geknackt haben sonst würde auch ein DPI nichts bringen. Somit bin ich echt Ratlos was die da "machen".
:
Bearbeitet durch User
Markus J. schrieb: > Da der OpenVPN mit 2048 Bit läuft müsste meines Wissens nach jedoch die > Telekom/T-Mobile wie auch immer, die Crypto geknackt haben sonst würde > auch ein DPI nichts bringen. Somit bin ich echt Ratlos was die da > "machen". Protokolle sind nicht selten an einer Startsignatur erkennbar. Oder es wird schlicht der Standardport von OpenVPN blockiert. Bessere Firewalls machen eine Wissenschaft draus, Anwendungen ohne Decryption zu erraten.
Würde der OpenVPN Port blockiert so würde VPN ja garnicht erst funktionieren. Ich kann jedoch alles über den VPN machen. Nur eben kein VoIP und das auch nur eben bei T-Mobile.
Meiner Meinung nach bist du schon einen Schritt zu weit. Ich glaube nämlich nicht, dass T-mobile dir deinen VPN-Tunnel aufbricht, damit du ja kein VoIP nutzt. Beispielsweise sind CGNAT und IPv6 gerade mobil sehr verbreitet, und können ganz interessante Effekte erzeugen.
Mach mal den tcpdump. Und noch einen mit Deinem OpenVPN. Dann schau Dir die Pakete genau an. Vielleicht schauen die sich ja z.B die DSCP-Flags der Pakete an. Oder die Paketgrößen. Oder etwas ähnliches. Was ist mit einem Ping den Du gleichzeitig zur Sprache durchs OpenVPN schickst?
:
Bearbeitet durch User
Hört sich für mich auch eher wie ein typisches NAT Problem bei VoIP an. Die Streams für Audio können ja offenbar nicht richtig geöffnet werden. Ich glaube auch NICHT das die Telekom da in irgendwelche Tunnel reinschaut - das würde viel zu viel (teure) Firewallkapazität kosten. Wir sind ja noch nicht in China hier :-) Zumal es garnicht so einfach möglich ist (Du hast ja bei Deinem OpenVPN sicher auf beiden Seiten einen Pre-shared-key oder ein Zertifikat um es zu sichern?). Geht der Tunnel direkt bis zum Endgerät? Ist sichergestellt das auch die Steams für das Audio durch den Tunnel gehen?
Gerd E. schrieb: > Mach mal den tcpdump. Und noch einen mit Deinem OpenVPN. Werde ich mir nachher mal genauer ansehen und berichten / posten eventuell übersehe ich ja was Gerd E. schrieb: > Was ist mit einem Ping den Du gleichzeitig zur Sprache durchs OpenVPN > schickst? Das ist kein Problem. Kein packet lost o.ä. Markus M. schrieb: > Hört sich für mich auch eher wie ein typisches NAT Problem bei VoIP an. > Die Streams für Audio können ja offenbar nicht richtig geöffnet werden. Kann ich mir kaum vorstellen. Der OpenVPN läuft im TAP Modus wegen streaming etc durchs VPN. Also da läuft nen DLNA und weiteres und das funktioniert ohne Probleme. Auch geht es ja mit allen anderen, dann müsste das Problem ja generell auftauchen, tuts aber nicht sondern nur mit T-Mobile. Ich habe auch schon mal das subnet geändert, ohne Erfolg. Markus M. schrieb: > Ich glaube auch NICHT das die Telekom da in irgendwelche Tunnel > reinschaut - das würde viel zu viel (teure) Firewallkapazität kosten. > Wir sind ja noch nicht in China hier :-) Zumal es garnicht so einfach > möglich ist (Du hast ja bei Deinem OpenVPN sicher auf beiden Seiten > einen Pre-shared-key oder ein Zertifikat um es zu sichern?). Wie gesagt, mit 2048Bit verschlüsselt, das ganze per SCP runter-/hochgeladen. SSH ist auch nur mittels Key erreichbar, normaler login ist nicht möglich. Weiterhin ist das gesamte System vollverschlüsselt mittels dmcrpyt und muss über ssh und passwort Eingabe gebootet werden. Nun ja, du redest von Firewallkapazität nutzen. Bisher ist mir nicht bekannt das jemand eine 2048Bit Verschlüsselung geknackt hat. Ich denke selbst T-Mobile ist dazu nicht in der Lage. Ich lasse mich aber gerne des besseren belehren. Markus M. schrieb: > Geht der Tunnel direkt bis zum Endgerät? Ist sichergestellt das auch die > Steams für das Audio durch den Tunnel gehen? Der Tunnel geht direkt vom Endgerät (Smartphone) zum Server. Der Asterisk ist nur "local" auf dem Server erreichbar. Es muss also alles vom internen Netz kommen. Somit muss der stream durch den Tunnel.
Markus J. schrieb: > Bisher ist mir nicht > bekannt das jemand eine 2048Bit Verschlüsselung geknackt hat. Ich denke > selbst T-Mobile ist dazu nicht in der Lage. Das hätte was. 2048-er Verschlüsselung knacken um pro Kunde ein paar Euro für VoIP/VPN-Freigabe kassieren zu können. Netzneutralität vom Feinsten.
Ja das ist es ja eben. Das kann ich mir beim besten Willen einfach nicht vorstellen. Es muss doch irgendwie rauszubekommen sein was/wie T-Mobile das/was macht. Irgendeine Filtertechnik müssen die ja verwenden.
Bei SIP ist es doch üblicherweise so, daß nach dem vom SIP-Server verwalteten Verbindungsaufbau die Audiodaten direkt von Endgerät zu Endgerät versendet werden, d.h. nicht durch den SIP-Server laufen. Und damit könnte es im geschilderten Szenario sein, daß die SIP-Audiodaten gar nicht erst durch den VPN-Tunnel gehen. Oder ist der VPN-Client so konfiguriert, daß er jeden Traffic durch den VPN-Tunnel leitet?
VoIP Provider - > IAX - > Asterisk - > VPN - > SIP-Client. Asterisk ist so geconft das er bis auf den VoIP Provider alles durch den Tunnel leiten muss oder eben die Verbindung ablehnt. Ebenfalls nimmt Asterisk das Gespräch an und baut dann ein neues Gespräch zum Client auf.
:
Bearbeitet durch User
Jupp, da gebe ich Rufus recht. Bin kein SIP Spezialist, aber ich erinnere mich, dass es relativ trickreich ist das hinter einem NAT-Router vernünftig zum Laufen zu bekommen, eben weil die Endgeräte in der Kontrollverbindung ihre IP-Adressen austauschen und dann zwischen diesen den Audiostream per UDP eröffnen. Ohne einen entsprechenden "Protokoll-Helper" auf dem NAT bzw. Firewall Router der die SIP Kontrollpakete entsprechend "anpasst" funktioniert das idR nicht richtig. Es wäre wirklich interessant, ob die Audiodaten wirklich durch den Tunnel gehen...
Es gibt einige Gründe dafür, wieso es dabei Probleme geben kann oder vielleicht sogar muss. Nur müssen sich diese Probleme stets am Umstand messen, dass es bei Vodafone und O2 funktioniert.
Markus J. schrieb: > Ich kann jedoch alles über den VPN machen. Nur eben kein > VoIP und das auch nur eben bei T-Mobile. Handelt es sich immer um das gleiche Mobilgerät mit verschiedenen SIM-Karten, oder sind das verschiedene Geräte? Nicht dass du an der falschen Stelle suchst und es tatsächlich das vielleicht sogar gebrandete Mobilgerät ist, das sich schlichtweg weigert.
Um Probleme mit NAT bei VOIP zu umgehen, wurde STUN erfunden. Schon probiert? https://www.3cx.de/voip-sip/stun-server/
A. K. schrieb: > Handelt es sich immer um das gleiche Mobilgerät mit verschiedenen > SIM-Karten, oder sind das verschiedene Geräte? Nicht dass du an der > falschen Stelle suchst und es tatsächlich das vielleicht sogar > gebrandete Mobilgerät ist, das sich schlichtweg weigert. Also ich habe es mit verschiedenen SIM Karten im gleichen Gerät und auch in anderen Geräten die T-Mobile SIM Karten getestet. Es geht mit T-Mobile einfach nicht. Also das können wir schonmal ausschließen, wie es mit Windows ist kA da auf den Firmen Notebooks überall Debian mit Linphone ohne Probleme läuft. Smartphones sind alles Sony oder Samsung (13 Stück). Frank E. schrieb: > Um Probleme mit NAT bei VOIP zu umgehen, wurde STUN erfunden. Schon > probiert? Ich kann es ja mal probieren nur wären NAT Probleme vorhanden würden die anderen ISP auch nicht funktionieren.
Markus J. schrieb: > Asterisk ist so geconft das er bis auf den VoIP Provider alles durch den > Tunnel leiten muss Und der Sip-Client?
Schreib doch mal T-Mobile an beachreibe dein Problem musst ja nicht gleich VoIP nennen und verweise mal auf https://de.m.wikipedia.org/wiki/Fernmeldegeheimnis erwähne auch mal die Bundesnetzagentur. Es gibt auch einige Patente ala Lesequelle bezüglich von VoIP Verhinderung/Störung Wäre vielleicht DualSIM eine Lösung?
Markus J. schrieb: > Ich kann es ja mal probieren nur wären NAT Probleme vorhanden würden die > anderen ISP auch nicht funktionieren. Dann weißt du nicht, wie viele Arten und Implementierungen von NAT es gibt. Thomas O. schrieb: > und verweise mal auf https://de.m.wikipedia.org/wiki/Fernmeldegeheimnis > erwähne auch mal die Bundesnetzagentur. Es wird sowohl T-Mobile als auch die BNA genau Null kratzen, wenn jemand seine Software nicht konfigurieren kann.
Rufus Τ. F. schrieb: > Und der Sip-Client? Nunja, der muss ja richtig geconft sein sonst könnte er sich ja nicht anmelden. Wie gesagt, der Asterisk ist nur über VPN erreichbar und mit ner anderen SMI Karte ohne Änderungen am Client klappt es ja. Jan H. schrieb: > Dann weißt du nicht, wie viele Arten und Implementierungen von NAT es > gibt. Ähm nö. Weiss ich nicht. Ich weiss ja auch nicht was ich mache. Ich habe etliche Server, arbeite selbst im Server Support seit 17 Jahren, aber hab keinen Plan von nichts ;) Einfach mal was rein werfen, hauptsache ich habe was geschrieben. Das sind mir die liebsten. Genau solche Leute sind meine/unsere liebsten Kunden, an denen verdienen wir am meisten. Jan H. schrieb: > Thomas O. schrieb: >> und verweise mal auf https://de.m.wikipedia.org/wiki/Fernmeldegeheimnis >> erwähne auch mal die Bundesnetzagentur. > > Es wird sowohl T-Mobile als auch die BNA genau Null kratzen, wenn jemand > seine Software nicht konfigurieren kann. Wenn es wirklich so ist das die das eventuell, durch was auch immer, doch sehen, dann wird das die BNA sehr wohl interessieren. Allerdings sehe ich hier auch das Problem der Vertragsfreiheit. Selbst wenn man dann rechtlich dagegen vorgehen würde müsste ich ja sagen was genau nicht geht und spätestens dann habe ich die A Karte gezogen denn dann kommt das "klein gedruckte". Zum konfigurieren, s.o. Thomas O. schrieb: > Wäre vielleicht DualSIM eine Lösung? Nunja, dann könnte man die T-Mobile Verträge auch auslaufen lassen und zu einem anderen Provider wechseln. DualSIM würde nur mehrkosten für den Kunden bedeuten.
:
Bearbeitet durch User
Markus J. schrieb: > Nunja, der muss ja richtig geconft sein sonst könnte er sich ja nicht > anmelden. Wie gesagt, der Asterisk ist nur über VPN erreichbar und mit > ner anderen SMI Karte ohne Änderungen am Client klappt es ja. Eben. Genau das passt ja zu meiner Vermutung, daß der Client nach Verbindungsaufbau die SIP-Sprachdaten eben nicht an Deinen SIP-Server, sondern an den korrespondierenden SIP-Client am anderen Ende der Verbindung sendet. Das soll ja auch so sein, so ist SIP designt. Du müsstest also mal die Clientseite genauer untersuchen.
Ja das trifft ja soweit zu nicht aber nach der Asterisk config (Kundenconfig). Der config, zumindest bei EINGEHENDEN Verbindung, sieht so aus, daß Asterisk das Gespräch annimmt, und eine neue Verbindung zum SIP Client herstellt. Nichtmals eine Echo Verbindung kommt mit T-Mobile zustande. Und dann wird NUR mit dem Asterisk durch den Tunnel gesprochen.
Nun, dann aber geschehen Dinge, die nicht geschehen können. Es ist ausgeschlossen, daß T-Mobile Dein VPN auf Inhalte filtert, denn das würde bedeuten, daß die Dein 2048-Bit-VPN entschlüsseln könnten. Wenn aber alle Daten durch das VPN gesendet werden, und selektiv Daten nicht durch das VPN hindurchkommen, müsste also doch eine Filterung auf Inhalte erfolgen. Was aber nicht sein kann. Du siehst das Problem? Also ist mit ziemlicher Sicherheit davon auszugehen, daß bei Deinem Setup eben doch nicht alle Daten durch das VPN transportiert werden. Und da musst Du Dir jetzt nicht die Konfiguration Deines Asterisk-Servers ansehen, sondern das, was der SIP-Client hinter Deinem VPN anstellt. Was ist das für eine Hardware?
Rufus Τ. F. schrieb: > Wenn aber alle Daten durch das VPN gesendet werden, und selektiv Daten > nicht durch das VPN hindurchkommen, müsste also doch eine Filterung > auf Inhalte erfolgen. Was aber nicht sein kann. Doch, das kann schon sein. Denn trotz Verschlüsselung kann man den Paketen von außen noch so einiges ansehen, anhand dem man eine Filterung machen könnte. Wie ich oben schon geschrieben habe, wären DSCP-Flags oder die Kombination von Paketgröße und Häufigkeit 2 Möglichkeiten die ich mir vorstellen könnte. Daher sollte Markus einfach mal gleichzeitig tcpdumps von Client und Server machen. Dann sieht man was passiert und muss nicht raten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.