VPN Verbindung klappt nur halb; Hirn verdreht

[Medium]

Zitat:

Zitat von ol1uw (Beitrag 1337103)

Hallo allerseits
Was sagt den ein

Code:

route print

wenn die VPN-Verbindung hergestellt ist?

Zitat:

================================================== =========================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c 29 31 8c 0e ...... Ethernetadapter der AMD-PCNET-Familie - Paketplaner-Miniport
0x20004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
================================================== =========================
================================================== =========================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.219 11
0.0.0.0 0.0.0.0 192.168.0.200 192.168.0.200 1
89.244.92.129 255.255.255.255 192.168.0.1 192.168.0.219 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.219 192.168.0.219 10
192.168.0.200 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.0.219 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.0.255 255.255.255.255 192.168.0.200 192.168.0.200 50
192.168.0.255 255.255.255.255 192.168.0.219 192.168.0.219 10
224.0.0.0 240.0.0.0 192.168.0.219 192.168.0.219 10
224.0.0.0 240.0.0.0 192.168.0.200 192.168.0.200 1
255.255.255.255 255.255.255.255 192.168.0.200 192.168.0.200 1
255.255.255.255 255.255.255.255 192.168.0.219 192.168.0.219 1
Standardgateway: 192.168.0.200
================================================== =========================
Ständige Routen:
Keine

(Edit: Komisch. Mit CODE-Tags wird die Tabelle nicht angezeigt. Dann eben als Quote.) (Edit2: Jetzt ist die Einrückung natürlich dahin. Grrr. Bitte diesen Beitrag zitieren um das vernünftig lesen zu können...)
(192.168.0.219 ist die lokale IP des Netzwerkadapters)
Leider sagt mir diese Tabelle überhaupt nichts.

Zitat:

Die Subnetmask ist aber sehr restriktiv, erlaubt sie doch nur einen Host.
Ich würde das und das Routing nochmals prüfen.

Die scheint so vom VPN-Server vorgegeben zu sein. Ich habe sie nirgends eingestellt, und wüsste auch nicht wirklich wo. Eingesehen habe ich sie mittels "ipconfig /all".

Danke dir schon mal!

[Medium]

Ich muss hier noch mal weiter machen. Das Ursprungsproblem ist nach wie vor, dass ich eine VPN Verbindung zwischen zwei Netzen im 192.168.0.x Kreis herstellen muss. Die Verbindung zum VPN Partner an und für sich ist hergestellt, die Gegenseite sieht mich auch in ihren Logs.

Jetzt haben wir bei manchen Kunden eine Fernwartungslösung der Firma MB Connect im Einsatz, und deren Client-Programm stellt letztlich auch nur eine VPN-Verbindung zu einem Endgerät her. Was dieser Client aber kann, ist das externe Netz auf ein anderes Subnetz quasi zu mappen. Heisst: Ein PC beim Kunden, der dort intern die IP 192.168.0.77 hat, ist bei verbundener Fernwartung von mir über die IP 192.168.10.77 erreichbar.
Sowas wäre DIE Lösung die ich bräuchte, aber in diesem Fall kann ich leider nicht die Software von MB einsetzen, sondern muss das irgendwie mit den Tools von Windows XP (leider geht nur XP, wegen anderer alter Software die zu dem Projekt gehört) allein erreichen. Wie macht man so was?

[Valle]

Sowas nennt man NAT und ist im Allgemeinen etwas, was man nicht möchte. Mit einem Linux Router wäre das über iptables relativ einfach umsetzbar.

[Medium]

Dazu muss das die Gegenstelle aber auch konfiguriert haben gelle? Ich vermute mal, dass das bei der Lösung von MB Connect deren Endgerät "out of the box" kann. Der Kunde hat leider niemanden vor Ort der solcher Dinge mächtig wäre, und ich selbst bin da leider auch nahe dem Ende meiner Kunst. Sieht so aus, als geht es einfach nicht. Keine Lösung dafür, bumms, aus. Selten sowas. Bleibt mir eigentlich nur, über mein Handy ins Internet zu gehen und damit ein klitze kleines LAN zu haben dessen IP Kreis ich sehr einfach verstellen kann. Und dann eben während dessen kein Zugriff auf unsere Server. Was ein Quark :?
Dass sowas nicht beim Herbeidenken von VPN mit bedacht wurde, und keine Standardlösung ins Protokoll eingebaut wurde, ist mir ein Rätsel.

