[Frage] Routing über VPN Tunnel

[Tanisrooth]

Hallo zusammen.

Wahrscheinlich für viele kein Problem und womöglich wurde die Frage auch schon in irgendeinem Post beantwortet, allerdings weiß ich gerade nicht genau wonach ich suchen muss. Folgende Problemstellung:

IP Telefon an Standort B soll mit IP Telefonanlage Standort A verbunden werden.

Standort A ist über VPN Tunnel mit Standort B verbunden. Funktioniert einwandfrei.

Standort A:
Fritzbox 7390
Gateway: 192.168.2.1
TK Anlage: 192.168.2.201

Standort B
Fritzbox 7560
Gateway 192.168.3.1
IP Telefon 192.168.2.230

Was genau muss ich wie routen, damit das Telefon von der Anlage gefunden wird?

Danke schon mal für die Hilfe.

Gruß Tanis

 

[PeterPawn]

Was genau muss ich wie routen,

Gar nichts ... wie kommt man denn auf die Idee, einem IP-Telefon an Standort B eine IPv4-Adresse zu geben, die es in diesem Netz gar nicht gibt? Wie findet dieses Telefon dann eigentlich sein eigenes Gateway?

Es steht zwar nirgends, aber ich nehme einfach mal jeweils die "übliche" Maske mit 24 Bit an ...

 

[Tanisrooth]

Ja genau 24 Bit.

Ich kann dem Telefon auch jede andere IP Adresse geben. Mir wurde nur gesagt, das Telefon müsse im gleich IP Bereich wie die TK Anlage sein.

 

[PeterPawn]

Mir wurde nur gesagt, das Telefon müsse im gleich IP Bereich wie die TK Anlage sein.

Wer auch immer Dir das gesagt hat ... sofern er damit recht haben sollte (weil die Telefonanlage das nicht anders kann - das wäre die einzige logische Erklärung für eine solche Aussage in dieser Konstellation mit zwei Boxen), wird das mit den FRITZ!Boxen ohnehin nichts. Selbst eine dedizierte VPN-Verbindung (dabei wird ein einzelner Ethernet-Port der lokalen FRITZ!Box zum Peer getunnelt) hilft dann nichts, weil auch diese ein gesondertes IPv4-Netz verwenden würde.

Wenn es die Einschränkung der Telefonanlage auf "ausschließlich lokale IPv4-Adressen für Clients" gar nicht geben sollte, ist die Aussage vermutlich nur Unfug. Wenn das Telefon ganz normal eine IPv4-Adresse aus LAN B hat und der dort eingetragene Registrar die TK-Anlage in LAN A ist, dann übernimmt die VPN-Konfiguration den Transport von Paketen zwischen den beiden Standorten (und zwar mit ihren "Standardeinstellungen") - wenn die Telefonanlage keine "nicht-lokalen" Adressen mag, wird sie das ja wohl kundtun ... und außerdem ist es dann wohl auch besser, das "abstrakte Gebilde" mit der Bezeichnung "IP Telefonanlage" vielleicht doch etwas näher zu beschreiben? Wenigstens so etwas wie eine Modellnummer oder eine Angabe, was da für Software arbeitet, sollte ja eigentlich drin sein.

 

[Tanisrooth]

Hallo Peter,

vielen Dank erstmal. Ich hab mir schon sowas gedacht. Ist eine Alcatel Lucent Anlage. Die sollte das können. Ich vermute gerade, dass es dann evtl. an den Ports liegt, aber das müsste ich erst noch einmal testen. Ich werde mich dann noch einmal melden.

Gruß Tanis

 

[woprr]

Die sollte das können.

Hexen aber nicht. Das vpn setup muss schon stimmen, sonst findet das fon die anlage nie.

 

[dg2drf]

