staging.inyokaproject.org

Hi,

ich habe hier eine Frage zu einem etwas seltsamen Scenario und hoffe, dass ich hier richtig bin.

Ich betreibe zwei Nextcloudinstanzen (z.B. auf nextcloud1.meine.domain und nextcloud2.meine.domain). Die zweite horcht aus Sicherheitsgründen nicht auf Port 443, sondern z.B. nur auf Port 12345 und hat auch keine feste IP (aber natürlich ein dynamisches DNS), sondern sitzt zu Hause hinter meiner Fritzbox. Zusätzlich habe ich einen Collaboraserver (collabora.meine.domain), der normal über Port 443 erreichbar ist. Wenn ich in Nextcloud mittels des Collaboraservers eine Datei bearbeite, wird unter anderem auch eine Verbindung vom Collaboraserver zum Nextcloudserver aufgebaut. Das klappt für nextcloud1.meine.domain auch wunderbar, aber für nextcloud2.meine.domain nicht, da Collabora standardmäßig den Port 443 verwendet. Wenn ich in meiner Fritzbox neben 12345 auch den Port 443 aufmache, funktioniert alles auch mit nextcloud2.meine.domain.

Ich frage mich nun, ob man mit iptables auf collabora.meine.domain den ausgehenden Netzwerkverkehr an nextcloud2.meine.domain:443 auf nextcloud2.meine.domain:12345 umleiten kann. Und zwar nur für diese eine Zieladresse. Oder lässt sich das irgendwie mit ssh-Tunneln erreichen?

Kann mir jemand helfen? Vielen Dank.

nextcloud1.meinedomain.de: fremdgehoster Webspace ohne root-Zugang

nextcloud2.meinedomain.de: Raspbian GNU/Linux 10 (buster) armv7l mit root-Zugang

collabora.meinedomain.de: Ubuntu 20.04.3 LTS x86_64 mit root-Zugang

Vielleicht rinetd? https://github.com/boutell/rinetd

Habe das selbst aber noch nicht genutzt.

Nach kurzer Durchsicht sieht es so aus, als ob diese Software genau das macht, was ich mir vorstelle. Ich werde mir das Paket mal ansehen.

Es scheint zwar etwas mühsam ist, bei jeder neuen dynamischen IP die Konfiguration zu ändern. Das wird sich aber sicher mit einem kleinen Skript von nextcloud2 erledigen lassen. Und bei iptables wäre es wohl nicht anders.

Vielen Dank schon einmal.

Leider bin ich nicht in der Lage, rinetd.conf so zu konfigurieren, wie ich es mit vorstelle. Ich mittlerweile, dass rinetd.conf eben doch nicht das macht, was ich brauche. Schade.

Ich habe mein Problem jetzt so "gelöst", dass ich eben doch den den Port 443 in meiner Fritzbox aufgemacht habe und den RPI (nextcloud2.meine.domain, die zweite Nextcloudinstanz) sowohl auf 443, als auch auf 12345 horchen lasse. Zusätzlich läuft auf dem RPI eine Firewall, die auf Port 443 alles blockt, was nicht von collabora.meine.domain kommt. Funktioniert, ist aber irgendwie unbefriedigend.

Falls jemand noch ein Idee hat, wie man den Port des selbstproduzierten, ausgehenden Netzwerkverkehrs in Abhängigkeit der ZIEL-Adresse verändern kann, bin ich für Tipps dankbar. Daher setze ich den Status noch nicht auf "gelöst".

malkubuntu schrieb:

Ich frage mich nun, ob man mit iptables auf collabora.meine.domain den ausgehenden Netzwerkverkehr an nextcloud2.meine.domain:443 auf nextcloud2.meine.domain:12345 umleiten kann. Und zwar nur für diese eine Zieladresse.

Das sollte mit destination-NAT in der OUTPUT-chain, möglich sein.

Hallo!

Welchen Webserver verwendest du denn? Wenn der ja eh schon auf 443 läuft, müsstest du doch nur die Anfragen zu nc2 umleiten, oder habe ich das Setup missverstanden? Beispiel für den Apachen:

<VirtualHost *:443>
…
        <Location />
                ProxyPass http://127.0.0.1:12345/
                ProxyPassReverse http://127.0.0.1:12345/
        </Location>
…

Danke für die Rückmeldung, habe die letzte Nachricht von ChickenLipsRfun2eat wohl irgendwie übersehen ...

Auf collabora.meine.domain verwende ich nginx. Ich verstehe nur nicht, wie ich mit dem lokalen Webserver, den Port einer ausgehenden Verbindung ändern soll. Ich bin aber auch kein Netzexperte ...

Aber vielleicht hatte ich mich auch nicht so ausgedrückt, dass ich verständlich bin. Ich verstehe den Ablauf so:

Ein user kommuniziert über seinen Browser mit nc2 über den "geheimen" Port 12345. Wenn dieser auf nc2 eine Officedatei öffnet, schickt nc2 die Datei an collabora über Port 443 auf dem die Datei verarbeitet wird. Wenn die Datei gespeichert werden soll, schickt collabora die Datei an nc2 zurück. Und genau das ist der Knackpunkt. collabora schickt sie immer über den Port 443 unabhängig davon unter welchem Port der Rechner, von dem sie stammt, erreichbar ist.

Konkret heißt das, dass in meinem Dockercontainer eine Anwendung sitzt, die immer wieder Verbindungen über 443 an nc1 oder nc2 aufbaut. Und ich möchte diese ausgehenden Verbindungen in Abhängigkeit des Ziels und nicht der Quelle (die ja immer unverändert der Dockercontainer ist) manipulieren: Also nc1 unverändert, nc2 443->12345. Kann das der lokale webserver auf collabora?

Wie gesagt, ich habe meinen dirty hack mit der Firewall auf nc2 gefunden, ich kann damit leben. Wenn jemand Resourcen frei hat, darf er/sie sich gerne an einer sauberen Lösung beteiligen ...

Vielen Dank nochmals für alle Tipps.