OpenVPN

OpenVPN (21 Beiträge, 708 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

IP von my-server-2
Beim Route Portweiterleitung eingerichtet zu 192.168.1.178

(sigkilled v1.10 (Tue Feb 4 14:41:01 2014): gesperrte externe URL gefunden)

04.02.2014, 14:45 Uhr - Editiert von Binchen, alte Version: hier

intern ja, extern nicht

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Kann der Client überhaupt die Server-IP im 10.8.2.X Bereich ansprechen? Kann er seine 10.8.2.X Adresse selbst anpingen, bzw. bekommt er überhaupt eine?

Zum Testen lass mal das weg:
push "route 192.168.1.0 255.255.255.0"

Das sagt ja aus, dass nur Anfragen für 192.168.1.X ans VPN geschickt werden.. Mit dem haben paar Probleme. Zum Testen also mal weg machen und gucken ob VPN funktioniert!

...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

Verbindung steht mittlerweile. Ich kann die Adressen 10.8.2.X Bereich pingen und auch die Serveradresse 192.168.1.178 kann ich pingen. Mehr jedoch nicht, außerdem ist das Internet am Client sofort Tot wenn ich die Verbindung aufbaue.

Die Verbindung steht, wenn du das push route weglässt oder allgemein steht die jetzt?
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

egal, Verbindung wird aufgebaut, jedoch geht dann das Internet nicht und ich finde nur den server

außerdem ist das Internet am Client sofort Tot wenn ich die Verbindung
aufbaue.

KLein Wunder!
Du redirectest ja das Gateway. Und am Server wird wohl kein NAT für das VPN Netz aktiv sein.
Lass diese Direktive weg, und das Problem ist behoben.

ok werde ich testen

Ich würde mal mit TCP anstelle UDP testen ...

Was sagt das log?
Kommt die Verbindung zu stande oder bekommst du ein Timeout?
Wie sieht die Firewall-Konfig von device tun am Server aus?

Ok, werde ich umstelle.
Ich habe am Server und auch am Client den Port 1194 ein- und ausgehend freigegeben.

Ich würde mal mit TCP anstelle UDP testen ...

Sehr schlechte Idee. Wieso für einen Tunnel TCP bemühen? Die Flow Control macht das je nach TTL extrem langsam.

Weil UDP in Zusammenhang mit nur über NAT erreichbar oft Probleme macht ...
Von der Perfomance her braucht es etwas mehr Leistung, aber alles in allen egal.

UDP wird üblicherweise aus Sicherheitstechnischen Gründen genommen ... habe zwar nie verstanden welches Problem TCP macht, aber angeblich werden Man in the Middle Angriffe durch TCP möglich ...

aber angeblich werden Man in the Middle Angriffe durch TCP möglich ...

Also das stelle ich mir bei UDP, welches keine direkte Verbindung OFFEN hält eigentlich leichter vor als mit TCP...
...

Apple Fans sind wie Zeugen Jehovas. Es ist sinnlos mit ihnen zu reden..

Why not ZOIDBERG? (V)_(°,,,°)_(V)
(-.(-.(-.(-.-).-).-).-)

UDP wird üblicherweise aus Sicherheitstechnischen Gründen genommen ... habe
zwar nie verstanden welches Problem TCP macht, aber angeblich werden Man in
the Middle Angriffe durch TCP möglich ...

Das ist aus der Luft gegriffen.
OpenVPN ist verschlüsselt. Daher sind Man in the Middle Attacken kein realistisches Szenario.
Und auch wenn dies nicht so wäre. Ein MitM Angriff verlangt, dass der Angreifer zugriff auf den Switch/Router hat. Wenn er da einfach einen Mirrorport einrichtet, dann ist es dem MitM völli9g egal, ob UDP oder TCP daherkommt. Alleine wenn er auf ARP-Spoofing oder MAC-Floodding angewiesen wäre, hätte TCP für den MitM Vorteile, weil er da sicher sein kann, alles mitzubekommen.

Der wesentliche Unterschied zwischen UDP und TCP ist, dass UDP die Datenwindows nach dem Fire&Forgett Prinzip liefert. D.h. es ist dem Sender völlig egal, ob die Daten beim Empfänger auch vollständig ankommen.

TCP hingegen wartet nach jedem gesendeten Window auf eine Bestätigung bevor das nächste Versendet wird. Und wenn es ein Problem gibt, wird die Windowsize verklei9nert und erneut gesendet.

D.h. es ist schon von daher viel langsamer, weil nach jedem Datenpackerl auf eine Bestätigung gewartet wird.

Dann kommt da noch ein zusätzliches Problem dazu. Innerhalb der OpenVPN Pakete sind ja in der Regel wieder TCP Pakete. D.h. wenn es jetzt ein Packerl verloren geht, fordert es OpenVPN nochmals an, der TCP Stream innerhalb der getunnelten Pakete tut das aber auch nochmal.

D.h. im Fehlerfall wird statt doppelt, gleich viermal gesendet. Und ebensooft mal auf Bestätigung gewartet. Entsprechend geht die Bandbreite in die Knie.

Wie schon geschrieben ... ich habe nie verstanden weshalb es anfälliger sein soll.
Hatte es einfach zur Kentniss genommen und ignoriert ...

Die 1% Ack. Daten verkraftet der Tunnel eher, als wie wenn die Nachricht nicht in der richtigen Reihnfolge ankommt ... und anstelle von 1 Paket gleich mehrere neu übertragen werden müssen.

Kentniss

Anders rum.....

Erstmal die Logs vom Serverstart posten und auch das vom Client wenn er sich verbinden will. Kommt die Verbindung überhaupt zustande (das steht im Log). Wenn das der Fall ist, dann kümmern wir uns ums Routing. Hierzu wäre es notwendig zu wissen, welche IP-Adressbereiche du in den beiden Netzwerken verwendest.

Wenn der Sturm losbricht,
verstummen die Einen vor Schrecken,
und die Anderen breiten, einem Adler gleich, die Flügel aus
und schwingen sich empor.

Herzlichen Dank an Raydoo für die Fotos

1.) bei deinem Router musst du eine statische Route für das 10.8er Netz setzen.
2.) Sehe ich in der config keine cipher Direktive, startet der Server überhaupt ohne ? (Logs)
3.) Verwendest du zufällig einen OpenWRT Router ?
4.) Hast du IP Forwarding aktiviert ? [1]
5.) Schalt ggf. mal deine Firewall ab bzw. erweitere den Scope auf das 10.8 Netz.

Default werden in Windows ICMP Pakete (ping) aus fremden IP Bereichen verworfen.

[1]: http://openvpn.net/index.php/open-source/faq/77-server/265-how-do-i-enable-ip-forwarding.html

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung