Netzwerk Tipps

Tipps und Tricks zum Netzwerk

Netzwerk in Datei interfaces einstellen

Auf Debian / Ubuntu basierten Linuxsystemen wird traditionell eine feste IP in der Datei /etc/network/interfaces eingestellt:

allow-hotplug eth0
iface eth0 inet static
  address 192.168.178.19
  netmask 255.255.255.0
  gateway 192.168.178.1
  dns-nameservers 192.168.178.1
  network 192.168.178.0
  broadcast 192.168.178.255

Hinweis: Für das Setzen des dns-nameservers ist das Paket resolvconf notwendig.

Soll nach dem Starten oder Stoppen eines Interfaces noch was automatisch ausgeführt werden, dann kann man so etwas noch dazu bauen:

  up /sbin/ip route add 192.168.2.0/24 dev eth0

  down /sbin/ip route delete 192.168.2.0/24 dev eth0


Eine dynamische IP (DHCP) in Datei /etc/network/interfaces wird so eingestellt

allow-hotplug eth1

  iface eth1 inet dhcp


Und eine statische IP bei IPv6 geht so:

allow-hotplug eth1
iface eth1 inet6 static
  address 2001:xxxx:xxxx:x::1
  netmask 64
  up /sbin/ip route add 2001:xxxx:xxxx:x::/64 dev eth1


Bei Redhat basierten Linuxsystemen wird im klassischen Modus das Netzwerk über Dateien für jedes Interface in /etc/sysconfig/network-scripts/ifcfg-eth0 z.B. Bei neueren Systemen, die auf dem Networkmanager (NM) aufbauen, werden die Konfigurationsdateien in /etc/NetworkManager/system-connections/ vom NM abgelegt. Am besten konfiguriert man diese entweder über die grafische Oberfläche (nm-connection-editor) oder man installiert die Zusatztools für den NM mit:

dnf install NetworkManager-tui

Über die Console kann man den NM konfigurieren mit nmcli (scriptfähig) oder über nmtui.


Beispiel mit VLAN und Bridge für einen Router

Will man einen Rechner als Router einsetzen, gibt es vielzählige Variationen. Hier mal ein Beispiel mit einem VLAN 178 und einem Bridge-Interface, zwischen denen der Router dann vermittelt:

auto lo

  iface lo inet loopback


allow-hotplug eth1
  iface eth1 inet dhcp


auto eth1.178
  iface eth1.178 inet static
  vlan-raw-device eth1


auto eth0


auto br0
  iface br0 inet static
  address 192.168.178.19
  netmask 255.255.255.0
  bridge_ports eth0 eth1.178


# für eine weitere IP auf der Brücke
auto br0:1
  iface br0:1 inet static
  address 192.168.178.1
  netmask 255.255.255.0

# für IPV6
  iface br0 inet6 static
  address 2001:4dd0:fd74:1::1
  netmask 64
  up /sbin/ip route add 2001:4dd0:fd74:1::/64 dev br0

Zugegeben, das Beispiel ist etwas abstrackt, aber es soll zeigen, was man machen kann. Hier wird im eigentlichen Sinn nicht "geroutet" sondern "gebridged".


WLAN aktivieren via /etc/network/interfaces

Um die WLAN Schnittstelle automatisch nach dem Booten zur starten, muss folgendes in die Interfaces Datei (bei Ubuntu/Debian/und ähnliche Linuxe) geschrieben werden:

auto wlan0
  iface wlan0 inet dhcp

  wpa-conf /etc/network/wlan.conf

Laut einem Forumseintrag soll das auch gehen:

auto wlan0 

  iface wlan0 inet dhcp

  wpa-driver wext

  wpa-ssid MeineSSID

  wpa-ap-scan 1

  wpa-proto RSN

  wpa-pairwise CCMP

  wpa-group CCMP

  wpa-key-mgmt WPA-PSK

  wpa-psk "swordfish"

oder bei fester IP

auto wlan0

  iface wlan0 inet static

  address 192.168.177.200

  network 192.168.177.0

  netmask 255.255.255.0

  wpa-conf /etc/network/wlan.conf