[Valle]

Ach was, geht nicht, gibt's nicht. Wenn man denkt dass bei VPN etwas fehlt, dann hat es meistens einfach nur nicht richtig gemacht.

Ich muss zugeben dass ich dein Problem nicht ganz vollumfänglich verstanden habe. Ich versuche mal zusammenzufassen.

• Du hast zwei physisch getrennte Netzwerke
  • 192.168.20.0/24
  • 192.168.0.0/24
• Beide Netze sollen über ein VPN komplett verbunden werden
  • d.h. jeder kann jeden innerhalb beider Netze erreichen
• Beide Netze benutzen eine FritzBox als Router
• Und in beiden Netzen gibt es je einen Windows XP Rechner, der das VPN herstellen soll

Ist das soweit alles richtig?

Falls ja, dann sollte das nun wirklich kein unlösbares Problem sein. Die FritzBoxen haben eine eingebaute VPN Funktion, die sehr gut funktioniert und ohne großen Aufwand beliebig viele Netze miteinander verbindet. Die wichtigsten Voraussetzungen dafür sind, dass du zwei unterschiedliche Subnetze in beiden Standorten benutzt (tust du ja). Außerdem benötigst du öffentliche IPs an beiden Standorten. Kein Carrier-NAT! Aber da du das VPN ja bereits mit den XP Rechner herstellen konntest, wird das wohl auch der Fall sein.

Wenn zwei Rechner, die nicht Router im Netzwerk sind, das VPN herstellen sollen, dann hast du mehrere Probleme. Denn die anderen Rechner mit Netz wissen nicht, wohin sie das fremde Netz routen sollten. Man müsste dies als statische Route bei beiden FritzBoxen hinterlegen. Die FritzBox-Lösung wäre aber deutlich schöner, allein schon weil Windows XP bei sicherheitsrelevanten Diensten wie VPN absolut nichts verloren hat.

[Aviator]

Zitat:

Zitat von Valle (Beitrag 1347539)

Ist das soweit alles richtig?

Ich glaube nicht ganz. Und da liegt der Knackpunkt. Sein Netz liegt im Bereich 192.168.0.X und das Netz mit dem er sich verbinden will liegt ebenfalls im Bereich 192.168.0.X

Und jetzt ist die Frage, wie er diese beiden Netze als jeweils eigenständiges Netz behandeln kann. Korrekt @Medium?

Hierfür müsste es dann eine Zwischenschicht geben die z.B. Anfragen über ein weiteres Netz auf das richtige Netz umleitet. Bzw. das gibt es ja als VPN Netz. Nur will er denke ich die ganz normalen IP-Adressen des Gegenüber verwenden. Und da beißt sich die Katze in den Schwanz. Denn dann kommt er ja in seinem eigenen Netz raus.

[Medium]

Zitat:

Zitat von Valle (Beitrag 1347539)

Die wichtigsten Voraussetzungen dafür sind, dass du zwei unterschiedliche Subnetze in beiden Standorten benutzt [...]

Nur um Aviators korrekte Aussage nochmal zu bestätigen: Ich habe die selben Subnetze in beiden Netzwerken.
Das ist genau der Knackpunkt. Sind die unterschiedlich, gibt es keine Probleme. (Getestet mit Internet am Notebook via Handy als AP und anderem IP-Kreis.)

Der Kunde ist auch leider etwas größer (ein Museum), so dass dort auch nicht mal eben das Netzwerk umgestellt werden kann. (Zumal es "nur" um die gelegentliche Fernwartung einer einzigen kleinen Anlage dort geht.) Bei uns wären ebenfalls etliche PCs, SPSen, Telefone, Drucker und IP-Kameras sowie entsprechende Dienste und Programme anzupassen, womit uns solch eine Komplettumstellung vermutlich mindestens 1-2 Tage komplett lahm legen würde - eher mehr, wenn man die "Nachwehen" der ganzen vergessenen Ecken dazu rechnet. Steht auch für uns also eigentlich in keinem Verhältnis zueinander.
Ich weiß zudem nicht, über was für ein Gerät der Kunde im Internet ist. Und selbst wenn: Es gibt dort einen Werksstudenten der "schon mal was mit Computern gemacht hat" (bisschen mehr schon, aber so in etwa), der auch nicht mal eben beliebige Konfigurationen herbeizaubern kann. (Dass überhaupt ein VPN Zugang existiert ist vermutlich eher dem Komfort aktueller Hardware geschuldet als allem anderen.) Ergo: Ich müsste, wenn es denn ein komplikations-unwahrscheinlicher Weg wäre, dem Kunden alles mundgerecht vorkauen, oder dafür 2 Tage Dienstreise machen (~6h pro Strecke mit Auto). Problem ist dabei, dass ich selbst bei Netzwerktechnik recht schnell überfordert bin. (Hab das in der FH auch nur mit Hängen und Würgen überstanden. Bin eindeutig Entwickler, kein Netzwerkler :D)

Wie gesagt. Im Zweifel klemm ich für den Kunden (eigentlich auch nur ein Sub-Kunde) meine VM-USB Platte ans Notebook und opfere etwas Mobildatenkontingent. Schöner wäre anders, aber offenbar wenn überhaupt nur mit großem Aufwand und ohne Garantie.

[BenjaminH]

Es geht nur um die Fernwartung eines einzigen Systems?
Dann ist der einfachste Trick dort irgendwo einen SSH-Server(zum Beispiel auf dem Router) zum laufen zu bringen, sich mit dem Verbinden und alle nötigen Ports mittels Forwarding zu holen.
Einfachstes Beispiel, ein Webserver(192.168.0.17 Port 80) steht im Museum, ist aber nicht von außen erreichbar. Man braucht jetzt nur einen SSH-Server irgendwo in deren Netz, der auch von außen erreichbar ist(z.B. mit Port Forwarding im Router des Museums).
Jetzt will man auf den Webserver von außen zugreifen. Dann macht man folgendes:

Code:

ssh -L 8080:192.168.0.17:80 IP.Adresse.des.Museums

Nach dem Login kann man im eigenen Webbrowser unter der URL http://127.0.0.1:8080 auf den Webserver im Museum zugreifen.
Das funktioniert natürlich auch für mehrere Ports. Die Verbindung mit dem Fernwartungstool baut man dann zu 127.0.0.1(also quasi sich selbst) auf.

[Valle]

Ah, okay.

Wenn eine Änderung des Subnetzes keine Option ist, dann gibt es natürlich andere.

• Wie du selbst sagst, kann man NAT verwenden. Hier hat jemand das gleiche Problem und es wird beschrieben wie man es löst. Das ist aber nicht trivial und vermutlich nicht mit Windows XP lösbar. Es würde Zugriff auf den Museumsrouter und ziemlich sicher einen weiteren Rechner oder Router benötigen. Falls du wirklich nur eine IP fernwarten willst, rate ich davon ab.
  
• Wenn du nur eine IP fernwarten willst, warum dann überhaupt der ganze Aufwand? BenjaminH beschreibt eine Standardlösung die ich seit Jahren für verschiedene Unternehme und Vereine verwende. Ein Raspberry Pi und ein Portforwarding im Museumsrouter und der Fall wäre erledigt. Falls der fernzuwartende Rechner verschlüsselt und authentifiziert erreichbar ist, könnte man sich SSH sogar sparen und direkt die nötigen Ports freigeben. Aber Achtung: Sicherheitsrisiko wenn das nicht so ist!
  
• Falls du an der technisch korrekten, aber leider meist nicht umsetzbaren Lösung interessiert bist: Die Lösung heißt IPv6. Jedes Gerät bekommt eine globale, eindeutige IP-Adresse. Im Museumsrouter könnte die IP der zu steuernden Anlage freigeschaltet werden. Falls man Authentifizierung oder Verschlüsselung benötigt, kann man mit VPN zwei IPv6-Netze verbinden. Da alle Adressen weltweit eindeutig wären, könnte es nicht zu Konflikten wie in eurem Fall kommen.
  
