sslh Umleitung auf 1194 möglich?

[dirk11]

Hi Leute,

auf meinem Heimserver lauscht auf Port 443 ein sslh. Der leitet dann Anfragen an ssh auf Port 22 weiter und Anfragen an den Webserver auf Port 443:

Code: Alles auswählen

DAEMON_OPTS="--user sslh --listen 0.0.0.0:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:442 --pidfile /var/run/sslh/sslh.pid"

Was muss ich dort hinzufügen, damit ich über diesen Port auch auf meinen VPN-Zugang zugreifen kann, welcher auf Port 1194 UDP lauscht?

Sinn der Sache: ich hatte jetzt mehrere Hostel, welche offensichtlich ihr WLAN mit Fritzen gebaut haben und aus der üblichen Unkenntnis heraus abgehend(!) alle Ports ausser 80 und 443 gesperrt haben. Dennoch würde ich halt gerne mal mein VPN nutzen.

[MSfree]

https://blog.buettner.xyz/sslh-ssl-ssh- ... -port-443/

[wanne]

Port UDP ist nicht TCP. Wenn dein sslh auf TCP hört wird er kein UDP abbekommen. Entweder du lässt dein OpenVPN TCP machen. (Und lebst mit den Geschwindigkeitseinbusen) oder du legst es schlicht auf Port 53/UDP. Der ist normalerweise überall offen.

[dirk11]

Aha, danke! Dann kann das auch nicht funktionieren, ich habe gerade parallel schon gesucht, wieso ich "connection refused (code=111)" als Fehler auf dem Client bekomme.

Mein Problem ist: ich brauche das sowieso nur für Mobiltelefone, und ich habe ja schon diverse Experimente mit openVPN gemacht. TCP ist trotz 10MBit uplink an meinem Anschluss (sprich dort, wo der Server steht) einfach viel zu langsam.

Auf Port 53 läuft normalerweise ein Domain Name Server. Gut, den biete ich sowieso nicht (mehr) an, sollte also kein Problem geben.

Dazu muss ich dann aber noch eine dritte openVPN-Instanz (neben 1194 UDP und 1195 TCP) laufen lassen, auf 53 UDP, richtig?

[wanne]

Dazu muss ich dann aber noch eine dritte openVPN-Instanz (neben 1194 UDP und 1195 TCP) laufen lassen, auf 53 UDP, richtig?

So würde ich es machen. Ist wahrscheinlich am wenigsten Stress. Du kannst auch per socat oder iptables die Pakete auf port 53 ankommen an Port 1194 weiterleiten.

[MSfree]

Dazu muss ich dann aber noch eine dritte openVPN-Instanz (neben 1194 UDP und 1195 TCP) laufen lassen, auf 53 UDP, richtig?

Die Frage ist halt, ob Port 53 überhaupt so clever ist. Der DNS deines Routers erwartet schließlich die Antworten der DNS-Abfragen auch auf UDP-Port 53. Wenn die DNS-Antworten und die VPN-Pakete beide auf Port 53 wollen, dürfte das letztlich nicht funktionieren.

[dirk11]

Du kannst auch per [...] iptables die Pakete auf port 53 ankommen an Port 1194 weiterleiten.

Das wäre in meinen Augen die smarteste Lösung. Wie würde dafür die Zeile lauten, kannst Du mir die netterweise sagen?

[dirk11]

Die Frage ist halt, ob Port 53 überhaupt so clever ist. Der DNS deines Routers erwartet schließlich die Antworten der DNS-Abfragen auch auf UDP-Port 53. Wenn die DNS-Antworten und die VPN-Pakete beide auf Port 53 wollen, dürfte das letztlich nicht funktionieren.

Ich wäre jetzt davon ausgegangen, daß der jeweils "falsche" Empfänger die entsprechenden falschen Pakete einfach verwirft/ignoriert. Wenn dem nicht so ist, wäre das in der Tat ein Problem, da Router!=openVPN-Server. Sprich ich muss sowieso auf dem Router eine Portweiterleitung einrichten, von 53(router) auf 53(Server). Wobei mir gerade auffällt, daß ich dann auch gleich von 53(router) auf 1194(server) weiterleiten könnte. Aber wenn das, wie Du vermutest, nicht geht, kann ich das sowieso vergessen.

[MSfree]

Ich wäre jetzt davon ausgegangen, daß der jeweils "falsche" Empfänger die entsprechenden falschen Pakete einfach verwirft/ignoriert.

Ja, der falsche Empfänger verwirft das Paket, aber danach ist es dann auch weg. Der richtige Empfänger hat dann keine Möglichkeit mehr, an das verworfene Paket zu gelangen.

Sprich ich muss sowieso auf dem Router eine Portweiterleitung einrichten, von 53(router) auf 53(Server). Wobei mir gerade auffällt, daß ich dann auch gleich von 53(router) auf 1194(server) weiterleiten könnte. Aber wenn das, wie Du vermutest, nicht geht, kann ich das sowieso vergessen.