In der angegebene wlan.conf Datei ist dann das WLAN definiert

network={

  ssid="wlan"

  proto=RSN

  key_mgmt=WPA-PSK

  pairwise=CCMP TKIP

  group=CCMP TKIP

  psk="geheim"

}


ETH-zu-WLAN-Router

Mal angenommen man sitzt so bei einem (LUG-)Treffen und alle surfen über WLAN. Alle bis auf einen, bei dem kein WLAN vorhanden ist. Damit dieser aber nicht im Dunkeln bleibt, verbindet man ihn per Crossover-Netzwerkkabel mit einem der anderen WLAN-Rechner und funktioniert diesen zum Router um. Im Bild könnte das so aussehen:

+---------------+ W     +-----------+         +-------------+

|  DSL Router   |  \    | Rechner 1 |  Cross  |  Rechner 2  |

|IP: 192.168.1.1|___L___|192.168.1.2|__Over___|             |

+---------------+    A  |192.168.9.1|  Kabel  | 192.168.9.2 |

                      N +-----------+         +-------------+

Nun muss beim WLAN-Rechner das Netzwerk und die IP-Tables Firewall konfiguriert werden und beim Rechner 2 das Netzwerk entsprechend. (Wir gehen hier von einer bereits funktionierenden WLAN Verbindung auf dem 1. Rechner aus.)

Auf dem WLAN-Rechner (Rechner 1)

Kabel Netzwerkkarte einstellen und aktivieren: (Für die Konsole)

ifconfig eth0 192.168.9.1 netmask 255.255.255.0 up

Nutzt man ein aktuelles Linux mit Networkmanager, dann legt man sich ein passendes Profil mit aussagekräftigem Namen an (z.B. lokal-192.168-9), dieses hat nur eine IP auf dem LAN-Interface mit passender Netzmaske, aber kein Gateway(!) und keinen DNS Eintrag(!). Man aktiviert dies dann auf der Konsole mit:

nmcli connection lokal-192-168-9 up

IP-Paket-Weiterleitung aktivieren und in der lokalen Firewall Maskieren einschalten:

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -I POSTROUTING -j MASQUERADE

Die IP-Pakete von Rechner 2 werden nun maskiert, damit der DSL Router die IP von Rechner 2 nicht sieht. Er behandelt alle Paket, als kämen sie von Rechner 1 und dieser wiederum merkt sich aber, welche von Rechner 2 kamen und leitet die Antworten an diesen weiter.

Eventuell muss man noch die Firewall im WLAN Rechner konfigurieren bzw. IP-Pakete von unserem Rechner 2 erlauben:

iptables -I FORWARD -s 192.168.9.0/24 -j ACCEPT

iptables -I FORWARD -d 192.168.9.0/24 -j ACCEPT


Auf Rechner 2:

Netzwerkkarte einstellen und aktivieren per Konsole oder Networkmanager:

ifconfig eth0 192.168.9.2 netmask 255.255.255.0 up

Dieser hier bekommt eine Defaultroute über WLAN Rechner 1.

route add default gw 192.168.9.1

Namensauflösung macht der DSL-Router, darum DNS Server im Rechner 2 auf DSL Router einstellen, entweder direkt in resolv.conf oder wieder über den Networkmanager:

echo "nameserver 192.168.1.1" > /etc/resolv.conf

Zusatztipp: Anstelle des Crossover Kabels kann man auch einen kleinen Switch einsetzen, über den dann mehrere Rechner über den einen mit WLAN surfen können. Jeder muss dann nur seine eigene IP-Adresse haben.

                                        +------+   +-----------+

+---------------+ W     +-----------+   |      |   | Rechner 2 |

|  DSL Router   |  \    | Rechner 1 |   |      |___|192.168.9.2|

|IP: 192.168.1.1|___L___|192.168.1.2|___|Switch|   +-----------+

+---------------+    A  |192.168.9.1|   |      |     +-----------+

                      N +-----------+   |      |     | Rechner 3 |

                                        |      |_____|192.168.9.3|

                                        +------+     +-----------+


