Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 3 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Housten, I have a problem …

At work I have to use a VPN con­nec­tion. Curr­ent­ly the­re is set up a (so cal­led) SSH jump-host, that only accepts con­nec­tions from out­side the internal/VPN network.

Pro­blem with that: If the VPN con­nec­tion is up it’s not pos­si­ble to SSH to the jump-host any­mo­re, becau­se my local machi­ne (with the VPN con­nec­tion) has an inter­nal IP address and is not allo­wed to con­nect to the jump-host.

Solution

I crea­ted a udev rule for the VPN inter­face tun0.
That rules worke like this: Crea­te a new rou­te (to the jump-host) over my default net­work inter­face if the VPN con­nec­tion is up and dele­te that rule if tun0 wents down.

And here are this udev rules for you – and myself … 🙂

  1. Crea­te the file with/for both udev rules as root (you can free­ly name the file as you want): /etc/udev/rules.d/99-tun0.rules
  2. Insert the fol­lo­wing two lines/rules, replace 
    • 2.2.2.2 with the jump-host IP
    • 1.1.1.1 your local gate­way IP
    • default_interface with your local/default net­work inter­face (for me it’s wlp2s0; you can use ip addr to see all interfaces)
  3. Restart (as root) the udev ser­vice: systemctl status udev
KERNEL=="tun0", ACTION=="add", RUN+="/sbin/ip route add 2.2.2.2 via 1.1.1.1 dev default_interface"
KERNEL=="tun0", ACTION=="remove", RUN+="/sbin/ip route delete 2.2.2.2 via 1.1.1.1 dev default_interface"

Housten, the problem is fixed …

Thanks (for hints and inspi­ra­ti­on) to

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 13 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Seit gut zwei Jah­ren habe (nicht nur) ich gro­ße Schwie­rig­kei­ten bei der Benut­zung des WLAN/VPN der Fach­hoch­schu­le Pots­dam unter Linux (Kub­un­tu & Ubuntu).

Zuerst lag es dar­an, dass die Instal­la­ti­on des – seit eini­gen Jah­ren nicht mehr offi­zi­ell von Cis­co Sys­tems (weiter-)entwickelten – VPN-Cli­ents recht pro­ble­ma­tisch war. Dies scheint glück­li­cher­wei­se nun seit gerau­mer Zeit (auch für Nicht-Geeks) gelöst zu sein. Wie im Wiki des Stu­Ra FB5 doku­men­tiert, pfle­ge ich z.Z. ein git repo­si­to­ry in das ich (für neue Ker­nel­ver­sio­nen) not­wen­di­ge Ände­run­gen für den (groß­ar­ti­gen!) VPN-Cli­ent von tuxx-home.at ein­pfle­ge. Somit habe ich pers. immer einen lau­fen­den vpn­cli­ent und kann die­sen auch noch ande­ren Usern zur Ver­fü­gung stellen.

Im letz­ten Semes­ter nah­men die Pro­ble­me jedoch (sub­jek­tiv) zu. – Stän­dig brach die VPN-Ver­bin­dung zusam­men und dann kam es teil­wei­se zur Nicht­er­reich­bar­keit des VPN-Ser­vers. Der Clou jedoch bestand dar­in, dass nach drei Recon­nects der VPN-Zugang mit mei­nen Log­in­da­ten für eine gerau­me Zeit (ca. 20 Minu­ten) über­haupt nicht mehr mög­lich war…
Letz­te Woche war ich dann wie­der­mal kurz vor dem Ver­zwei­feln, weil selbst an Posi­tio­nen, die bis­her recht sta­bi­le VPN-Ver­bin­dun­gen zulie­ßen, obi­ge Pro­ble­me auf­tra­ten. Nach etwas Recher­che muss­te ich dann jedoch fest­stel­len, dass wohl gar nicht der VPN-Cli­ent schul­dig ist/war, son­dern der Net­work­Ma­na­ger (unter Ubuntu).

In (fast) minüt­li­chen Abstän­den fand ich fol­gen­de Mel­dung in den System-Logdateien:
Feb 25 16:16:47 axolotl NetworkManager[749]: (wlan0): roamed from BSSID 00:16:9D:56:A3:E0 (FH-Potsdam) to (none) ((none))
Feb 25 16:16:59 axolotl NetworkManager[749]: (wlan0): roamed from BSSID (none) ((none)) to 00:16:9D:44:84:90 (FH-Potsdam)

Somit war also nicht die VPN-Ver­bin­dung durch Pro­ble­me in dem vpn­cli­ent wacke­lig, son­der die VPN-Ver­bin­dung brach stän­dig zusam­men, weil die WLAN-Ver­bin­dung immer wie­der neu (und manch­mal auch mit einem neuen/weiteren Acces­s­Point) her­ge­stellt wurde.

Grün­de:
Für obi­ge Insta­bi­li­tät habe ich einen (offi­zi­el­len Ubun­tu) Feh­ler­be­richt gefun­den → https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/291760. Aller­dings fin­det sich in den 123 Kom­men­ta­ren lei­der kei­ne ein­deu­ti­ge Begrün­dung und auch kei­ne Lösung.

