DAEMON_OPTS="-p 0.0.0.0:443 --ssl 127.0.0.1:8443 --ssh 127.0.0.1:22 --user nobody"
Abhängig von der Art der Verbindung werden Verbindungen zu Port 443 entweder an den lokalen Port weitergeleitet:
- 8433 im Fall von https (nginx läuft auf diesem Port)
- 22 bei ssh
Aber als ich versuchte, eine SSH-Verbindung zum Server herzustellen, schlug ich erneut fehl. Anscheinend wurde die Filterung nicht nur durch Ports durchgeführt, sondern es wurde auch eine eingehende Paketuntersuchung durchgeführt. Dies macht die Aufgabe schwieriger. SSH-Verkehr muss in https eingeschlossen sein. Glücklicherweise ist dies dank des Websocat- Projekts nicht schwierig . Auf der Projektseite finden Sie viele vorgefertigte Binärdateien. Wenn Sie aus irgendeinem Grund die Binärdatei selbst aus dem Quellcode kompilieren möchten, ist dies ebenfalls nicht sehr schwierig. Ich mache das mit dem Packer von Hashicorp mit der folgenden Konfiguration:
{
"min_packer_version": "1.6.5",
"builders": [
{
"type": "docker",
"image": "ubuntu:20.04",
"privileged": true,
"discard": true,
"volumes": {
"{{pwd}}": "/output"
}
}
],
"provisioners": [
{
"type": "shell",
"skip_clean": true,
"environment_vars": [
"DEBIAN_FRONTEND=noninteractive"
],
"inline": [
"apt-get update && apt-get install -y git curl gcc libssl-dev pkg-config gcc-arm-linux-gnueabihf",
"curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs >/tmp/rustup.sh && chmod +x /tmp/rustup.sh && /tmp/rustup.sh -y",
"git clone https://github.com/vi/websocat.git && cd websocat/",
". $HOME/.cargo/env && cargo build --release --features=ssl",
"printf '[target.armv7-unknown-linux-gnueabihf]\nlinker = \"arm-linux-gnueabihf-gcc\"\n' >$HOME/.cargo/config",
"rustup target add armv7-unknown-linux-gnueabihf",
"cargo build --target=armv7-unknown-linux-gnueabihf --release",
"strip target/release/websocat",
"tar czf /output/websocat.tgz target/armv7-unknown-linux-gnueabihf/release/websocat target/release/websocat",
"chown --reference=/output /output/websocat.tgz"
]
}
]
}
Die Client-Seite ist auf Ubuntu 20.04, der Server läuft auf NVIDIA Tegra Jetson TK1, also mache ich dafür eine Cross-Assembly für die Armv7-Plattform. Bitte beachten Sie, dass die Servererstellung ohne SSL-Unterstützung erfolgt, da die SSL-Beendigung von nginx durchgeführt wird, das eingehende Verbindungen verarbeitet. Die Nginx-Konfiguration sieht folgendermaßen aus:
http {
server {
listen 0.0.0.0:8443 ssl;
server_name your.host.com;
ssl_certificate /etc/letsencrypt/live/your.host.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your.host.com/privkey.pem;
location /wstunnel/ {
proxy_pass http://127.0.0.1:8022;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
}
}
Ich starte Websocat von der Krone meines Benutzers aus:
* * * * * netstat -lnt|grep -q :8022 || $HOME/bin/websocat -E --binary ws-l:127.0.0.1:8022 tcp:127.0.0.1:22|logger -t websocat &
Jetzt können Sie wie folgt eine Verbindung zu Ihrem Server herstellen:
ssh -o ProxyCommand='websocat --binary wss://your.host.com/wstunnel/' your.host.com
Um wie viel reduziert das Umschließen in https die Bandbreite? Um dies zu überprüfen, habe ich den folgenden Befehl verwendet:
ssh -o ProxyCommand='websocat --binary wss://your.host.com/wstunnel/' your.host.com 'dd if=/dev/zero count=32768 bs=8192' >/dev/null
In meinen Experimenten wurde die Bandbreite um das Zweifache reduziert. Bei Verwendung des Protokolls ws: //, d.h. http, die Verbindungsbandbreite ist identisch mit nicht umschlossenem ssh.
So können Sie eine Sshuttle-Sitzung einrichten:
sshuttle -e 'ssh -o ProxyCommand="websocat --binary wss://your.host.com/wstunnel/"' -r your.host.com 0/0 -x $(dig +short your.host.com)/32
Beim nächsten Besuch beim Autoservice habe ich dafür gesorgt, dass alles so funktioniert, wie es sollte. Als netter Bonus ist die Anzahl der Versuche, sich über ssh von den linken Adressen aus beim Server anzumelden, stark gesunken.