Bitte um VPN Übersicht

[MaxMuster]

Ja, das wäre genau der Unterschied und ist für "getrennte Netze" eigentlich sinvoller, weil dann ur das "über den Draht" geht, was auch wirklich für die andere Seite bestimmt ist (während "Bridging" einfach stumpf alles, jedes Paket im LAN, von A nach B kopiert, egal ob es da benötigt wird oder nicht)

Jörg

 

[pollonhokairos]

Nun gut. Hab jetzt die Verbindung per TCP von Box zu Box.
Langsam versteh ich sogar die meisten Sachen.
Doch bleibt ja bei der TCP Lösung meine Kasse aussen vor.
Die scheint also nur im Bridging zu funktionieren.
Sehr schade eigentlich, weil das ja der Hauptgrund meiner VPN Verbindung ist.
Oder kann ich da noch etwas probieren?

Wie wirds denn beim Drucken über VPN ausschauen.
Funktioniert dessen Protokoll auch nicht, wenn er am USB Port meines alten T-Sinus 154comfort hängt?

Anton

 

[MaxMuster]

Doch bleibt ja bei der TCP Lösung meine Kasse aussen vor.

Das liegt aber nicht am TCP sondern an der Frage, ob dieses Kassenprogramm Routingfähig ist oder nicht, da du ja nun eine "Tunnel-Lösung" realisiert hast.

Die scheint also nur im Bridging zu funktionieren.
Sehr schade eigentlich, weil das ja der Hauptgrund meiner VPN Verbindung ist.

Oder kann ich da noch etwas probieren?

Klar, das geht immer ;-)
Du könntest, wenn das das einzige Problem ist, speziell für die Kassenverbindung eine seperate Verbindung des Notebooks auf den VPN-Server aufbauen, der dann per Bridging im LAN ist. Ist halt alles eine Frage des Aufwands...

Wie wirds denn beim Drucken über VPN ausschauen.

Testen! Eigentlich solten diese Dinger rein per IP funktionieren

Jörg

 

[pollonhokairos]

eine seperate Verbindung des Notebooks auf den VPN-Server aufbauen, der dann per Bridging im LAN ist
Jörg

In diese Richtung habe ich auch gedacht.
Würde das wohl so ablaufen:

- Auf der Box läuft bereits der OpenVPN-Server im Routing-Modus, der beide Boxen verbindet.

- Ich logge mich per SSH auf der Box ein.

- Ich starte per Skript oder sonstwie eine zweite OpenVPN Instanz im Bridging-Modus.

- Diese zweite Instanz braucht nur eine dementsprechende Konfigurationsdatei - OpenVPN muss nicht nochmal geladen werden.

- Nach dem Arbeiten auf der Kasse beende ich wieder diese zweite Instanz per SSH.

Soweit die Theorie.
Kriege ich bei zwei gleichzeitigen Verbindungen Probleme?
Mein Notebook ist ja dann einmal über die Box2Box und einmal über eine eigene VPN mit der entfernten Box verbunden.
Müsste also dann die erste Instanz zuerst bendet werden?

Gruß Anton

 

[MaxMuster]

Genau so sollte das gehen. Wenn der Brücken-VPN-Server dem NB eine "TAP-IP" aus dem LAN bei der Kasse vergibt, ist da auch keine Notwendigkeit, irgendwas anderes zu beenden, denn dein NB hat dann halt zwei Netzwerkkarten, und die eine (virtuelle) ist die, die direkt mit der Kasse verbunden ist...

Jörg

 

[pollonhokairos]

Bin wieder einen Schritt weiter.
Hab das erste Script meines Lebens geschrieben.
Dieses startet eine zweite Instanz von Open-VPN mit einem anderen Interface. Getestet hab ich erst mal nur mit dem Open-VPN Client auf meinem Notebook.
Gewechselt zwischen TAP und TUN - funktioniert.

Die in der Fitzbox(Server) hinterlegte route für mein lokales LAN hat dann aber doch Probleme gemacht. Mit dem doppelten Routing auf mein Lan hinter der Fitzbox(Client) konnte ich die Server-Fritzbox nicht erreichen. Komischerweise die Kasse in dessen Lan schon.
Gibts da eine Erklärung?