• Edit: Ist TeamViewer eine Lösung? Einfacher als TeamViewer wird es nicht mehr.

[Medium]

Zitat:

Zitat von Valle (Beitrag 1347569)

Wie du selbst sagst, kann man NAT verwenden. [..] nicht trivial und vermutlich nicht mit Windows XP lösbar.

Das war auch der Eindruck den ich bei meinen Recherchen hatte. Deutlich oberhalb des Wissensstandes aller beteiligten, und irgendwie eine "zu große" Lösung.

Zitat:

Wenn du nur eine IP fernwarten willst, warum dann überhaupt der ganze Aufwand? BenjaminH beschreibt eine Standardlösung die ich seit Jahren für verschiedene Unternehme und Vereine verwende. Ein Raspberry Pi und ein Portforwarding im Museumsrouter und der Fall wäre erledigt. Falls der fernzuwartende Rechner verschlüsselt und authentifiziert erreichbar ist, könnte man sich SSH sogar sparen und direkt die nötigen Ports freigeben. Aber Achtung: Sicherheitsrisiko wenn das nicht so ist!

Problem. Der zu wartende PC ist nicht direkt von außen erreichbar, und ich brauche neben dem PC auch Zugriff auf eine SPS. Spätestens da wird's dann doof.

Zitat:

Falls du an der technisch korrekten, aber leider meist nicht umsetzbaren Lösung interessiert bist: Die Lösung heißt IPv6. Jedes Gerät bekommt eine globale, eindeutige IP-Adresse. Im Museumsrouter könnte die IP der zu steuernden Anlage freigeschaltet werden. Falls man Authentifizierung oder Verschlüsselung benötigt, kann man mit VPN zwei IPv6-Netze verbinden. Da alle Adressen weltweit eindeutig wären, könnte es nicht zu Konflikten wie in eurem Fall kommen.

Scheidet ebenfalls wegen der SPS aus, die kennt IPv6 nicht.

Zitat:

TeamViewer

Setzen wir praktisch überall sonst ein. Dort haben wir aber auch jeweils einen "Zugangs-PC", der die gesamte Entwicklungsumgebung insbesondere mit den Siemens-Tools fährt, so dass wir auf diese Weise sehr schmerzfrei beides warten können, SPSen und PCs. Da betreiben wir aber auch ganze Produktionsanlagen. In anderen Fällen kommt o.g. Lösung von MB Connect zum Einsatz. In dem jetzigen Fall haben wir leider beide Optionen nicht. Der Kunde stellt sich da auch etwas quer: Es gibt VPN, das muss reichen. (Nach dem Motto: Andere schaffen das ja auch.) Mehr Verbindungen will man wegen Sicherheitsbedenken nicht zulassen, schon gar nicht Dinge mit denen sich dort keiner auskennt :? (Dazu kommt, dass am einzig sinnvollen Installationsort dank viel Beton kein Mobilempfang herrscht, den wir dazu bräuchten. Antennen lassen sich auch nur begrenzt weit absetzen.)

Leider kann ich dem Kunden da nicht so auf die Füße treten wie ich das gerne würde, da wir in diesem (sehr seltenen) Fall als Sub agieren, und unser Auftragsgeber leider überhaupt keinen Informatik-Hintergrund hat. Und dann auch noch als Nachfolger für einen verstorbenen Freelancer, der das System in der Vergangenheit ja auch problemlos so erreichen konnte. Schwer zu vermitteln das ganze.

Als letzten Anker klemme ich meine VM mit den nötigen Tools bei mir zu Hause an den Rechner (dank VMware Player ja sehr schmerzfrei), gehe da vom Büro aus mit TeamViewer drauf, und mache über 5 Ecken dort die VPN Verbindung. Zu Hause kann ich immerhin sehr schnell ein anderes Subnetz einstellen, bei ner Hand voll Geräten. Sollte dank VDSL sogar recht komfortabel sein.