Alte Konfigurationsmethode

Low-Level/Barebones/Step-by-step/The old Method

Low-Level technisch formuliert geht das so:

• Dann legt man das OpenVPN Device an:

  openvpn --mktun --dev tap0

Wenn tap0 schon belegt ist, nimmt man das nächste freie (tap1, 'tap2, ...). Im folgenden geh ich davon aus, daß tap0 verwendet wird. Voila, wir haben eine neues Netzwerk-Device namens tap0, daß man mit

  /sbin/ip addr /show

auch sehen kann.

• Dann muß man den OpenVPN Tunnel aufbauen:

  /usr/sbin/openvpn --dev tap0 --remote 78.41.115.16 --port port --daemon --writepid /var/run/openvpn-tap0.pid --cd /var/tmp

Dabei muß als Parameter für port der Port, den man oben mitgeteilt hat verwendet werden - der wird i.Ü. der Einfachheit auch lokal verwendet. Der OpenVPN Prozeß verzieht sich dabei in guter alter Unix-Manier für Deamons in den Hintergrund, schreibt seine Prozess-Id in das File /var/run/openvpn-tap0.pid (das man verwenden kann, um den Prozeß wieder zu terminieren) und sagt ihm, er soll ins Directory "/var/tmp" wechseln (dann blockiert er sonst nichts). Voila, wir haben einen Tunnel - der steht noch nicht, weil noch nichts drüber geschickt wurde.

• Unser tap0 Device braucht eine IP-Adresse - die gleiche wie eh wohl schon von eth1 (funkseitig) verwendet.

  /sbin/ip addr add ip broadcast + dev tap0

ip ist dabei eben die 0xFF IP-Adresse (inklusive Netzmaske - z.B. /22). Mit

  /sbin/ip addr show

kann man sich den Erfolg jetzt ansehen.

• Allerdings haben wir jetzt ein Problem (FIXME: auch auf nicht-Linuxens?). Wir haben vom Linux-Kernel eine Netzroute geschenkt bekommen, die wir nicht brauchen und wollen. Die entsorgen wir gleich wieder:

  /sbin/ip route del 193.238.156.0/22 dev tap0

Die Zeile kann man (u.U. bis aufs "tap0" Device) 1:1 kopieren, weil im Moment alle 0xFF-IP-Adressen aus dem gleichen Netz (193.238.156.0/22) sind.

• Und jetzt aktivieren wir das Interface:

  /sbin/ip link set tap0 up