Das Telefon am Standort B muss auf jeden Fall eine IP aus dem Bereich 192.168.3.x haben.
Ein Problem könnte der Port 5060 sein, wenn beide FB als Sip-TK eingerichtet sind..
Ansonsten muss das Routing kontrolliert werden; Standort A muss wissen, das alle 192.168.3.x über den Gateway 192.168.3.1 erreichbar sind, Standort B muss wissen, das das Netz 192.168.2.x über Standort A 192.168.2.1 erreichbar ist.

 

[PeterPawn]

@dg2drf:
Das mag zwar als "abstrakte Fehlersuche" alles richtig sein ... hier geht es aber um zwei FRITZ!Boxen, an jedem Standort eine und da hat es nur sehr wenig mit "dem Routing" zu tun, welche Daten über den Tunnel zwischen den Standorten ausgetauscht werden - das wird (im Prinzip vermutlich sogar wie bei jedem modernen Linux, wo man diese Funktionen über "CONFIG_XTRM=y" einschließen kann) über Transformationen und die Auswahl von Datenpaketen für diese Verarbeitung geregelt - AVM hat hier im eigenen IP-Stack auf der WAN-Seite ggf. noch eine eigene Implementierung im Einsatz, das Prinzip sollte aber dasselbe sein, denn alles das, was durch eine "accesslist" für einen Tunnel ausgewählt wird, landet am Ende auch in diesem Tunnel.

Der "Ort" für das Selektieren dieser Pakete ist offenbar auch tatsächlich irgendwo im AVM-Stack "verborgen", denn beim FRITZ!OS muß jedes Paket, was für ein VPN-Ziel gedacht ist, zwingend über das Default-Interface (dev dsl) gehen. Damit sind irgendwelche Routing-Einstellungen im FRITZ!OS nicht notwendig (die kann man auf "normalem Weg" ohnehin nur für Routen vornehmen, die über das LAN-Interface (dev lan, ggf. ist das auch eine Bridge, in der die Ethernet-Interfaces und das WLAN zusammengeklöppelt sind) gehen) und würden sogar dazu führen, daß das AVM-VPN ein Paket gar nicht zu Gesicht bekommt, solange die zusätzliche Route nicht über "dev dsl" geht.

Unter anderem deshalb gibt es im FRITZ!OS für jede aktivierte Client-LAN-Verbindung im VPN auch einen Eintrag in der Routing-Tabelle, der alle Pakete für die IP-Adresse des Clients über "dev dsl" sendet ... die Pakete von anderen LAN-Geräten für diese Adresse fängt eine FRITZ!Box ein, indem sie sich per Proxy-ARP selbst für die entfernte IP-Adresse ausgibt. Das hat aber mit der LAN-LAN-Kopplung auch wieder nichts zu tun - es untermauert nur die Feststellung, daß jeder ausgehende VPN-Traffic über "dev dsl" gehen muß und stellt einen Zusammenhang zum Routing her, was aber nur bei einem ganz anderen Kontext (eben einer Client-LAN-Verbindung, wo der VPN-Client eine IP-Adresse aus dem lokalen Segment erhält) zum Einsatz kommt und mit einer LAN-LAN-Kopplung nichts zu tun hat.

Solange das Telefon am Standort B die FRITZ!Box am Standort B als Standard-Gateway verwendet, gehen alle Pakete, die nicht lokal "verwurstet" werden, automatisch an FRITZ!Box B und wenn das für Standort A und die dort befindliche Telefonanlage ebenfalls gilt (natürlich mit der FRITZ!Box A als Gateway), braucht da weder das Telefon noch die TK-Anlage irgendeine Information, wer da von wo nach wo routet ... das ist dann Sache des Routers (aka FRITZ!Box).

Apropos und sofern das Telefon mit der TK-Anlage kommunizieren will (was hier ja die Aufgabenstellung ist) ... wieso sollte es in diesem Zusammenhang irgendeine Rolle spielen, wenn die FRITZ!Box (egal an welchem Standort) den Port 5060 selbst verwendet? Der einzige Beitrag der FRITZ!Boxen auf beiden Seiten des VPN-Tunnels zur Verbindung zwischen der TK-Anlage und dem Telefon besteht im Transport der Daten zwischen den Standorten ... mit dem SIP-Protokoll kommt dabei keine der FRITZ!Boxen selbst in Kontakt.

 