WLAN Kanäle und Frequenzen

Beim LUG Treffen hatten wir u.a. auch mal kurz das Thema „Doppelbelegung durch benachbarte WLAN Access Points (kurz: AP)“. Hier eine kurze Zusammenfassung von mir:

Für das klassische WLAN gibt es 13 verschiedene Kanäle auf denen die verschiedenen WLAN Geräte senden können. Nebenbei sind davon in den USA nur 11, dafür in Japan sogar noch einer mehr, also 14 Kanäle erlaubt. Die 13 bei uns erlaubten Kanäle teilen sich den Frequenzbereich 2,4 GHz bis 2,4835 GHz und überlappen sich dabei. Das heisst ein AP auf Kanal 1 teilt sich Frequenzanteile mit den Kanälen 2-4 und stößt direkt an Kanal 5 an. Richtig störungsfrei wäre demnach ein Betrieb dreier benachbarter AP auf den Kanalkombinationen 1+6+11, 2+7+12, oder 3+8+13 möglich. In der Wikipedia findet sich auch eine Grafik dazu (siehe unten).

Leider kann man nie ausschließen, das morgen ein Nachbar sich einen WLAN Router zulegt und munter anfängt auf der gleichen Frequenz zu senden. Das macht auch erst einmal nichts, wenn alle Teilnehmer immer nahe beim eignen AP sind. Will man aber zum Beispiel im Garten surfen und sitzt in der Mitte der beiden AP, kann das schon problematisch werden. Dann hilft nur scannen und ausweichen, weil dem Nachbarn erklärst du das mal nicht so einfach.

Einfaches Scannen unter Linux geht auf der Konsole als root mit: „iwlist [interface] scanning“. Das Interface zeigt z.B. der Befehl „iwconfig“ an.

Quellen:


WLAN auf Konsole auflisten

Folgender Befehl zeigt alle gefundenen Netze im Detail an. wlan0 ist hier der Name des Wlan-Adapters und kann auch anders lauten.

iwlist wlan0 scanning

Folgendes Script kann man sich speichern, um eine kleinere und übersichtliche kurze Liste der gefundenen Netze zu erhalten:

#!/bin/bash

iwlist wlan0 scanning|grep -i -e frequen -e essid -e signal | tr '\n' ' ' | sed 's/Freq/\nFreq/g; s/   / /g'|sort

echo ""

Das echo am Ende dient nur der Schönheit und kann auch weggelassen werden.

WLAN Belastung erzeugen mit Ping:

nice --20 ionice -c2 -n0 ping -q -s 484 -l 3 -p 0f1e2d3c4b5a6978 -f 192.168.179.193


Serielle Schnittstelle tunneln mit socat

Die bracht man wenn ein Linux PC ohne serielle Schnittstelle über Netzwerk via einem weiteren Linux PC oder via einem RS232 Netzwerk-Modul wie z.B. Lantronix oder DigiWEB mit RS232 verwenden will.

socat PTY,link=/dev/ttyS4,raw,echo=0,wait-slave TCP4:192.168.178.32:10001

via SSH auf die serielle Schnittstelle des Linux PCs, ohne root Rechte, da das Device im Homedir des Users liegt.

socat  PTY,link=$HOME/vmodem0,raw,echo=0,wait-slave   EXEC:'"ssh   modem‐server.us.org socat - /dev/ttyS0,nonblock,raw,echo=0"'

via SSH Tunnel von einem Linux PC auf ein DigiWEB

socat PTY,link=/dev/ttyS4,raw,echo=0,wait-slave EXEC:'"ssh 192.168.178.21 -p 22 socat - TCP4:192.168.178.32:10001"'

zusätzlich kann man das ganze auch in eine Schleife einhüllen, damit bei einem Verbindungsabbau diese wieder automatisch geöffnet wird.

while true;

 do socat PTY,link=/dev/ttyS4,raw,echo=0,wait-slave

 EXEC:'"ssh 192.168.178.21 -p 22 socat - TCP4:192.168.178.32:10001"';

 sleep 1;

 done;

(Hinweis: Die fünf Zeilen hier oben sind hintereinander in eine Zeile zu kopieren. Die Zeilenumbrüche dienen lediglich der Lesbarkeit.)


IPs im Netzwerk scannen

Es gibt einen (bei manchen Menschen verpönten) Netzwerkscanner namens nmap, mit dem man unter anderem das Netzwerk durchpingen kann mit nmap -sP 192.168.1.1-254 z.B. Hat man dieses Tool nicht, geht es mit der folgenden Schleife auch mit dem ping Kommando. Die einfache Schleife gibt die Endziffern aus, derer IPs die erreichbar sind:

for i in `seq 110 199`; \

   do ping -c 1 192.168.6.$i > /dev/null; \

   if [ $? == 0 ]; then echo $i; fi; done;

Hier ein anderes Beispiel das bei nicht-erreichbar einen Punkt ausgibt und bei den erreichbaren die Endziffer:

for i in `seq 40 60`; do ping -c 1 192.168.1.$i > /dev/null; if [ $? == 0 ]; then echo -n " $i "; else echo -n "."; fi; done; echo " "

. 41 . 43  44  45  46 .... 51  52 . 54  55 .....


Mit Fritzbox Internet Traffic mitschneiden

Unter der folgenden URL kann mit der Fritzbox der Internet Traffic mitgeschnitten werden.

http://fritz.box/html/capture.html (ältere Modelle)
http://fritz.box/#cap (neuere Modelle)

Die mitgeschnittene Datei *.eth kann dann mit dem Programm Wireshark geöffnet werden.


X11 XDMCP

Will man die Login Oberfläche eines Linux Rechners remote via Netzwerk erreichen so ist das via XDMCP möglich. Hierzu muss im Display Manager das Hostrechners das XDMCP aktiviert werden. Je nachdem kann das gdm, lightdm oder gdm3, usw. sein. Meist gibt es da einen Eintrag im /etc/xxx/yyy.conf File.

[XDMCP]

Enable=true

kann aber auch so sein,

[XDMCPServer]

Enable=true

Ist das aktiviert und der Display Manager neu gestartet, kann man z.B. mit dem Befehl:

sudo Xorg -terminate -query 192.168.0.251 :1

einen weiteren X-Server auf seinem PC starten und das login des Remote PC anzeigen. Die Server werden dabei durch „strg+alt+F7“ und „strg+alt+F8“ bzw.„strg+alt+F9“ umgeschaltet.

Soll der Remote Login im einem Fenster des eigenen Desktop angezeigt werden, kann man dies auch durch den Befehl:

Xephyr -query 192.168.0.252 :1

machen. Dann öffnet sich der Login Desktop in einem Fenster auf dem Remote PC.

Hinweis: Xephyr wird vermutlich mit dem Paket „xserver-xephyr“ installiert.

Achtung: Wenn eine Firewall im remote PC aktiv ist dann geht das vermutlich nicht, also Firewall für die Host IP off schalten.


TCPDUMP via Netzwerk *!

ACHTUNG noch nicht ganz richtig

ssh root@test.des tcpdump -U -s0 -w - 'not port 22' | wireshark -k -i -

Netzwerkbasierte Anwendungen

HTTPs auf Apache2 aktivieren

Aktivieren der Apache Module und Seiten:

a2enmod ssl

a2ensite default-ssl

In Datei /etc/apache2/sites-enabled/default-ssl den Servernahme z.B. „ServerName url.de“ eingeben. Diesen dann auch unbedingt für das Zertifikat verwenden. In der selben default-ssl Daten das folgende Beispiel auskommentieren

# SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem

# SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

und das einbauen:

SSLCertificateKeyFile /etc/apache2/mycert/server.key

SSLCertificateFile /etc/apache2/mycert/server.crt

Zertifikat erstellen z.B. in:

mkdir /etc/apache2/mycert

cd /etc/apache2/mycert

openssl genrsa -out server.key 2048

openssl req -new -key server.key -out server.csr

openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

Zum Schluss noch: „service apache2 restart“, dann sollte https gehen.

