Discussion:
Fehlersuche bei einer OpenVPN-Verbindung
Jens Küspert
2010-08-09 19:38:07 UTC
Permalink
Hallo Liste,

ich versuche OpenVPN-Tunnel zu unserem Server (4.01) zu legen. Im Prinzip
läuft alles wie erwartet, aber ich bekomme keine Verbindung zum Server über
das VPN.

Eine Verbindung zum ipcop "funktioniert" (ich kann sein Web-Interface auf Port
445 aufrufen und auch eine ssh-Verbindung zum Port 222 aufbauen). Gemäß dem
dokumentierten Wunschverhalten werden auch die Standardrouten über die VPN-
Verbindung geführt. Soweit alles prima - nur bekomme ich keine Verbindung zu
10.16.1.1 aufgebaut (gibt immer einen Timeout). Dabei spielt der Zielport
keine Rolle (probiert habe ich 22 und 242).

Habt ihr schon einmal Erfahrungen mit dieser Art von Verhalten gemacht? Wo
könnte ich für die Diagnose ansetzen?

Ich bin für jeden Fingerzeig dankbar...

Grüße,
--
- Jens -
Raunheimer
2010-08-09 20:37:21 UTC
Permalink
Hallo Jens,
Post by Jens Küspert
Hallo Liste,
Eine Verbindung zum ipcop "funktioniert" (ich kann sein Web-Interface auf Port
445 aufrufen und auch eine ssh-Verbindung zum Port 222 aufbauen). Gemäß dem
dokumentierten Wunschverhalten werden auch die Standardrouten über die VPN-
Verbindung geführt. Soweit alles prima - nur bekomme ich keine Verbindung zu
10.16.1.1 aufgebaut (gibt immer einen Timeout). Dabei spielt der Zielport
keine Rolle (probiert habe ich 22 und 242).
Habt ihr schon einmal Erfahrungen mit dieser Art von Verhalten gemacht? Wo
könnte ich für die Diagnose ansetzen?
versuchs mal mit https://10.16.1.1:242

Gruß

Alois
Jens Küspert
2010-08-10 06:24:17 UTC
Permalink
Hallo Alois!
Post by Raunheimer
Post by Jens Küspert
Habt ihr schon einmal Erfahrungen mit dieser Art von Verhalten gemacht?
Wo könnte ich für die Diagnose ansetzen?
versuchs mal mit https://10.16.1.1:242
Hm, das habe ich ja bereits. Mein Browser (Firefox) sagt dann für einige Zeit
"Verbinden mit 10.16.1.1..." und dann kommt "Fehler: Netzwerk-
Zeitüberschreitung".

Ein ping auf 10.16.1.1 bringt keine Antwort. Auch ein tracepath kommt nicht
zum Ziel.

$ ping 10.16.1.1
PING 10.16.1.1 (10.16.1.1) 56(84) bytes of data.
^C
--- 10.16.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms

$ tracepath 10.16.1.1
1: 172.16.18.6 (172.16.18.6) 0.278ms pmtu 1200
1: 172.16.18.1 (172.16.18.1) 396.082ms
1: 172.16.18.1 (172.16.18.1) 77.799ms
2: no reply
3: no reply
4: no reply
^C

Interessanterweise hat tracepath auf 10.16.1.254 Erfolg:

$ tracepath 10.16.1.254
1: 172.16.18.6 (172.16.18.6) 0.254ms pmtu 1200
1: 10.16.1.254 (10.16.1.254) 77.502ms reached
1: 10.16.1.254 (10.16.1.254) 80.112ms reached
Resume: pmtu 1200 hops 1 back 64

Irgendetwas scheint meine Pakete in Richtung Server zu blockieren, oder?

Ratlos,
--
- Jens -
Raunheimer
2010-08-10 06:31:32 UTC
Permalink
Hallo Jens,
Post by Jens Küspert
Irgendetwas scheint meine Pakete in Richtung Server zu blockieren, oder?
schalt mal Deine Firewall zu Hause kurzzeitig aus.

Ping auf 10.16.1.1 geht bei mir.

tracepath 10.16.1.1

Da kommt die Meldung der Befehl sei falsch geschrieben.


Gruß