[dg2drf]

@PeterPawn
vielen Dank für deine Ausführung, ich komme auch aus dem IT-Bereich.
Wenn man einen Anschluss in Auftrag gibt, bekommt man neben der Fritzbox einen Installationscode. Über diesen Installationscode wird die FB automatisch eingerichtet, inklusiv der Telefonie (in der heutigen Zeit SIP.....)
Schon kennen die FB das Sip-Protokoll. (Im übrigen kann die TK trotz Einrichtung der FB mit SIP mit dem Provider kommunizieren, kann ich dir Life bei mir zeigen)
Das die Protokolle über Dev DSL gehen müssen ist klar. Aber das heisst nicht, das default mäßig auch die Routing-Einträge korrekt da sind. Musste die schon öfters händisch entsprechend anpassen.
Du hast Recht, die TK und das Telefon müssen die Routen nicht kennen. Das man in dem Telefon natürlich den Registrar als IP und den Port (in diesem Fall die 192.168.2.201, und den Port 5060) eintragen muss , versteht sich von alleine. Im Gegensatz zu Dir bin ich der Meinung, das die in einem Router local genutzten Ports nicht weitergeleitet werden. Sprich wenn in der FB SIP aktiv ist, wird der Port 5060 nicht weitergeleitet.

 

[HabNeFritzbox]

Entweder an der TK Anlage die Firewall lockern, dass auch fremde Netze erlaubt sind bzw. das vom anderen Standort in Ausnahme kommt.

Sonst an FB B die Rufnummer registrieren, und dann am Telefon von Standard A, statt die TK Anlage die FB B als Anlage einrichten.

Oder sonst z.B. nen RasPi mit 2 LAN Ports, welcher mit VPN B verbindet und LAN 2 direkt ins VPN routet.

 

[PeterPawn]

Im Gegensatz zu Dir bin ich der Meinung, das die in einem Router local genutzten Ports nicht weitergeleitet werden. Sprich wenn in der FB SIP aktiv ist, wird der Port 5060 nicht weitergeleitet.

Mit dieser Ansicht befindest Du Dich überhaupt nicht in einem "Gegensatz" zu mir ... nur erklärt die lokale Verwendung des SIP-Ports an der FRITZ!Box ja immer noch nicht, warum das beim Zusammenspiel des Telefons mit der TK-Anlage eine Rolle spielen sollte.

Die eine Seite versendet Pakete mit der Empfängeradresse und dem gewünschten Port (ein IP-Endpoint besteht immer aus der Adresse und der Portnummer) und dieser Endpoint befindet sich eben gerade nicht auf/an/in der FRITZ!Box. Warum sollte sie hier also irgendetwas "weiterleiten"? Sie hat hier weder mit ihrer Firewall noch mit ihrer Übersetzung von IP-Adressen bzw. Portnummern etwas beizutragen ... sie ver- und entschlüsselt nur den Payload aus den IPSec-Paketen. Wenn sich hier zwei LAN-Clients (und sei es über ein VPN) miteinander "unterhalten", dann greift die FRITZ!Box da natürlich nicht ein ... egal, was in ihrer eigenen Firewall als "hole" von außen nach innen zugelassen sein mag und was nicht.

 

[dg2drf]

@peter-Pawn : Imho wiedersprichst du dich da im Moment selber. Durch die eigene Verwendung des Ports 5060 in der FB wird dieser nicht weitergeleitet. Dadurch kann sich das Telefon von Standort B nicht an der TK an Standort A anmelden (über den Port 5060).
Der VPN-Tunnel wird zwischen den beiden DSL-Ports aufgebaut (unter Umgehung der Firewall). Heisst natürlich, das auf der LAN Seite der FB der Port 5060 geöffnet ist, und somit nicht zum Routen zur verfügung steht. (Geroutet wird ja erst hinter der Firewall, wo der VPN Tunnel aufhört).
Da du mit mir übereinstimmst mit "....das die in einem Router local genutzten Ports nicht weitergeleitet werden." hast du an der Stelle deinen eigenen Widerspruch.

 