Info: Zur Installation der owncloud muß in der default-ssl „AllowOverride All“ eingestellt werden.


OwnCloud Update *!

Nach einem Update der OwnCloud durch 'apt-get upgrade' wird die owncloud in den Maintenance-mode geschaltet.

Um das Upgrade vollständig durchzuführen (z.B. die mySQL Datenbank) muss dann folgendes gemacht werden.

1. Sicherheitshalber backup der mySQL Datenbank (Beschreibung folgt noch)
2. Wechseln in folgenden OwnCloud Ordner
3. Als root den Upgrade starten
4. OwnCloud wieder starten

cd /var/www/owncloud

sudo -u www-data ./occ upgrade

sudo -u www-data ./occ maintenance:mode --off

Hinweis:

Da die OwnCloud beim Upgrade immer die 3rd-party Module ausschaltet müssen diese wieder aktiviert werden. Hierzu beim Upgrade z.B. auf folgende Ausgaben achten:

...

Disabled 3rd-party app: calendar

Disabled 3rd-party app: contacts

Disabled 3rd-party app: documents 

...


OwnCloud client

Der OwnCloud Client wird am besten über ein Repository installiert. Dazu die folgende Datei anlegen:

/etc/apt/sources.list.d/owncloud-client.list

mit diesem Inhalt:

deb http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_8.0/ /

dann noch den gpg Key runterladen und den Key hinzufügen:

wget http://download.opensuse.org/repositories/isv:/ownCloud:/desktop/Debian_8.0/Release.key -O /tmp/Release.key

apt-key add /tmp/Release.key

Tipps zu iptables Firewall

Service blocken ohne Passwort

Hat man einen Service auf einem Linux Rechner der nicht mit User und Passwort geschützt werden kann, dann hilft einem iptables.

/sbin/iptables -A INPUT -p tcp --destination-port 2000 -m mac \

                        --mac-source 00:0F:EA:91:04:07 -j ACCEPT

/sbin/iptables -A INPUT -p tcp --destination-port 2000 -j DROP