Die Weiterleitung ginge natürlich. Nur kämen dann auch alle DNS-Antworten, die eigentlich der Router empfangen sollte auch auf Port 1194 desVPN-Servers an und der fängt damit natürlich nichts an.

Wenn man hinter so einer zugemauerten Firewall hängt, muß man wohl oder über auf TCP gehen, das dann auch von sshl entsprechen aufgeteilt werden kann. Die andere Alternative lautet, das eigene Smartphone zu nehmen, den Rechner damit zu tethern. Damit hat man einen Internetzugang, den kein anderer blockiert.

[wanne]

Wie würde dafür die Zeile lauten, kannst Du mir die netterweise sagen?

Wollte mich darum drücken. Deswegen habe ich gemeint, setz einfach einen neuen auf.
Ich glaube so müsste das aussehen:

Code: Alles auswählen

socat UDP6-LISTEN:53,fork UDP:[::1]:1195

Bzw so:

Code: Alles auswählen

socat UDP6-LISTEN:53,fork UDP:127.0.0.1:1195

Der DNS deines Routers erwartet schließlich die Antworten der DNS-Abfragen auch auf UDP-Port 53.

Aber hoffentlich nicht nach außen ans Internet.
Ich glaube bei sowas fliegt man mittlerweile auch aus dem Internet. Ob der Router das dann hinbekommt von Außen Pakete weiterzuleiten während er von innen Pakete annimmt, ist natürlich eine andere Frage. Ich würde mal auf ja tippen. Sicher bin ich mir da aber nicht. Deswegen habe ich einen OpenWRT-Router. Da gibt es solche Probleme nicht. Würde den DNS-Server auf dem Router eh abschalten mittlerweile bist du schneller wenn du einen performanten übers Internet nimmst als dein schwachbrüstiges Routerchen mit DNS zu überfordern.

[MSfree]

Würde den DNS-Server auf dem Router eh abschalten mittlerweile bist du schneller wenn du einen performanten übers Internet nimmst als dein schwachbrüstiges Routerchen mit DNS zu überfordern.

Als ob so das bißchen DNS einen Pastikrouter wirklich ernsthaft herausfordern würde.

OK, im Rechenzentrum würde ich DNS auch nicht von einer Fritzbox erledigen lassen wollen. Zuhause, bei 3-4 Rechnern im Netz langweilt sich der DNS auf dem Router sowieso die meiste Zeit.

[wanne]

Als ob so das bißchen DNS einen Pastikrouter wirklich ernsthaft herausfordern würde.

OK, im Rechenzentrum würde ich DNS auch nicht von einer Fritzbox erledigen lassen wollen. Zuhause, bei 3-4 Rechnern im Netz langweilt sich der DNS auf dem Router sowieso die meiste Zeit.

Für nen schnellen DNS-Server braucht es vor allem schnellen RAM (und nach Möglichkeit viel davon.). Und RAM ist da oder – wie bei der Fritzbox – eben nicht. Ob der jetzt Tausende oder 4 Nutzer bedient ist Wurst. Ganz im Gegenteil machen mehr Nutzer deinen DNS-Server deutlich schneller. Der bekommt Trends schneller mit und kann deswegen intelligenter Cachen. (Deswegen war ja auch schon immer das Credo, dass man den auf dem Router betreibt und nicht lokal.) Probiere es einfach aus. Guter Nameserver reagiert im einstelligen ms Bereich. Deine Fritz!Box eher so mit 40ms eher mehr für die erste Anfrage (und das ist die, die im Realbetrieb relevant ist).
Problem ist, dass die nicht Megabyte weise RAM fürs Caching übrig hat. Entsprechend schnell schmeißt sie ihre gespeicherten Ergebnisse weg. Bei den großen triffst du dagegen praktisch immer den Cache. Weil irgend jemand war garantiert schon mal vor dir auf der domain unterwegs.
Dazu kommt, dass deine Fritzbox genau aus dem Grund keine Itteration macht. Die fragt auch nur einen weiter nach. Entsprechen addieren sich die Latenzen. Nimmst du direkt den eins drüber hast du das Problem nicht.

[MSfree]

Für nen schnellen DNS-Server braucht es vor allem schnellen RAM (und nach Möglichkeit viel davon.). Und RAM ist da oder – wie bei der Fritzbox – eben nicht. Ob der jetzt Tausende oder 4 Nutzer bedient ist Wurst.

Das ist völlig übertrieben. Das typische Surfverhalten, das ich so beobachte liegt er so, daß die Leute ihre 10-20 Seiten haben, die sie regelmässig aufrufen. Dazu kommt noch der übliche Werbemüll, der nochmal um den Faktor 10 mehr Hostnamen bedingt, so daß am Ende pro User vielleicht 100-200 DNS-Einträge gecached werden müssen, wobei bei mehreren Usern sich die DNS-Anfragen auch überlappen. Bei 4 Nutzern wären das also um die 800 DNS-Einträge, die gecached werden müßten. Wieviel RAM braucht man dafür wohl? Ich würde sagen, daß bleibt unter 512kByte und wenn man das in einem KD-Tree organisiert, ist die Cacheabfrage in spätestens 10 Iterationen erledigt. Ein 33MHz 4-86 würde das in unter einer ms erledigen können.