Edit:
Hab nochmal rumprobiert.
Wenn ich den Open-VPN Modus jeweils explizit neu starte, also z.B meinen TAP-Modus mit:

/var/tmp/openvpn --config /var/tmp/server.ovpn

dann funktionierts.
Wenn ich nur auf meinem Client den Modus ändere, gehts nicht.

Kann es sein, daß dabei das Routing nicht "neu geschrieben" wird und das die Fehlerquelle ist?

Edit Ende


Hab dann per ssh eine der beiden Routen gelöscht und dann gings.

Auf jedenfall machts immer mehr Spaß - auch wenn ich viele Sachen zwar immer noch nicht durchschaue und noch viel googeln muß.
Angefangen hatte ich mit einem Fehler der Groß/Kleinschreibung und lange lange gebraucht, bis ich erfuhr, daß Unix da sehr wählerisch ist. Aber das ist lange lange her - mindestens drei Wochen.

Welches Linux/Unix läuft denn überhaupt auf der Box?
Würde mir vielleicht meine zukünftige Suche erleichtern.

Gruß Anton

 

[pollonhokairos]

Genau so sollte das gehen. Wenn der Brücken-VPN-Server dem NB eine "TAP-IP" aus dem LAN bei der Kasse vergibt, ist da auch keine Notwendigkeit, irgendwas anderes zu beenden, denn dein NB hat dann halt zwei Netzwerkkarten, und die eine (virtuelle) ist die, die direkt mit der Kasse verbunden ist...

Jörg

Funktioniert leider noch nicht ganz.

Ich hab jetzt meine beiden Boxen per "tun" verbunden - geht.

Dann starte ich auf der Server-Box zusätzlich den "tap-Server" und kann mich über den Open-VPN Client auf meinem NB mit dem "tap-Sever" verbinden.
Wenn ich dann auf dem NB den Open-VPN Client beende, funktioniert die "tun-Verbindung" nicht mehr.
Ich muss dann per SSH den "tap-Server" per "kill" beenden und den "tun-Server" wieder starten - dann läufts wieder.

Was mach ich denn da noch falsch?

 

[MaxMuster]

Funktionieren die denn beide Verbindungen, während die TAP-Verbindung läuft? Oder bricht die TUN-Verbindug sofort weg, wenn die andere aufgebaut wird?

Vielleicht kannst du mal die beiden Server-Configs und die entsprechenden Client-Configs posten? Wichtig ist z.B., dass die auf verschiedenen Ports lauschen (oder beim gleichen Port einer TCP einer UDP macht). Ansonsten wäre ein Log nicht schlecht, speziell vom Zeitpunkt Auf- und Abbau der zweiten Verbindung.

Jörg

 

[pollonhokairos]

Hallo Jörg,