Alois
Jens Küspert
2010-08-10 06:49:57 UTC
Permalink
Post by Raunheimer
Post by Jens Küspert
Irgendetwas scheint meine Pakete in Richtung Server zu blockieren, oder?
schalt mal Deine Firewall zu Hause kurzzeitig aus.
Öh - welche Firewall? Der Client-Rechner ist mit Ubuntu ausgestattet (ohne
spezielle FW-Software) und versteckt sich hinter einem handelsüblichen DSL-
Modem/Router (FRITZ!Box SL WLAN). Ich wüsste jetzt nicht, welche Firewall ich
dort ausschalten kann.
Post by Raunheimer
Ping auf 10.16.1.1 geht bei mir.
tracepath 10.16.1.1
Da kommt die Meldung der Befehl sei falsch geschrieben.
Je nach Betriebssystem heißt der Befehl wohl anders, unter Linux war es früher
traceroute und unter Windows ist's tracert (meine ich).

Grüße,
--
- Jens -
Müller, Peter
2010-08-10 10:32:53 UTC
Permalink
Peter Müller schrieb am 10.08.2010 12:32
_____________________________________________________________________

Hallo Jens,
Post by Jens Küspert
Post by Jens Küspert
Irgendetwas scheint meine Pakete in Richtung Server zu blockieren,
oder?
Wird denn die VPN-Verbindung vom IPcop richtig geroutet?

Was spricht die Ausgabe von ip route und/oder route -n auf Deinem Ubuntu PC?
Da müsste ja ein entsprechender Eintrag mit 10.16.x.y/z drin stehen.
Post by Jens Küspert
Je nach Betriebssystem heißt der Befehl wohl anders, unter Linux war es
früher traceroute und unter Windows ist's tracert (meine ich).
Heißt bei Linux immer noch traceroute und bei Windows, zumindest bis XP, immer noch tracert ;-)

Gruß Peter


Peter Müller
Systemtechniker Öffentliche Auftraggeber
Projekt- & Servicemanagment

URANO Informationssysteme GmbH
Brückes 72
55545 Bad Kreuznach

Tel: +49 671 84030 139
Fax: +49 671 84030 433
Mobil: +49 163 9160 894
E-Mail: Peter.Mueller-***@public.gmane.org

Handelsregister: AG Bad Kreuznach Blatt HRB 3363
Geschäftsführer: Andreas Krafft, Heiner Sepeur
Steuer-Nr: 06650/00153 | USt-ID: DE 148266313

____________________________________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
____________________________________________________________________________


_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Jens Küspert
2010-08-10 13:33:28 UTC
Permalink
Post by Müller, Peter
Wird denn die VPN-Verbindung vom IPcop richtig geroutet?
Was spricht die Ausgabe von ip route und/oder route -n auf Deinem Ubuntu
PC? Da müsste ja ein entsprechender Eintrag mit 10.16.x.y/z drin stehen.
Ich habe das Orakel geschwind befragt, und es sagt:

$ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.18.1 172.16.18.5 255.255.255.255 UGH 0 0 0 tun0
172.16.18.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
91.57.91.55 192.168.178.1 255.255.255.255 UGH 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 2 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
10.16.0.0 172.16.18.5 255.240.0.0 UG 0 0 0 tun0
0.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth1

Wie ist das nun zu verstehen? Ich denke so:

Alles was zu 10.16.0.0 "passt" (also auch 10.16.1.1 oder 10.16.1.254) wird in
Richtung 172.16.18.5 verschickt. Von dort aus finde ich keinen weiteren Weg -
aber vermutlich verstehe ich einfach noch nicht, was 0.0.0.0 als Router
bedeutet (ist es die default-Route für das entsprechende Interface?).

Mich irritiert dabei, dass der Weg zu 10.16.1.254 gefunden wird - der Weg zu
10.16.1.1 jedoch nicht.
Post by Müller, Peter
Heißt bei Linux immer noch traceroute und bei Windows, zumindest bis XP,
immer noch tracert ;-)
Hm - und warum hat "mein" Ubuntu dann tracepath im Angebot? Gibt's da subtile
Unterschiede?!