Solange man nicht zig-Millionen DNS-Einträge cachen können will, reichen auch die paar MB RAM in einem Plastikrouter.

Deine Fritz!Box eher so mit 40ms eher mehr für die erste Anfrage (und das ist die, die im Realbetrieb relevant ist).

Ich habe ein DSL-Modem, das an einem Celeron N3450 mit 4GB RAM hängt und bind9 als DNS verwendet. Die Namensauflösung ist hier aber nicht wirklich schneller als auf einem ollen Xyxel-Router bei meinen Bekannten.

[novalix]

... oder du legst es schlicht auf Port 53/UDP. Der ist normalerweise überall offen.

Was ist schon normal?
Ich habe es schon häufiger erlebt, dass tatsächlich *alle* Ports außer 80 und 443 zugeklebt waren. DNS läuft dann eben ausschließlich über den internen Router.
In einem solchen Fall hast Du dann gar nichts von den Klimmzügen im Heimnetz.

[dirk11]

Ich glaube so müsste das aussehen:
Bzw so:

Ehm, mir wäre mehr an der passenden iptables-Zeile gelegen. Socat sagt mir so gar nichts.

Deswegen habe ich einen OpenWRT-Router. Da gibt es solche Probleme nicht.

Meiner ist ein openWRT-Router.

Würde den DNS-Server auf dem Router eh abschalten mittlerweile bist du schneller wenn du einen performanten übers Internet nimmst als dein schwachbrüstiges Routerchen mit DNS zu überfordern.

Bei mir läuft ja kein DNS-Server mehr. Der dnsmasq läuft nur noch für's Intranet, nach außen nutze ich die Nameserver vom Provider.

[dirk11]

Ich habe ein DSL-Modem, das an einem Celeron N3450 mit 4GB RAM hängt und bind9 als DNS verwendet.

Den bind9 habe ich vor ca. 12-15 (vielleicht auch noch mehr) Jahren auch mal laufen gehabt, als die Netzbetreiber noch der Meinung waren, sie müssten ihre Kunden verarschen und mit "Netzsperren" in Form von Nicht-Auflösung von Adressen nerven. Da der Mist irgendwann aufgegeben wurde, habe ich dann auch den eigenen bind9 drangegeben.

Was ist schon normal?
Ich habe es schon häufiger erlebt, dass tatsächlich *alle* Ports außer 80 und 443 zugeklebt waren. DNS läuft dann eben ausschließlich über den internen Router.
In einem solchen Fall hast Du dann gar nichts von den Klimmzügen im Heimnetz.

Ich habe in den Hostels, da ich sowieso nur mit Tablet und nicht mit dem Notebook unterwegs war, jetzt nicht explizit geschaut, welche Ports wirklich offen waren. Aber da außer "surfen" nichts ging, kein ssh, kein vpn, gehe ich von dem üblichen Mist aus, den die Leute an ihrer Fritzbox (eine Fritz war es wirklich) verfrickeln.

Was habe ich denn noch für eine Chance, wenn so ein Netz so verfrickelt ist, dass nur noch 80 und 443 gehen? Ich könnte natürlich zu Hause Port 80 frei machen und den lighttpd darauf nicht mehr lauschen lassen, aber so richtig will ich das eigentlich nicht. UDP kann man nicht umleiten?

[MSfree]

Was habe ich denn noch für eine Chance, wenn so ein Netz so verfrickelt ist, dass nur noch 80 und 443 gehen? Ich könnte natürlich zu Hause Port 80 frei machen und den lighttpd darauf nicht mehr lauschen lassen, aber so richtig will ich das eigentlich nicht. UDP kann man nicht umleiten?

Wenn die Hostels nur TCP-Port 80 und TCP-Port 443 durchlassen, dann nützt es dir nichts, wenn du dein VPN auf UDP-Port 80 oder 443 laufen läßt. UDP und TCP sind nicht das selbe.

Wie gesagt, du müßtest dann VPN über TCP statt UDP laufen lassen.

[dirk11]

Ok, danke. Das wird dann für die wenigen Fälle im Jahr aber zu kompliziert. Auf dem Laptop kann ich VPN over ssh laufen lassen, und das auf diversen Ports, da ist mir sowas gepflegt wurscht.

Auf dem "smarten" Device stellt man bei sowas sehr schnell fest, dass daran kaum was "smart" ist und eine Umsetzung a) kompliziert und b) nicht laienkompatibel möglich ist (wenn, dann sollte die Lösung nicht nur für mich sein). Aber dann wird halt drauf verzichtet bzw. Mobilfunk genutzt...