Unternehmen     Impressum     Kontakt
+ Antworten
Ergebnis 1 bis 8 von 8

Thema: Intranator als Openvpn Client

  1. #1
    thorian ist offline Registered User
    Registriert seit
    Apr 2006
    Beiträge
    7

    Intranator als Openvpn Client

    Aufgrund von Schwierigkeiten mit einem IPSEC Tunnel möchte ich auf der Intranator gerne OpenVPN + Clientzertifikat installieren. Die Frage ist, ob das machbar ist, oder ob das Nachteile nach sich zieht.

    BYE BERND

  2. #2
    Gerd von Egidy ist offline Administrator
    Registriert seit
    Dec 2001
    Ort
    Tübingen
    Beiträge
    829
    Hallo,

    die Verwendung von OpenVPN wird im Intranator derzeit nicht unterstützt.

    Was für Probleme haben Sie denn mit dem IPSec?

    Herzliche Grüße,

    v. Egidy

  3. #3
    thorian ist offline Registered User
    Registriert seit
    Apr 2006
    Beiträge
    7
    Ok, um darauf einzugehen hier die Randbedingungen :-)

    Eine Seite des VPNs wird durch ein Debian Cluster abgebildet auf welchem OpenSWan installiert ist. Dieses Cluster übernimmt viele Verbindungen zu Kunden und Standorten via IPSEC. Weiterhin gibt es verschiedene OpenVPN Konfigurationen, die verschiedene Verbindungsmodi unterstützen.

    Eine Verbindung kommt zustande und es wird in beide Richtungen geroutet .. soweit toll, nur bricht die Verbindung ab und zu ein. Beide Seiten geben vor, die Verbindung bestehe. Wir auf Clusterseite der Tunnel neu aufgebaut, so besteht das Problem weiterhin. Wird der Tunnel jedoch auf Intranatorseite neu initialisiert, so funktioniert hinterher alles wieder gut.

    Nun, soweit erstmal zum Szenario :-D

  4. #4
    Gerd von Egidy ist offline Administrator
    Registriert seit
    Dec 2001
    Ort
    Tübingen
    Beiträge
    829
    Hallo,

    ok, die IPSec-Verbindung ist also konfiguriert und funktioniert grundsätzlich, ist nur nicht dauerhaft stabil.

    Haben Sie mal versucht, auf beiden Seiten das Dead-Peer-Detection (im Intranator Offline-Erkennung genannt) zu aktivieren?

    Können beide Seiten von sich aus die Verbindung neu aufbauen?

    Verwenden Sie auf einer der beiden Seiten dynamische IPs oder haben beide Seiten feste IPs?

    Wenn Sie feste IPs haben, haben Sie die IPs als IPs eingetragen, oder haben Sie DNS-Namen eingetragen, die auf die IPs zeigen? Wenn Sie DNS-Namen verwenden, versuchen Sie es bitte mal mit IPs.

    Wie häufig treten diese Probleme in etwa auf? Ist das schon nach wenigen Minuten, vielleicht einmal am Tag oder erst nach ein paar Wochen?

    Herzliche Grüße,

    v. Egidy

  5. #5
    thorian ist offline Registered User
    Registriert seit
    Apr 2006
    Beiträge
    7
    Hallo,

    Grundsätzlich kann die Verbindung von beiden Seiten aufgebaut werden. Ist sie einmal abgestürzt, so kann dieses nur von der Intranator geschehen.

    Die Intranator hat eine dynamische IP, was durch folgenden Mechanismus auf dem Cluster mit der statischen IP abgefangen wird:

    /usr/bin/iptofile----------------------------------------------------------------------
    #!/bin/sh
    ping -c1 $1 | grep from | awk '{print $5}' > /tmp/$1.ip

    /usr/bin/reinitipsec-----------------------------------------------------------------
    #!/bin/sh

    ipsec auto --down $1
    ipsec auto --delete $1
    ipsec auto --rereadsecrets
    ipsec auto --add $1
    ipsec auto --up $1

    /usr/bin/updateipsec--------------------------------------------------------------
    #!/bin/sh

    echo "usage udateipsec example.dyndns.org tunnelname"

    #wir gucken ob die alte ip bereits da ist
    if [ -f /tmp/$1.ip ]; then
    echo "IPSECUPDATE - ipfile exists ... nothing to do" >> /var/log/messages
    else
    echo "IPSECUPDATE - creating ipfile" >> /var/log/messages
    iptofile $1
    exit
    fi

    # fuer bessere Lesbarkeit
    ipsectunnel=$2

    old_ip=`cat /tmp/$1.ip`
    echo $old_ip >> /var/log/messages

    new_ip=`ping -c 1 $1 | grep from | awk '{print $5}'`
    echo $new_ip >> /var/log/messages

    # wenn IPs gleich, dann mache nichts, andernfalls reinitialisiere
    if [ $old_ip = $new_ip ]; then
    echo "IPSECUPDATE - ip did not change - no reconfiguration" >> /var/log/messages
    exit
    else
    echo "IPSECUPDATE - update new ip in file" >> /var/log/messages
    iptofile $1
    echo "IPSECUPDATE - reconfiguring tunnel" >> /var/log/messages
    reinitipsec $ipsectunnel
    fi



    Die Probleme treten mehrfach am Tag auf und sind nicht voraussagbar

  6. #6
    Gerd von Egidy ist offline Administrator
    Registriert seit
    Dec 2001
    Ort
    Tübingen
    Beiträge
    829
    Hallo,

    Zitat Zitat von thorian Beitrag anzeigen
    Grundsätzlich kann die Verbindung von beiden Seiten aufgebaut werden.
    Das ist auf jeden Fall schon mal eine gute Basis.

    Zitat Zitat von thorian Beitrag anzeigen
    Ist sie einmal abgestürzt, so kann dieses nur von der Intranator geschehen.
    Das ist allerdings etwas merkwürdig. Eigentlich sollte die Verbindung von beiden Seiten wieder aufgebaut werden können.

    Zitat Zitat von thorian Beitrag anzeigen
    Die Intranator hat eine dynamische IP, was durch folgenden Mechanismus auf dem Cluster mit der statischen IP abgefangen wird:
    Ein Tipp: Falls Sie eine einigermaßen neue Strongswan-Version verwenden, können Sie den ganzen Aufwand umgehen, in dem Sie einfach z.B.

    right=%meinserver.dyndns.org

    schreiben. Bei der Syntax mit dem %dnsname erkennt das strongswan die Namensänderungen automatisch, lässt aber einen Verbindungsaufbau von der Gegenseite vor dem Update des DNS-Namens zu. Soweit ich weiß bietet openswan keinen vergleichbaren Mechanismus.

    Zitat Zitat von thorian Beitrag anzeigen
    Die Probleme treten mehrfach am Tag auf und sind nicht voraussagbar
    Ändert sich die IP des Intranators auch mehrfach am Tag? Ich vermute eher mal nein. Dann hätten die Probleme nichts mit dem Dyndns zu tun.

    Haben Sie mal versucht, auf beiden Seiten das Dead-Peer-Detection (im Intranator Offline-Erkennung genannt) zu aktivieren?

    Interessant wären auch die Logdateien, jeweils von beiden Seiten:

    Zum einen im Fehlerfall - meinen beide Seiten wirklich alles wäre gut, nur das Routing stimmt letztendlich nicht oder gibt es da auch auf IKE-Ebene Hinweise auf Fehler.

    Zum anderen beim Neuaufbau der Verbindung: was wird hier protokolliert, wenn Sie es nicht vom Intranator, sondern von Ihrem anderen Server aus versuchen?

    Was verwenden Sie für einen IPSec-Dienst (freeswan, openswan, strongswan,...) auf Ihrem Server? Was für eine Version?

    Welche Kernel-Version? Verwenden Sie die Kernel-Module (KLIPS) von freeswan oder openswan (d.h. Sie haben eine virtuelle ipsec0-Netzwerkkarte im System) oder das im Kernel enthaltene IPSec (keine ipsec0-Netzwerkkarte)?

    Wenn Ihnen die Logdateien für das Forum zu groß sind oder nicht für die Öffentlichkeit bestimmte Daten enthalten, können Sie auch gerne für diesen Fall ein Support-Ticket anlegen.

    Herzliche Grüße,

    v. Egidy

  7. #7
    thorian ist offline Registered User
    Registriert seit
    Apr 2006
    Beiträge
    7
    Hallo,

    das Logging zeigt, dass sich die IP im Falle eines Absturzes nicht geändert hat. Die Dead Peer Detection ist aktiv und hat als Testperiode 1 Minute.

    Hier die Version von Freeswan:

    ipsec auto --version
    ipsec auto 2.4.6

    Mehr Infos kann ich an dieser Stelle nicht geben, da man mich als Systemintegrator mit dem Auffinden von IP Telefonen aufhält. Mehr dazu also später.

  8. #8
    Gerd von Egidy ist offline Administrator
    Registriert seit
    Dec 2001
    Ort
    Tübingen
    Beiträge
    829
    Hallo,

    der Versionsnummer nach wird das wohl ein etwas älteres openswan sein, freeswan hat glaube ich bei 2.06 aufgehört, openswan ist derzeit bei 2.6.14.

    Wenn Sie kurz ein ifconfig aufrufen und dort eine Netzwerkkarte ipsec0 sehen, verwenden Sie KLIPS. Das ist mit openswan eigentlich eher unüblich. Wenn nein, dann verwenden Sie das im Kernel enthaltene IPSec.

    Erkennt denn das Dead Peer Detection von einer oder beiden Seiten, daß die Verbindung nicht mehr funktioniert?

    Herzliche Grüße,

    v. Egidy

+ Antworten

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein