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!