[PeterPawn]

@dg2drf:
Vielleicht erklärst Du mir ja einmal, wieso irgendein IP-Endpoint in der FRITZ!Box (daß ein IP-Endpoint immer aus einer Adresse und einer Portnummer besteht, hatte ich bereits geschrieben - mithin ist der Endpoint mit der IP-Adresse der FRITZ!Box und der Portnummer 5060 (egal, ob es TCP oder UDP wäre) ein anderer, als der an der TK-Anlage => er hat nämlich tatsächlich eine andere IP(v4)-Adresse) sich in die Kommunikation zwischen dem Telefon und der TK-Anlage "einmischen" sollte.

Beide Geräte senden jeweils Pakete mit der IP-Adresse des Empfängers (das Telefon an die TK-Anlage, diese wiederum an das Telefon) und die FRITZ!Box hat damit - im Rahmen des SIP-Protokolls - gar nichts zu tun.

Die einzige Aufgabe der FRITZ!Box(en) in diesem Szenario ist es, die Pakete von der einen Seite der VPN-Verbindung auf die andere zu befördern und das mach(t/en) sie unabhängig davon, welche IP-Adresse aus dem entfernten Segment da konkret im Paket steht oder an welchen Port dieses Paket geht ... ich unterstelle jetzt mal, daß da kein Traffic zusätzlich "gefiltert" wird über eine selbst erstellte "accesslist" für die VPN-Verbindung - das wäre aber für die Frage, ob der Port 5060 in der FRITZ!Box genutzt wird oder nicht, auch vollkommen irrelevant.

Alles das, was in irgendeiner der FRITZ!Boxen selbst an Diensten läuft und an irgendwelche internen oder externen Adressen gebunden ist (egal auf welchen Portnummern), interessiert hier gar nicht, solange davon nicht einer der Ports betroffen ist, die für das vom VPN verwendete IPSec-Protokoll eine Bedeutung haben (5060 hat keine, nur als "hint").

Wen juckt es denn (und bitte mit Begründung), daß/wenn der Port 5060 auf der FRITZ!Box selbst "geöffnet" ist bzw. da irgendein Dienst an diesen Port gebunden ist? KEINER (oder auch: nicht einer) der - an der Verbindung zwischen der TK-Anlage und dem Telefon - beteiligten Clients will mit der FRITZ!Box auf Port 5060 "reden" ... das heißt, keiner sendet Pakete mit irgendeiner IP-Adresse der FRITZ!Box und dem Port 5060 aus.

Ich habe ja kein Problem damit, das mit Dir auszudiskutieren ... aber vielleicht möchtest Du es ja auch einfach mal testen? Oder mir zumindest mal erklären, warum das (allen praktischen Erfahrungen zum Trotz) nicht funktionieren sollte - schon in der Theorie ist das für mich absolut nicht nachvollziehbar, was Du Dir vorstellst bzw. was Du tatsächlich meinst, woran das am Ende scheitern sollte. Irgendeine - wie auch immer geartete - Portweiterleitung findet hier ja gar nicht statt.

 

[andilao]

Mir sind schon TK-Anlagen/Geräte untergekommen, die tatsächlich alles außer Subnetz geblockt haben, natürlich einschließlich VPN. Das war dann nur eine Einstellungsfrage des darunterliegenden Asterisks oder z.B. beim N510 IP PRO per "Zugriff aus anderen Netzen zulassen" (was nichts mit der SIP-Registrierung des N510 zu tun hatte).

Falls "IP Telefonanlage Standort A" dahingehend keine Einstellmöglichkeiten hat, ist sie wohl eher ein Fehlkauf.