Lösungs­ver­such:

  1. Deak­ti­vie­ren der “Auto con­nect” Funk­ti­on für die WLAN-Ver­bin­dung mit derm Netz­werk “FH-Pots­dam”. – Damit muss man zwar manu­ell dafür sor­gen, dass die WLAN-Ver­bin­dung auf­ge­baut wird, aller­dings kann es auch ver­hin­dern, dass oben beschrie­be­nes Roa­ming (Wech­seln des AP) nicht auto­ma­tisch pas­siert, wenn ein wei­te­rer AP in Reich­wei­te ist.
  2. Instal­la­ti­on der tages­ak­tu­el­len Ver­si­on des Net­work­Ma­na­ger mit­tels des Launch­pad-PPA. – In die­se Ver­si­on flie­ßen bspw. (auch) Ver­än­de­run­gen ein, die durch Feh­ler­be­rich­te (wie oben) erkannt und beho­ben wurden.
  3. Als Alter­na­ti­ve zum Net­work­Ma­na­ger kann auch das Pro­gramm WICD die­nen. – Mit die­sem war es ande­ren Per­so­nen, die ähn­li­che Pro­ble­me hat­ten, mög­lich, eine stabile(re) WLAN-Ver­bin­dung herzustellen.

Ich habe mich für Schritt 1 und 2 ent­schie­den und wer­de die­se Woche mal aus­pro­bie­ren, ob es etwas gehol­fen hat.

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Auf Grund der Tat­sa­che, dass an der FH Pots­dam für das VPN – ohne die­ses funk­tio­niert der Zugang ins Inter­net (lei­der) nicht – Hard­ware der Fir­ma Cis­co Sys­tems benutzt wird und die Verbindung/Verschlüsselung (IPsec) nur über TCP funk­tio­niert, sind die Nut­ze­rIn­nen auf die Ver­wen­dung des “Cis­co Sys­tems VPN Cli­ent” ange­wie­sen. (Der “Anny­Con­nect” von Cis­co kann kein IPsec und alle alter­na­ti­ven Cli­ents kön­nen kein IPsec über TCP, son­dern ’nur’ über UDP… *damn*)

Tja und den “Cis­co Sys­tems VPN Cli­ent” gibt es lei­der nicht für 64-biti­ge Betriebs­sys­te­me (BS). – ‘Nicht­ein­mal’ für Win­doofs 7!
Und so bekommt man dann bei unse­rer DV-Abtei­lung bei­spiels­wei­se die freund­li­che Aus­kunft, dass man sich doch ein unter­stütz­tes BS besor­gen und parallel/alternativ instal­lie­ren ’soll’. *tzzz*

Aber heu­te habe ich beim Stö­bern fol­gen­de Aus­sa­ge eines Cis­co-Ange­stell­ten in den Cis­co-Foren gefunden:

The VPN Cli­ent is sup­port­ed on 32-bit sys­tems. A 64-bit IPSec VPN cleint is also being work­ed on for some­time this year.

Any­Con­nect SSL VPN has aways sup­port­ed 32-bit and 64-bit sys­tems. The next gene­ra­ti­on ver­si­on of the Any­Con­nect being work­ed on will also include IPsec com­po­nent (using IKE-V2).

Somit steigt die Span­nung bzgl. der Zeit­an­ga­be “some­time”, der Wei­ter­ent­wick­lung von “Anny­Con­nect” und deren Ein­flüs­se auf den Linux-Cli­ent (der offi­zi­ell kei­nen ‘aktu­el­le­ren’ Ker­nel, als einen 2.4.18 unterstützt).

Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Glück­li­cher­wei­se gibt es auf tuxx-home.at immer­noch eine Ver­si­on des Cis­co VPN Cli­ents, die halb­wegs aktu­ell ist und mit Ker­neln der Ver­si­on 2.6.x funk­tio­niert. Glück­li­cher­wei­se des­halb, weil es (näm­lich) nicht allen VPN-Benut­zern mög­lich ist auf vpnc umzu­stei­gen – bspw. denen, deren VPN-Gegen­stel­le den VPN-Zugang mit­tels IPSec over TCP betreibt.
Da das Pro­jekt aller­dings eine one-man-show ist und die Kom­mu­ni­ka­ti­on der com­mu­ni­ty nur über ein regis­trie­rungs­pflich­ti­ges Forum läuft, habe ich die aktu­ells­te Ver­si­on (4.8.02.0030) mal auf git­hub gepackt: http://github.com/sokai/vpnclient.

Außer­dem gibt es dort unter http://github.com/sokai/vpnclient/tree/2.6.31 einen branch, in den die aktu­el­len Patches für den Ker­nel 2.6.31 (zu fin­den im oben erwähn­ten Forum) ein­ge­spielt wurden.

Ich wer­de ver­su­chen das git-Repo aktu­ell zu hal­ten. Dies wird mir sicher auch eine Wei­le gelin­gen, da ich den vpn­cli­ent für das Netz der FH Pots­dam benötige.
Wer also Lust und Lau­ne hat, kann sei­ne Ver­i­on von obi­gen URLs run­ter­la­den oder einen Fork des Projekts/Branche auf git­hub machen und sei­ne Änderungen/Verbesserungen machen. Ich bin dann gern bereit die­se unter Kub­un­tu zu tes­ten und ggf. in den Mas­ter ein­flie­ßen zu lassen.

sofar|sogood|sokai

zur Ver­fü­gung gestell­te Pro­gramm vpn­cli­ent krankt momen­tan etwas dar­an, dass die