die Änderung der Ports hatte ich natürlich vergessen. Trotzdem geht`s nicht.

Server tun:

mknod /var/tmp/tun c 10 200

dev tun0
dev-node /dev/misc/net/tun
ifconfig 192.168.1.1 192.168.1.2
secret /var/tmp/secret.key
proto tcp-server
port 1194
verb 4
route 192.168.178.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
daemon

client tun:

mknod /var/tmp/tun c 10 200

dev tun
dev-node /var/tmp/tun
ifconfig 192.168.1.2 192.168.1.1
secret /var/tmp/secret.key
proto tcp-client
port 1194
remote xxxxx.dynalias.com
verb 4
route 192.168.2.0 255.255.255.0
push "route 192.168.178.0 255.255.255.0"
daemon

Server tap:

mknod /var/tmp/tun c 10 200

dev tap0
dev-node /dev/misc/net/tun
ifconfig 192.168.2.2 255.255.255.0
secret /var/tmp/secret.key
proto tcp-server
port 1195
verb 4
daemon

client tap:

ifconfig 192.168.2.3 255.255.255.0
remote xxxxx.dynalias.com 
secret F:\\OpenVPN\\config\\secret.key
dev tap
proto tcp-client
port 1195
verb 5

Vielleicht siehst Du ja hier schon einen Fehler und ich spar mir mal noch das Log.

Die tun Verbindung läuft bis ich den tap-Server starte.
Dabei erscheint dann folgende Fehlermeldung:
multid(391): tap0: SIOCGIFADDR cannot assign requested adress(126)

Besten Dank. Anton

 

[MaxMuster]

Ich denke, der Fehler ist, dass du versehntlich versuchst, TUN mit TAP zu verbinden.

Die Client-Config für TAP muss auch den anderen Port ansprechen (die "port" Angabe ist für den "lokalen" Port, der ist dafür beim Client egal). Du benötigst also:

remote xxxxx.dynalias.com 1195

Jörg

 

[pollonhokairos]

Hab jetzt also beim client tap

remote xxxxx.dynalias.com 1195

Bleibt aber dabei - sobald tap-server gestartet - Verbindung tun weg.

Noch eine Idee?

 

[MaxMuster]

Und wie ist das mit dem Interface:
Warum legst du denn auf dem Server eins in /tmp an und nutzt dann das "/dev/misc/net/tun"? Ist das wirklich da, oder müsstest du auch da "dev-node /var/tmp/tun" nutzen?

Jörg

EDIT Hier mal eine Test-Konfig von mir, extra noch eine zweite TCP-Config (zu dem alten Test, ob es denn überhaput mit TCP geht) hinzugefügt ;-):

/var/tmp $ cat /mod/etc/openvpn.conf
##############################################################
#
#  OpenVPN 2.1 Config, generated Sat Sep 22 13:07:14 CEST 2007
#
##############################################################
proto udp
port 1194
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
mode server
ifconfig-pool x.x.x.x y.y.y.y
ifconfig x.x.x.x 255.255.255.0
push "route-gateway x.x.x.x"
max-clients 1
tun-mtu 1500
mssfix
verb 3
daemon
cipher AES-128-CBC
comp-lzo
float
keepalive 10 120
/var/tmp $ cat /mod/etc/openvpn_TCP_1195.conf
##############################################################
#
#  OpenVPN 2.1 Config, generated Sat Sep 22 13:07:20 CEST 2007
#
##############################################################
proto tcp-server
port 1195
dev tun
secret /tmp/flash/static.key
ifconfig 192.168.200.1 192.168.200.2
tun-mtu 1500
mssfix
verb 3
daemon
cipher BF-CBC
comp-lzo
keepalive 10 120
/var/tmp $
/var/tmp $ cat /mod/etc/openvpn_Config3.conf
##############################################################
#
#  OpenVPN 2.1 Config, generated Mon Sep 24 15:37:21 CEST 2007
#
##############################################################
proto tcp-server
port 1196
dev tap
secret /tmp/flash/static.key
ifconfig 192.168.178.12 255.255.255.0
push "route-gateway 192.168.178.12"
max-clients 1
tun-mtu 1500
mssfix
verb 3
daemon
cipher BF-CBC
comp-lzo
keepalive 10 120
/var/tmp $ ifconfig
[...snip...]
tap0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:x.x.x.x  Bcast:x.x.x.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
[...snip...]

tap1      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:192.168.178.12  Bcast:192.168.178.255  Mask:255.255.255.0
[...snip...]


tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.200.1  P-t-P:192.168.200.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
[...snip...]

/var/tmp $

 

[pollonhokairos]

Und wie ist das mit dem Interface:
Warum legst du denn auf dem Server eins in /tmp an und nutzt dann das "/dev/misc/net/tun"? Ist das wirklich da, oder müsstest du auch da "dev-node /var/tmp/tun" nutzen?

Wenn ich in /misc anlege wird der server nicht gestartet.
Gerade mit /tmp überprüft - geht nicht.

Gewundert hat mich das auch schon. Aber als Laie macht man viele Sachen einfach nach - wie die kleinen Kinder.
Soweit ich mich erinnere, hab ich das auch hier aus dem Forum und müsste wegen des Kernel 24 sein.

"Ifconfig" zeigt ein tun0 device - wenn Du das meintest.

Deine Konfiguration verwirrt mich momentan mehr als sie mir hilft. Du verwendest ja keinen statischen Schlüssel und manche Befehle kenne ich nicht. Du hast tap0 und tap1 - liegt wohl aber an Deiner Konfiguration? Ich brauch doch nur eins?

Vielleicht nochmal mein Ablauf:

- server tun Box und Client tun Box verbinden sich.

- ich starte den tap-Server über ssh

- Log zeigt dabei: - "mknod: /var/tmp/tun: file exists
"ifconfig" zeigt aber tap0 device

- Verbindung tun bricht ab ( kein Ping am NB) - jedoch kann ich den tun-Server weiterhin im Putty-Fenster pingen - warum??

-"ifconfig" der Client-Box zeigt: tun0-00 Linc encap: UNSPEC HWaddress : lauter 00-00-00
Ist das normal?

-tap Verbindung läuft dann normal

- durch Eingabe von

/var/tmp/openvpn --config /var/tmp/server.ovpn

in der Server-Box ist die tun Verbindung wieder intakt.
- dann wieder tap - geht.

- dann muß ich die tun-server Instanzen erst killen um mit

/var/tmp/openvpn --config /var/tmp/server.ovpn

die tun-Verbindung wieder zum Laufen zu bringen.

Also funktionieren die Verbindungen an sich schon.


Der tun-Sever restartet aber nur, wenn ich den laufenden server kille und neu starte.

Vielleicht hilft ja meine Beschreibung.
Ansonnsten sollte ich wohl das Ganze erstmal begraben.
Zwar schade, aber den mir wichtigen Zugang zur Kasse habe ich ja.
Und wenn unbedingt kann ich ja noch eine tap Verbindung zwischen den Boxen einrichten, die ich halt dann nur bei Bedarf starte.

Aber die Hoffnung stirbt zuletzt und es nervt mich doch, daß all meine und Deine Zeit noch nicht vom Erfolg beschienen werden.

Danke deshalb nochmals für das Schenken Deiner Zeit.

Anton

 

[MaxMuster]

Ich schaue es morgen mal genauer an. Nur kurz für jetzt:
- Das mknod musst du (höchstens) einmal machen, dann, wenn es noch keine Datei für das tun-Device gibt (wenn es /dev/misc/net/tun gibt, brauchst du den Befehl also nicht)
- Was heißt "Verbindung bricht ab"? Ping von welcher IP auf welche IP?
- Schick doch mal bitte ein "ifconfig" und ein "route" vom Server einmal vor und einmal nach den Starten des zweiten VPN-Servers.
- Die Konfigs heißen aber verschieden, also "/var/tmp/server.ovpn" und "/var/tmp/tapserver.ovpn" oder so?!?

Das kriegen wir schon hin ;-)

Jörg

 

[pollonhokairos]

- Die Konfigs heißen aber verschieden, also "/var/tmp/server.ovpn" und "/var/tmp/tapserver.ovpn" oder so?!?

Das kriegen wir schon hin ;-)

Jörg

Ja, Konfig heißen server und servertap

Rest dann morgen.

Noch am Rande: Hab gerade mein NB mal neu gestartet und wie es scheint legt mir XP auch noch Steine in den Weg - war eine falsche Route drin.

 

[MaxMuster]

- Verbindung tun bricht ab ( kein Ping am NB) - jedoch kann ich den tun-Server weiterhin im Putty-Fenster pingen - warum??

Das müsstest du bitte genauer erklären: Welcher Ping "bricht ab" , welche SSH-Session (vom Putty) existiert noch und wass kann noch von wo gepingt werden.

-"ifconfig" der Client-Box zeigt: tun0-00 Linc encap: UNSPEC HWaddress : lauter 00-00-00
Ist das normal?

Ja (siehe meinen Post beim tun0).

Der weitere Ablauf ist für mich noch unklar, was wird wann gestartet, wann (und wie genau) wird vorher was gestoppt/gekillt.

Also nach dem Starten vom TAP-Server ist die TUN-Verbindung weg, dann startest du den TUN-Server nochmal.
Ist der Server denn zu dem Zeitpunkt noch da? Bitte mal mit "ps" prüfen. Wenn ein "Neustart" gelingt, kann eigentlich der Server nicht gelaufen sein, sonst könntest du den TCP-Port nicht belegen, weil auf dem schon der "alte" Prozess lauschte...
Zu diesem Zeitpunkt laufen dann TAP und TUN beide gleichzeitig?

Mit diesen Angaben und dem Routing/ifconfig (siehe meine Anfrage oben) zu den Zeitpunkten kriegen wir das sicher hin.

Jörg

 

[ts6911]

Hallo, ich versuche krampfhaft mit dem in diesem Forum aufgeschnappten Halbwissen eine VPN Verbindung zwischen zwei 7170 Boxen hinzubekommen. Mittlerweise bekomme ich openvpn SOftware auf der Prozessliste zu sehen, aber keine Verbindung von Box zu Box. Ein Ping funktioniert, aber auf der Clientseite bekomme ich die Fehlermeldung "no route to host".
Nun schaue ich heute morgen in die ar7.cfg und die sieht völlig anders aus !
Liegt das an der Firmware Version 29.04.39/40 ?
Das Problem ist nun : Der Block mit den forwardroules ist so nicht mehr da.
Wo öffne ich nun den Port 1194?:noidea:
Über eure Hilfe würde ich mich sehr freuen !

 

[MaxMuster]

In irgendeiner Form müsste der aber drin sein, ich habe die Box jedoch nicht.
Zur Not trage mal in der GUI zwei, drei "Dummy Weiterleitungen" ein und schau dann , was sich der dann in der ar7.cfg verändert hat. Wenn du den Part mal posten könntest...

Jörg

 

[ts6911]

Vielen Dank für den Hinweis !
Habe Dummys 88.88.88.88 und 99.99.99.99 angelegt und wiedergefunden.
Die entsprechende Stelle in der ar7.cfg sieht jetzt so aus :

dsldpconfig {
security = dpsec_firewall;
lowinput {
policy = "permit";
accesslist =
"deny ip any 242.0.0.0 255.0.0.0",
"deny ip any host 255.255.255.255",
"deny udp any any eq 135",
"deny tcp any any eq 135",
"deny udp any any range 137 139",
"deny tcp any any range 137 139",
"deny udp any any range 161 162",
"deny udp any any eq 520",
"deny udp any any eq 111",
"deny udp any any eq 22289",
"deny udp any any eq 1710",
"deny udp any any eq 1048",
"deny udp any any eq 158",
"deny udp any any eq 515";
}
lowoutput {
policy = "permit";
}
highinput {
policy = "permit";
}
highoutput {
policy = "permit";
accesslist =
"reject ip any 242.0.0.0 255.0.0.0",
"deny ip any host 255.255.255.255",
"reject ip any 169.254.0.0 255.255.0.0",
"reject udp any any eq 135",
"reject tcp any any eq 135",
"reject udp any any range 137 139",
"reject tcp any any range 137 139",
"reject udp any any range 161 162",
"reject udp any any eq 520",
"reject udp any any eq 111",
"reject udp any any eq 22289",
"reject udp any any eq 1710",
"reject udp any any eq 1048",
"reject udp any any eq 158",
"reject udp any any eq 515",
"reject icmp any 149.1.1.0 255.255.255.0";
}
forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
"tcp 0.0.0.0:21 88.88.88.88:21 0 # FTP-Server",
"udp 0.0.0.0:4672 99.99.99.99:4672 0 # eMule UDP";
shaper = "globalshaper";
}

Dort setze ich jetzt die Zeile :

"tcp 0.0.0.0:1194 192.168.100.1:1194 0 #OpenVPN", ein ?
oder
"udp 0.0.0.0:1194 192.168.100.1:1194 0 #OpenVPN", ?

Müssen diese Einträge auch auf der Clientbox gemacht werden ?

 

[MaxMuster]

Ob TCP oder UDP hängt von deiner (geplanten) Konfig ab, "ohne Not" würde ich zum "Standard" UDP raten. Allerdings würde ich dir empfehlen, die Config in der ar7.cfg "auf beiden Seiten" mit 0.0.0.0 zu machen, also z.B.:

udp 0.0.0.0:1194 0.0.0.0:1194 0 #OpenVPN",

Der Eintrag ist nur auf der Server-Seite nötig, weil die "von außen angequatscht" wird.

Jörg