Grüße,
--
- Jens -
Axel Morawietz
2010-08-10 14:23:43 UTC
Permalink
Hallo,
Post by Jens Küspert
$ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.18.1 172.16.18.5 255.255.255.255 UGH 0 0 0 tun0
172.16.18.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
91.57.91.55 192.168.178.1 255.255.255.255 UGH 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 2 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
10.16.0.0 172.16.18.5 255.240.0.0 UG 0 0 0 tun0
0.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth1
Alles was zu 10.16.0.0 "passt" (also auch 10.16.1.1 oder 10.16.1.254) wird in
Richtung 172.16.18.5 verschickt. Von dort aus finde ich keinen weiteren Weg -
aber vermutlich verstehe ich einfach noch nicht, was 0.0.0.0 als Router
bedeutet (ist es die default-Route für das entsprechende Interface?).
Doch, 172.16.18.5 erreicht er direkt über tun0.

Hast Du denn eine IP erhalten, kannst Du 172.16.18.5 pingen?
Was liefert OpenVPN, wenn Du es auf "verbose" stellst?

Stimmen denn die Rückrouten bzw. wird das VPN geNATted?

HTH,
Axel

_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Müller, Peter
2010-08-10 15:19:42 UTC
Permalink
Peter Müller schrieb am 10.08.2010 17:19
_____________________________________________________________________
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.18.1 172.16.18.5 255.255.255.255 UGH 0 0 0 tun0
Route zum Tunnelendpunkt auf dem IPcop durch den Endpunkt in Deinem PC
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.18.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Route vom default-Gateway zum Tunnelendpunkt
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
91.57.91.55 192.168.178.1 255.255.255.255 UGH 0 0 0 eth1
Route von der FritzBox zum Internetprovider
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
192.168.178.0 0.0.0.0 255.255.255.0 U 2 0 0 eth1
Route Deinem LAN ins Internet
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
Eintrag für den Fall, dass keine korrekte IP erhalten wird (LinkLocal)
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
10.16.0.0 172.16.18.5 255.240.0.0 UG 0 0 0 tun0
1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ paedML
Route zum paedML-Netz durch den Tunnelendpunkt auf Deinem PC
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEFAULT
Erste default-Route "ins Internet" über den Tunnelendpunkt auf Deinem PC
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
128.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
Die IP sagt mir jetzt gerade nix, geht aber auch durch den Tunnel
Post by Jens Küspert
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 0 0 0 eth1
3 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEFAULT
Zweite default-Route "ins Internet", normaler Weg über die FritzBox
Post by Jens Küspert
Alles was zu 10.16.0.0 "passt" (also auch 10.16.1.1 oder 10.16.1.254) wird in Richtung 172.16.18.5 verschickt.
Genau, ist die mit "1" markierte Route durch den OpenVPN-Tunnel (Iface tun0).
Post by Jens Küspert
ist es die default-Route für das entsprechende Interface?
Nicht für das Interface, sondern für das gesamte System ins Internet.
Post by Jens Küspert
Mich irritiert dabei, dass der Weg zu 10.16.1.254 gefunden wird - der Weg zu 10.16.1.1 jedoch nicht.
Aufgrund der Routen (mal abgesehen von den doppelten default's) stimmt die Routing Tabelle.
Du kannst aber mal bei aktiver VPN-Verbindung folgenden Befehl auf der Konsole absetzen um die default-Route "3" zu löschen:

route del default dev eth1.

Dann teste mal den Zugriff auf den paedML-Server und auf das Internet.
Post by Jens Küspert
Post by Müller, Peter
Heißt bei Linux immer noch traceroute und bei Windows, zumindest bis
XP, immer noch tracert ;-)
Hm - und warum hat "mein" Ubuntu dann tracepath im Angebot? Gibt's da
subtile Unterschiede?!
Gut möglich, dass bei Ubuntu ein zusätzliches Paket existiert. Aber im Paketmanagement sollte auch als traceroute enthalten sein (hab leider keines greifbar zum nachsehen). Zu den Unterschieden kann ich jetzt konkret nix sagen.

Viele Grüße
Peter

Peter Müller
Systemtechniker Öffentliche Auftraggeber
Projekt- & Servicemanagment

URANO Informationssysteme GmbH
Brückes 72
55545 Bad Kreuznach

Tel: +49 671 84030 139
Fax: +49 671 84030 433
Mobil: +49 163 9160 894
E-Mail: Peter.Mueller-***@public.gmane.org