Hier wird eine Verbindung auf Port 2000 nur angenommen, wenn die MAC Adresse stimme, alle anderen Verbindungen auf den Port 2000 von anderen Rechnern bzw. MAC`s werden blockiert.


Internes Port forwarding

Will man einen Service starten der keine Rootrechte hat, kann man diesen nicht auf den ersten 1024 Ports laufen lassen. Dies kann man mit einem internen Port forwarding via iptables umgehen.

/sbin/iptables -A PREROUTING -t nat -i eth0 -p tcp \

               --dport 80 -j REDIRECT --to-port 8080


*! Muss noch nachbearbeitet werden *!

Tipps zu SSH und Co.


SSH Tunnel

Beispiel 1: Will man aus der Ferne z.B. einen Router zuhause konfigurieren, der aber nur lokalen Zugriff erlaubt, kann man dies mit Hilfe von SSH recht einfach bewerkstelligen. Hierzu benötigt der Linuxuser zuhause einen Linuxrechner mit installiertem OpenSSH und einen dynamischen DNS-Provider wie dyn-dns oder no-ip (z.B.).

Mit dem folgenden Befehl kann der Tunnel angelegt werden:

$ ssh -C -L 12345:192.168.0.1:80 user@meinhost.dyndns.org

Nun kann man auf dem lokalen Rechner den Webbrowser starten und gibt als URL den Tunneleingang an:

http://localhost:12345/

und schon wird über den Tunnel die Seite unseres Routers geladen.

+---------------+         +-----------+        +-------------+

|1. $ ssh ...   |__Inter__|DSL-Router |__Heim-_|  SSH-Server |

|2. http://...  |  -net   |192.168.0.1|  netz  |192.168.0.xxx|

+---------------+         +-----------+        +-------------+


Beispiel 2 ermöglicht jetzt anders herum einem Remotepartner auf einen Telnet Server im lokalen Netz zuzugreifen. Das kann z.B. eine Receiverbox sein, die eben nur FTP oder Telnet anbietet, aber kein SSH um selbst als Tunnelserver wie in Beispiel 1 zu dienen.

$ ssh -C -R 2300:192.168.0.42:23 user@seinhost.dyndns.org

Jetzt kann der Benutzer auf der Remoteseite bei seinhost.dyndns.org den Tunnel benutzen mit

$ telnet 127.0.0.1 2300

+---------------+        +-----------+        +-------------------+

|Lokaler Rechner|  Heim- |DSL-Router |  In-   |  Remote - Partner |

|$ ssh -C -R ...|__netz__|           |__ter-__|   mit SSH-Server  |

|192.168.0.2    |    |   |192.168.0.1|  net   |seinhost.dyndns.org|

+---------------+    |   +-----------+        +-------------------+

  +---------------+  |

  |   Receiver    |__+

  |192.168.0.42   |

  +---------------+

Versuche mit Weiterleitung von FTP Verbindungen hat leider noch nicht funktioniert. Wir arbeiten daran.


Beispiel 3 ermöglicht die Weiterleitung eines SMTP-Server

$ssh user@test.de -L192.168.178.4:2525:smtp.server.de:25


SSH Tunnel erweitern

Was nun, wenn man während eine Verbindung beseht, noch einen weiteren Port tunneln will? Dafür gibt es die Escape Character, um auf eine Art Hintergrundshell zu kommen. Beispiel:

[host-1]$ ssh -L 1380:10.11.12.13:80 userx@host-2

Enter Password for user userx:

[host-2]$

Jetzt sind wir auf host-2 eingeloggt und haben auf host-1 die Möglichkeit mit dem Browser auf http://127.0.0.1:1380/ zuzugreifen. Dies wird auf host-2 weiter geleitet auf 10.11.12.13, Port 80.

Durch drücken der Tastenkombination ~C (je nach Tastatur auch ~[SPACE]C) kommen wir auf den ssh-Prompt und können einen weiteren Tunnel hinzufügen:

[host-2]$ ~C  //(wird nicht angezeigt)//

ssh> help

Commands:

    -L[bind_address:]port:host:hostport    Request local forward

    -R[bind_address:]port:host:hostport    Request remote forward

    -D[bind_address:]port                  Request dynamic forward

    -KR[bind_address:]port                 Cancel remote forward

[ENTER]

[host-2]$ ~C

ssh> -L1480:10.11.12.14:80

Forwarding port.

[ENTER]

Ab jetzt haben wir einen zweiten Port weiter geleitet und greifen mit einem weiteren Browserfenster über http://127.0.0.1:1480/ auf 10.11.12.14, Port 80 zu.

Mit [ENTER] ~# kann man die aktiver Verbindungen anschauen.

[ENTER]

[host-2]$ ~#

The following connections are open:

#2 client-session (t4 r0 i0/0 o0/0 fd 6/7 cc -1)

#3 direct-tcpip: listening port 10000 for 192.168.178.1 port 80

[ENTER]


SSH Befehle bei aktiver Verbindung

Ist man per SSH verbunden können folgende Befehle durch Betätigen von '~' eingegeben werden:

  ~.      Disconnect.

  ~^Z     Background ssh.

  ~#      List forwarded connections.

  ~&      Background ssh at logout when waiting for forwarded connection

          or X11 sessions to terminate.

  ~?      Display a list of escape characters.

  ~B      Send a BREAK to the remote system (only useful if the peer sup‐

          ports it).

  ~C      Open command line.  Currently this allows the addition of port

          forwardings using the -L, -R and -D options (see above).  It

          also allows the cancellation of existing port-forwardings with

          -KL[bind_address:]port for local, -KR[bind_address:]port for

          remote and -KD[bind_address:]port for dynamic port-forwardings.

          !command allows the user to execute a local command if the

          PermitLocalCommand option is enabled in ssh_config(5).  Basic

          help is available, using the -h option.

  ~R      Request rekeying of the connection (only useful if the peer

          supports it).

  ~V      Decrease the verbosity (LogLevel) when errors are being written

          to stderr.

  ~v      Increase the verbosity (LogLevel) when errors are being written

          to stderr.


SSH-Tunnel im SSH-Tunnel

Man kann SSH auch in einem bestehenden Tunnel machen, wenn man z.B. einen Server (B) von extern erreichen will, der keinen direkten Internetzugang hat. Man baut dazu einen Tunnel zu einem Gateway auf und baut dann einen zweiten Tunnel darin auf. Beispielnetz:

+---------------+ Inter- +-------------+ Inter- +-------------+

|   Rechner A   |__net___| SSH-Gateway |__nes___|  Server B   |

|192.168.0.2    |        |gw.domain.xyz| Netz-  | 172.16.3.28 |

+---------------+        +-------------+  werk  +-------------+


Rechner A $ ssh -L 2200:172.16.3.28:22 gw-user@gw.domain.xyz

Enter Password for gw-user:

SSH-Gateway $


Rechner A $ ssh -p 2200 srv-user@127.0.0.1

Enter Password for srv-user:

Server B $

Das erste Fenster, mit dem Login auf dem Gateway, muss solange offen bleiben, wie man auf Server B arbeiten will. Wenn man fertig ist, schließt man die Verbindung zu Server B und dann die zum Gateway.

Wenn nun z.B. hinter Server B ein weiterer Rechner (C) ist, der eine Weboberfläche bietet, die aber nur von Server B aus aufrufbar ist, kann man dies im zweiten Tunnel oben einpacken. Dann ändert sich der Befehl wie folgt:

Rechner A $ ssh -p 2200 -L 8000:172.16.7.8:80 srv-user@127.0.0.1

Enter Password for srv-user:

Server B $

Jetzt kann man auf Rechner A auf http://127.0.0.1:8000/ im Browser aufrufen und bekommt über den getunnelten HTTP-tunnel im getunnelten SSH-Tunnel die Webseite von 172.16.7.8 angezeigt. Man kann auch aus dem Tipp zuvor den bestehenden Tunnel 2 erweitern mit der ~C Funktion (s.o.).


Socks Proxy via SSH

Will man über eine SSH Verbindung die Internetanbindung des entfernten Rechnes benutzen, kann man dazu einen Socks-Proxy verwenden, wenn z.B. das Routing nicht geht. Mit folgendem Befehl wird die SSH-Verbindung hergestellt.

ssh -D 10000 user@host

Anschließend muß im lokalen Browser unter Proxyeinstellungen den Socks-Proxy einstellen:

Host: localhost  Port: 10000

Jetzt kann man im Browser über die Internetverbindung des entfernten Host-Rechners surfen.


Socks Proxy via SSH für apt update wenn der Rechner kein Internet hat

Öffnen der Verbindung mit:

ssh -R 9000 user@host

Dann im Remote System das eingeben (ohne Zeilenumbruch):

apt -o Acquire::http::proxy="socks5h://localhost:9000" -o Acquire::https::proxy="socks5h://localhost:9000" update


Mit SSH nach Hause Telefonieren

Will man einen Rechner hinter einem Router erreichen ohne Portweiterleitung, so muß dieser Rechner bzw. Client aktiv eine SSH Verbindung zu einem SSH-Server aufnehmen um einen Tunnel aufzubauen, der dann rückwärts verwendet wird, um wiederum eine SSH Console auf dem Client zu öffnen.

Vorbereitung auf dem Server

Auf dem Server muss ein neuer User angelegt werden, der keine „root“ Rechte hat z.B.:

adduser tun

Bei diesem sollte man später zur Sicherheit in der /etc/passwd die Shell abschalten indem der Shelleintrag /bin/bash durch /bin/true ersetzt wird. Allerdings erst nach dem Kopieren des Keys.

Zusätzlich müssen in der Datei /etc/ssh/sshd_config die beiden folgenden Zeilen eingebaut werden.

ClientAliveInterval 20

ClientAliveCountMax 3

Dies ist notwendig, da bei einem IP-Wechsel am Client Rechner sonst die Verbindung nicht geschlossen wird und der Tunnelport nicht mehr geöffnet werden kann.

Vorbereitung auf dem Client

Auf dem Client Rechner verwenden wir autossh. Zuerst muss als root ein RSA Key angelegt werden. Root deswegen, da via rc.local das autossh als root ausgeführt wird und die id_ras.pub von root verwendet wird:

sudo -i    (oder 'su -' je nach Linux-System)

cd ~/.ssh

ssh-keygen -t rsa

Diesen nun auf den Server kopieren:

cat ~/.ssh/id_rsa.pub | ssh [-p <port>] tun@<server> \

 -c "cat - >> ~/.ssh/authorized_keys

Kopieren mit scp wäre ebenfalls möglich, aber dieser Befehl überschreibt grundsätzlich bereits vorhandene Dateien, was hier unerwünschte Effekte erzeugen kann. Sollen oder müssen mehrere Keys angelegt werden ist der Befehl „ssh-copy-id“ besser, mit welchem ebenfalls Keys an die Datei „.ssh/authorized_keys“ angehängt werden können:

ssh-copy-id tun@<server>

muß ein Port angegeben werden, so sieht das so aus:

ssh-copy-id "-p <port> tun@<server>"

Achtung: /etc/passwd Eintrag nicht vergessen !

Jetzt muss noch der folgende Befehl in die /etc/rc.local rein:

/usr/bin/autossh -f -N -R 2222:127.0.0.1:22       \

                   -oServerAliveInterval=20       \

                   -oServerAliveCountMax=3        \

                   -oStrictHostKeyChecking=no     \

                   -oUserKnownHostsFile=/dev/null \

                   -oExitOnForwardFailure=yes     \

                   -oCompression=yes              \

                   [-p <port>] tun@<server>

Hinweis: Wird der Server unter einem anderen Port betrieben, muss bei ssh der Parameter „-p <port>“ angegeben werden. ssh-copy-id verwendet ssh und hier muss wieder eine kleines p verwendet werden, jedoch sind hier Anführungsstriche nötig (siehe Beispiel oben).

Anwendung

Wenn alles richtig ist, wird man nach Neustart des Client oder Ausführen der Datei /etc/rc.local sofort zuhause auf dem Server angerufen und der SSH-Hilfs-Tunnel erzeugt.

Jetzt kann man auf seinem Server zuhause über diesen Hilfs-Tunnel mit:

ssh -C -p 2222 <user>@127.0.0.1

auf dem Client Rechner eine Shell öffnen. Weiterhin kann man mit den bekannten -L oder -R Parametern weitere Ports tunneln.

Variation 127.x.y.z

Will man den Hilfs-Tunnel auf einer anderen localhost IP laufen lassen z.B. 127.0.0.2, um z.B. mehrere solcher Clients immer auf Port 2222 zu tunneln, so muss in der sshd_config auf dem Server die folgende Zeile eingebaut werden:

GatewayPorts clientspecified

Anschließend wird auf dem Client autossh angepasst auf: „… -R 127.x.y.z:2222:127.0.0.1:22“ und autossh neu gestartet. z.B.:

/usr/bin/autossh -f -N -R 127.0.1.8:2222:localhost:22  \

(** Nachbearbeitung?)

Vorteil ist jetzt, das man in der Hosts Datei auf dem Server dem Tunnel einen Namen geben kann:

sudo -i

vi /etc/hosts

...

127.0.0.2  client-muenchen

127.0.0.3  client-hamburg

...

Danke an Klaus für den Tipp


X-Fenster über SSH öffnen

Eine einfache Möglichkeit X-Programme eines entfernten Rechners auf dem lokalen Rechner anzuzeigen, bietet eine Option von SSH:

ssh -X -C user@host

Das -C aktiviert einen zusätzliche Kompression der übertragenen Daten. Man kann es mal mit und ohne -C probieren, ob sich dies bemerkbar macht, oder nicht. Das hängt von der Bandbreite der Verbindung und der Leistungsfähigkeit der CPU ab, die ja den Traffic komprimieren muss.

Auf dem entfernten Rechner kann man nun ein beliebiges Programm öffnen und das Fenster dazu erscheint auf meinem lokalen Desktop:

firefox &


VPN - openvpn

Das ist ein Thema, das wir noch bearbeiten müssen!