Handelsregister: AG Bad Kreuznach Blatt HRB 3363
Geschäftsführer: Andreas Krafft, Heiner Sepeur
Steuer-Nr: 06650/00153 | USt-ID: DE 148266313

____________________________________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
____________________________________________________________________________


_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Jens Küspert
2010-08-10 21:07:26 UTC
Permalink
Hallo Peter,

danke für die prompte Analyse.
Post by Müller, Peter
Du kannst aber mal bei aktiver VPN-Verbindung folgenden
route del default dev eth1.
Gemacht.

$ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.18.1 172.16.18.5 255.255.255.255 UGH 0 0 0 tun0
172.16.18.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
91.57.91.55 192.168.178.1 255.255.255.255 UGH 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 2 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
10.16.0.0 172.16.18.5 255.240.0.0 UG 0 0 0 tun0
0.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0

Das sieht mir nach nur noch einer default-Route aus, oder?
Post by Müller, Peter
Dann teste mal den Zugriff auf den paedML-Server und auf das Internet.
Auf "das Internet":

$ tracepath gmx.de
1: 172.16.18.6 (172.16.18.6) 0.516ms pmtu 1200
1: 172.16.18.1 (172.16.18.1) 76.510ms
1: 172.16.18.1 (172.16.18.1) 79.583ms
2: 217.0.118.212 (217.0.118.212) 172.850ms
3: 87.186.251.118 (87.186.251.118) 168.594ms asymm 4
4: ka-eb1-i.KA.DE.NET.DTAG.DE (62.154.74.38) 186.237ms asymm 9
5: dtag.bb-c.bs.kae.de.oneandone.net (80.156.160.54) 180.681ms asymm 6
6: ae-2.gw-distg-b.bs.ka.oneandone.net (212.227.116.215) 182.993ms asymm 7
7: gmx.net (213.165.65.50) 184.154ms reached
Resume: pmtu 1200 hops 7 back 57


Auf den paedML-Server bzw. den ipcop:

$ slogin -l root 10.16.1.1
ssh: connect to host 10.16.1.1 port 22: Connection timed out
$ slogin -p 222 -l root 10.16.1.254
root-***@public.gmane.org's password:
Last login: Mon Aug 9 20:30:07 2010 from 172.16.18.6
***@ipcop:~ # logout
Connection to 10.16.1.254 closed.


Wenn ich openvpn mit "verbose 5" starte bekomme ich einige Infos, aber keine
Fehlermeldungen. Bei den o.g. Versuchen erscheinen die Buchstaben r, w, R und
W - ich nehme an das sind Kodierungen für gelesen bzw. geschriebene Daten.

Tut mir leid, wenn ich mich doof anstelle - aber ich verstehe das Problem
nicht. Die Routen sind korrekt, es gehen Daten über den Tunnel. Ich kann
Rechner über den Tunnel erreichen (10.16.1.254 und "das Internet"). Warum
komme ich nicht auf den Server (10.16.1.1)?!?!?!
--
- Jens -
Müller, Peter
2010-08-11 14:15:44 UTC
Permalink
Peter Müller schrieb am 11.08.2010 16:15
_____________________________________________________________________

Hi Jens,
Post by Jens Küspert
$ route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
172.16.18.1 172.16.18.5 255.255.255.255 UGH 0 0 0 tun0
172.16.18.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
91.57.91.55 192.168.178.1 255.255.255.255 UGH 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 2 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
10.16.0.0 172.16.18.5 255.240.0.0 UG 0 0 0 tun0
0.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 172.16.18.5 128.0.0.0 UG 0 0 0 tun0
So soll das aussehen.
Post by Jens Küspert
$ tracepath gmx.de
1: 172.16.18.6 (172.16.18.6) 0.516ms
1: 172.16.18.1 (172.16.18.1) 76.510ms
1: 172.16.18.1 (172.16.18.1) 79.583ms
2: 217.0.118.212 (217.0.118.212) 172.850ms
3: 87.186.251.118 (87.186.251.118) 168.594ms
4: ka-eb1-i.KA.DE.NET.DTAG.DE (62.154.74.38) 186.237ms
5: dtag.bb-c.bs.kae.de.oneandone.net (80.156.160.54) 180.681ms
6: ae-2.gw-distg-b.bs.ka.oneandone.net (212.227.116.215) 182.993ms
7: gmx.net (213.165.65.50) 184.154ms
Passt ja.
Post by Jens Küspert
$ slogin -l root 10.16.1.1
ssh: connect to host 10.16.1.1 port 22: Connection timed out
Hört sich nach der Firewall auf der paedML an.
Post by Jens Küspert
Wenn ich openvpn mit "verbose 5" starte bekomme ich einige Infos, aber
keine Fehlermeldungen.
OpenVPN an sich läuft sauber, sieht man ja am trace auf gmx.
Post by Jens Küspert
Tut mir leid, wenn ich mich doof anstelle - aber ich verstehe das
Problem nicht. Die Routen sind korrekt, es gehen Daten über den Tunnel.
Ich kann Rechner über den Tunnel erreichen (10.16.1.254 und "das
Internet"). Warum komme ich nicht auf den Server (10.16.1.1)?!?!?!
Hmm, andere Idee.

Peter Müller
Systemtechniker Öffentliche Auftraggeber
Projekt- & Servicemanagment

URANO Informationssysteme GmbH
Brückes 72
55545 Bad Kreuznach

Tel: +49 671 84030 139
Fax: +49 671 84030 433
Mobil: +49 163 9160 894
E-Mail: Peter.Mueller-***@public.gmane.org

Handelsregister: AG Bad Kreuznach Blatt HRB 3363
Geschäftsführer: Andreas Krafft, Heiner Sepeur
Steuer-Nr: 06650/00153 | USt-ID: DE 148266313

____________________________________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
____________________________________________________________________________


_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Müller, Peter
2010-08-11 14:21:41 UTC
Permalink
Peter Müller schrieb am 11.08.2010 16:21
_____________________________________________________________________

Sorry, hab zu schnell auf meinem Klavier rumgehackt.
Tut mir leid, wenn ich mich doof anstelle - aber ich verstehe das Problem nicht. Die Routen sind korrekt, es gehen Daten über den Tunnel.
Ich kann Rechner über den Tunnel erreichen (10.16.1.254 und "das Internet"). Warum komme ich nicht auf den Server (10.16.1.1)?!?!?!
Aus dem Schulnetz klappt der ssh-Login? Vermutlich ist eine Firewall-Regel auf dem Server aktiv, welche die Verbindungen droppt.
Kannst Du mal die Ausgabe von iptables -L -nv vom paedML-Server als Datei posten?


Gruß Peter

Peter Müller
Systemtechniker Öffentliche Auftraggeber
Projekt- & Servicemanagment

URANO Informationssysteme GmbH
Brückes 72
55545 Bad Kreuznach

Tel: +49 671 84030 139
Fax: +49 671 84030 433
Mobil: +49 163 9160 894
E-Mail: Peter.Mueller-***@public.gmane.org

Handelsregister: AG Bad Kreuznach Blatt HRB 3363
Geschäftsführer: Andreas Krafft, Heiner Sepeur
Steuer-Nr: 06650/00153 | USt-ID: DE 148266313

____________________________________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
____________________________________________________________________________


_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Jens Küspert
2010-08-11 20:37:28 UTC
Permalink
Hallo Peter,

danke für Deine Hartnäckigkeit.
Post by Müller, Peter
Aus dem Schulnetz klappt der ssh-Login?
Ja, da gibt es keine Probleme.
Post by Müller, Peter
Vermutlich ist eine Firewall-Regel
auf dem Server aktiv, welche die Verbindungen droppt. Kannst Du mal die
Ausgabe von iptables -L -nv vom paedML-Server als Datei posten?
Die ganze Ausgabe ist komprimiert immer noch 11k groß, damit möchte ich die
Liste nicht vollspammen, Du bekommst sie als direkte Mail.

ABER: Mir scheint die letzte Zeile ist interessant. Sie lautet:


727K 44M REJECT 0 -- * * 0.0.0.0/0 0.0.0.0/0
reject-with icmp-port-unreachable

Könnte es sein, dass der Server gerne den "Rückweg" zum anrufenden Rechner
finden können möchte? Und das geht das eben über OpenVPN nicht?
--
- Jens -
Müller, Peter
2010-08-12 08:15:05 UTC
Permalink
Peter Müller schrieb am 12.08.2010 10:14
_____________________________________________________________________

Guten Morgen Jens,
Post by Jens Küspert
danke für Deine Hartnäckigkeit.
Keine Ursache, wie geschrieben Routing etc. ist manchmal "Gift für die Nerven" ;-)
Post by Jens Küspert
Post by Müller, Peter
Vermutlich ist eine Firewall-Regel
auf dem Server aktiv, welche die Verbindungen droppt. Kannst Du mal
die Ausgabe von iptables -L -nv vom paedML-Server als Datei posten?
Die ganze Ausgabe ist komprimiert immer noch 11k groß, damit möchte ich
die Liste nicht vollspammen, Du bekommst sie als direkte Mail.
Joo, kam an und ich habe die Liste mal durchforstet und das Problem lokalisiert.
Post by Jens Küspert
727K 44M REJECT 0 -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Damit werden alle Anfragen, welche nicht über eine der vorherigen Regeln abgedeckt werden, mit der Antwort, dass der Port nicht erreichbar wäre, zurückgewiesen.

Die Firewall der paedML lässt nur die Anfragen durch, welche explizit mit einer MAC-Adresse eingetragen sind. Du müsstest dann Deinen PC mit MAC-Adresse als Workstation am Server registrieren. Danach sollte auch der SSH-Zugriff klappen.

In der Datei findest Du ab Zeile 1645 die zugelassenen MAC-Adressen für den Zugriff auf SSH (davor und danach auch für die anderen Dienst des Servers).

Gruß Peter

Peter Müller
Systemtechniker Öffentliche Auftraggeber
Projekt- & Servicemanagment

URANO Informationssysteme GmbH
Brückes 72
55545 Bad Kreuznach

Tel: +49 671 84030 139
Fax: +49 671 84030 433
Mobil: +49 163 9160 894
E-Mail: Peter.Mueller-***@public.gmane.org

Handelsregister: AG Bad Kreuznach Blatt HRB 3363
Geschäftsführer: Andreas Krafft, Heiner Sepeur
Steuer-Nr: 06650/00153 | USt-ID: DE 148266313

____________________________________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
____________________________________________________________________________


_______________________________________________
Hinweis:
Bitte melden Sie sich unter http://www.support-netz.de/hotline.html
an der Hotline des Support-Netzes an.
Nur so koennen wir eine langfristige Weiterentwicklung und einen
nachhaltigen und guten Support gewaehrleisten. Vielen Dank.
Jens Küspert
2010-11-03 20:24:00 UTC
Permalink
Moin Liste,

ich versuche zur Zeit einmal wieder ein OpenVPN-Problem zu diagnostizieren.

Der letzte Versuch lag im August und konnte noch nicht erfolgreich
abgeschlossen werden. Wir waren soweit gekommen, dass die TCP-Pakete zwar bis
zum Server (10.16.1.1) kommen, dort aber von der Firewall verworfen werden.

Peter Müller schrieb dazu am 12.08.2010 10:14
Post by Müller, Peter
Die Firewall der paedML lässt nur die Anfragen durch, welche explizit mit
einer MAC-Adresse eingetragen sind. Du müsstest dann Deinen PC mit
MAC-Adresse als Workstation am Server registrieren. Danach sollte auch der
SSH-Zugriff klappen.
OK, das verstehe ich mittlerweile. Die MAC-Adressen werden von wimport.sh aus
der workstations-Datei ermittelt. Mein Problem: Wenn ich per OpenVPN "komme",
haben die Pakete doch gar keine Absender-MAC-Adresse, oder?

Um überhaupt mal einen Fuß in die Tür zu bekommen, habe ich so gedacht: Das
tun-interface auf dem entfernten Rechner bekommt eine IP aus dem Subnetz
172.16.18.0/24 zugewiesen (so steht es auch in der firewall-Regeln des IPCop),
also trage ich diese auf dem server als erlaubt ein:

# iptables -A IN-intern -s 172.16.18.0/24 -j ACCEPT

Aber kein Erfolg. Hm - also logging einschalten mit

# iptables -A INPUT -m limit --limit 15/minute -j LOG \
--log-level 7 --log-prefix "Dropped by firewall: "

Aber da bekomme ich dann nur verworfene Pakete mit dem Absender 10.16.1.1 (?!)
aufgelistet...

Nun bin ich wieder ratlos - und hoffe auf Inspiration aus der Liste...

Grüße,
--
- Jens -
Loading...