• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Fehler: Umleitungsfehler bei Apache Reverse Proxy

Lock

NGBler

Registriert
25 März 2020
Beiträge
72
Hallo zusammen,

ich habe auf meinem Raspbery Pi einen Apache Reverse Proxy Server aufgesetzt.
Ich möchte hier meine zwei Server - Netxcloud und Jitsi Meet von aussen (internet) erreichen.

Meinen Apache Reverse Proxy Server habe ich so installiert und eingerichtet.

## install apache2 ##
apt-get update
apt-get install apache2 -y

## enable moduls ##
a2enmod proxy
a2enmod proxy_http
a2enmod proxy_ajp
a2enmod rewrite
a2enmod deflate
a2enmod headers
a2enmod proxy_balancer
a2enmod proxy_connect
a2enmod proxy_html
service apache2 restart

## create config for 1st client ##
nano /etc/apache2/sites-enabled/server1.conf

<VirtualHost *:80>
ServerName subdomain11.yourdomain.com
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://10.1.1.11:80/
ProxyPassReverse / http://10.1.1.11:80/
</VirtualHost>

## create config for 2nd client ##
nano /etc/apache2/sites-enabled/server2.conf
<VirtualHost *:80>
ServerName subdomain12.yourdomain.com
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://10.1.1.12:80/
ProxyPassReverse / http://10.1.1.12:80/
</VirtualHost>

## restart apache server ##
service apache2 restart

## install Let's Encrypt Certbot ##
apt-get install python-certbot-apache

## create certificates ##
certbot --apache

#--> certificate only lasts 90 days

#install crontab
crontab -e

0 1 * * * /usr/bin/certbot renew & > /dev/nul

Natürlich habe ich die /etc/apache2/sites-enabled/server1.conf und /etc/apache2/sites-enabled/server2.conf auf meine Dyndns Adressen angepasst und meine Lokalen IP eingetragen.

Die ssl Zertifizierung sollte für beide Domains auch funktionieren.
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting vhost in /etc/apache2/sites-enabled/server1.conf to ssl vhost in /etc/apache2/sites-enabled/server1-le-ssl.conf
Redirecting vhost in /etc/apache2/sites-enabled/server2.conf to ssl vhost in /etc/apache2/sites-enabled/server2-le-ssl.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://.dyndns.org and
https:/mine.nu

Beispiel von mir:
/etc/apache2/sites-enabled/server2.conf

<VirtualHost *:80>
ServerName videomeet.dyndns.org
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/
RewriteEngine on
RewriteCond %{SERVER_NAME} =videomeet.dyndns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>


Ich habe in meiner Fitzbox die Ports 443 und 80 auf den pi weitergeleitet.
Rufe ich meine Seite aber über das Internet auf erhalte ich diese Meldungen:

Fehler: Umleitungsfehler
Beim Verbinden mit domain.dyndns.org trat ein Fehler auf.
Dieses Problem kann manchmal auftreten, wenn Cookies deaktiviert oder abgelehnt werden

Ich habe die Cookies gelöscht von unterschiedlichen Rechner und Netzten probiert, leider bleibt diese Meldung.
Was kann ich machen? Kann mir einer behilflich sein.
Gruß
 
Zuletzt bearbeitet:

Dr. M.

Weltmaschinenfahrer

Registriert
30 Juli 2018
Beiträge
188
Der Browser will dir vermutlich sagen, dass deine Site eine Umleitungsschleife hat - du also eine URL immer wieder auf sich selbst umleitest.
Auf die Schnelle haette ich
Code:
RewriteEngine on
RewriteCond %{SERVER_NAME} =videomeet.dyndns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
im Verdacht.
Steckt das auch in der VirtualHost-Config fuer TLS, also "*:443"? Dort waer's verkehrt.

Ausserdem - wenn du eh schon alles von HTTP weg nach HTTPS umleitest (was an sich ja gut ist), kannst du dir die ganze uebrige Konfiguration im HTTP-VirtualHost (also ProxyPass etc.) auch sparen.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Mal ne doofe Frage: Sind die anderen zwei Server andere Maschinen?

Wenn ja, musst du Proxyrules einrichten, korrekt. Dann aber entweder Rewrites oder Proxy, nicht beides zusammen. Außerdem: die sites-enabled ist eigentlich ein technisches Directory, man arbeitet grundsätzlich in sites-available und enabled dann via a2ensite die entsprechende Config (damit kann man schnell wieder zurück, wenn eine Config den Apachen kaputt schießt, und man den Fehler nicht auf die Schnelle findet).

Wenn das auf der gleichen Maschine ist, braucht es keinen Proxy. Umleitung via HTTP 301 genügt dann völlig. Man muss nur den Port am Router freischalten.
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
Und Tests von Seiten die extern erreichbar sein sollten bitte immer mit dem Handy ohne WLAN machen.
Laut den logs kommen ja zumindest anfragen an, wobei du neben vhost in ein eigenes Log schreiben solltest

Die Fritzbox leitet Anfragen an das eigene Netz meist erstmal nicht über die externe Schnittstelle was zu unerwarteten Ergebnissen führen kann
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
Wenn das auf der gleichen Maschine ist, braucht es keinen Proxy. Umleitung via HTTP 301 genügt dann völlig. Man muss nur den Port am Router freischalten.

Ist bei uns allerdings ein Standardvorgehen. Wir klemmen vor jeden Webservice (Tomcat, Glassfish, u.a.) einen Apache. Hat die Vorteile:
  • Standardisierte Zertifikatsinstallation. Bei anderen Webdiensten müssten wir dann die unterschiedlichen Configs erst durcharbeiten
  • Verwendung Port 443: Unsere firmeninternen Firewalls mögen keine abweichenden Ports. Genauso sind aus dem Firmennetzwerk auch keine Internetseiten erreichbar, die auf anderen Ports laufen.
  • Zugriffskontrolle per LDAP, Kerberos, AD: Auch das frühstücken wir über den vorgeschalteten Apache als Proxy ab.


Code:
RewriteCond %{SERVER_NAME} =videomeet.dyndns.org
https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewritecond
Ich finde da nirgendwo ein =.


Was mich in den Logs stutzig macht:
Da tauchen die Fehler 302 und 400 auf. Metal_Warrior hat's auch schon erwähnt. Sofern die 192.168.0.50 auf demselben Server liegt wie der Apache, kommt der Server ja gar nicht aus der Umleitung raus. D.h. du schickst den beim Aufruf von Port 80 immer wieder in dieselbe VHost-Sektion rein. Der kommt gar nicht erst bis zum Proxy Pass. Deswegen wär's interessant zu wissen, von welchen IPs auf welche der Proxy funktionieren soll.
 
Zuletzt bearbeitet:

Lock

NGBler

Registriert
25 März 2020
Beiträge
72
  • Thread Starter Thread Starter
  • #8
Hallo zusammen,

danke erstmals das ihr euch dieses Thema annimmt.
Ich beschreibe am besten Erstmal mein Netzwerk.
  • Router ist eine Fritzbox mit der IP 192.168.0.1
  • Der Apache Reverse Proxy läuft auf einem Raspberry PI mit der IP 192.168.0.38
  • Der Jitsi Server läuft auf einem Debian 10 mit der IP: 192.168.0.50
  • Nextcloud läuft auf einem Raspberry PI mit der IP: 192.168.0.70


Also alle Geräte laufen auf eigenen Maschinen.

Ich bin wie im ersten Post vorgegangen und habe nach dieser Anleitung gearbeitet.


Ich habe unter /etc/apache2/sites-enabled/server2.conf
diesen Eintrag:
[src=apache]<VirtualHost *:80>
ServerName videomeet.mine.nu
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/
RewriteEngine on
RewriteCond %{SERVER_NAME} =videomeet.mine.nu
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>[/src]

[src=apache]
RewriteEngine on
RewriteCond %{SERVER_NAME} =videomeet.mine.nu
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent][/src]
Diese Einträge stammen von certbot --apache

Da ich, wie auch schon festgestellt wurde, alle Einträge über https laufen lassen möchte habe ich mich auch nach dem Sinn der oberen Eintragung gefragt und eine
neue server4.conf erstellt.

[src=apache]<VirtualHost *:443>
ServerName lock.dyndns.org
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://192.168.0.70:443/
ProxyPassReverse / http://192.168.0.70:443/
RewriteEngine on
RewriteCond %{SERVER_NAME} =lock.dyndns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>[/src]

aber auch dieser leitete nicht weiter.

Ich habe auf Jitsi Meet und dem Netxcloud bereits Zertifikate über cerbot erstellt.
Zum einen frage ich mich, wie ich ob ich mehrere Zertifikate auf eine IP nutzen kann zum anderen stellt sich für mich die Frage, wo ich die Zertifikate erstellen soll, auf dem Gerät (also Jitsi / Netxcloud) oder auf dem Apache.

Ist es eventuell besser mit einem Nginx Proxy Manager mit GUI zu arbeiten?

Ich hoffe ich konnte euch weitere Infos geben und ihr könnt meine Fragen beantworten.

Gruß Lock
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
Eine Gui behebt nicht das Problem das man verstehen muss was man machen möchte... im Gegenteil - das verstärkt das Problem eher.

Ich kenne nun leider den Syntax für Apache als ReverseProxy nicht - da ich in der Tat für alles grunsätzlich Nginx verwende.
Aber das du "alles" auf eine IP weiterleitest macht so keinen Sinn.

Was möchtest du denn erreichen? Beide Dienste auf deiner IP zu betreiben.. soweit so klar...
Aufruf über eine Subdomain oder über einen Teil der URL?

  1. Der Client "verbindet" sich mit der Fritzbox.
  2. Die Fritzbox leitet Anfragen auf Port 80 + 443 an den Raspi, dort wartet ein Dienst der die Frage entgegen nimmt, dieser benötigt nun ein SSL-Zertifikat für die Verbindung Raspi <-> Client. Passend für die jeweilige(n) Domain(s).
  3. Der Dienst auf dem Raspi baut dann innerhalb deines Netzwerks eine Verbindung zum anderen PC / Raspi auf und ruft dort Infos ab. Hier kannst du dir dann überlegen ob du das wieder über SSL machst oder ohne. So oder so benötigt dann dort, wenn du über https gehst, erneut die jeweiligen Zertifikate auf den Zielsystemen. Wichtig ist das der Reverse-Proxy die Verbindung Terminiert und nicht "Durchleitet".
    Ebenso müssen auch Rewrite-Geschichten überdacht werden. Es bringt nicht viel url-Rewrites an allen ecken und Enden umzusetzen.
    Eventuell bringt das Rewrite oben nach der Weiterleitung an die proxy-Adresse auch nichts mehr? (Wie gesagt kenne hier die Verarbeitung nicht).

Die Konfiguration muss jedenfalls so lauten das der Reverse-Proxy weiß was er bei Aufruf von hostname 1 machen soll und was bei hostname 2 - beide können dabei natürlich auf einer IP laufen. Ein VHOST mit *:80 heißt hier aber das bei beiden Hostnamen immer das gleiche passiert.
 

Lock

NGBler

Registriert
25 März 2020
Beiträge
72
  • Thread Starter Thread Starter
  • #10
Hallo,

ich möchte folgendes erreichen.

Ich habe z.Z. zwei Dyndns Adressen.

Beispiel:

jitis.dyndns.org
und
nextcloud.dyndns.org

Diese beiden Adressen möchte ich so weiterleiten, dass ich diese vom Internet aus erreichen kann.
Da beide den Port 80 und 443 verwenden ist mein Router hier überfordert, er kann nur an eine IP weiterleiten.

Deshalb wollte ich einen Reverse Proxyn aufsetzten.

Dazu habe ich wie in der Anleitung im ersten Post diesen erstellt.

Um eine Weiterleitung zu erreichen habe ich mehrere
/etc/apache2/sites-enabled/server1.conf
erstellt.

Beispiel:
/etc/apache2/sites-enabled/server1.conf

[src=apache] <VirtualHost *:80>
ServerNamej itsie.dyndns,org
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/
RewriteEngine on
RewriteCond %{SERVER_NAME} =itsie.dyndns,org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>[/src]

und
/etc/apache2/sites-enabled/server2.conf

mit diesem Inhalt:

[src=apache] <VirtualHost *:80>
ServerName nextcloud.dyndns.org
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://192.168.0.70:80/
ProxyPassReverse / http://192.168.0.70:80/
RewriteEngine on
RewriteCond %{SERVER_NAME} =nextcloud.dyndns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>[/src]

dadurch will ich erreichen, wenn ich aus dem Internet auf

nextcloud.dyndns.org zugreife komme ich auf meine nextcloud
und wenn ich auf
ijtsie.dyndns,org zugreife komme ich auf den jitsi Server.

Meine Frage geht auf die Syntac
Laut Beschreibung habe ich

[src=apache] <VirtualHost *:80> ---- ist hier nicht Port 443 richtig
ServerName nextcloud.dyndns.org
ProxyPreserveHost On
DocumentRoot /var/www/html
ProxyPass /.well-known !
ProxyPass / http://192.168.0.70:80/ ---- ist hier nicht Port 443 richtig
ProxyPassReverse / http://192.168.0.70:80/ ---- ist hier nicht Port 443 richtig
RewriteEngine on
RewriteCond %{SERVER_NAME} =nextcloud.dyndns.org
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>[/src]

Eventuell kann mir hier einer weiterhelfen und ich hoffe ich habe meine Wünsche jetzt einigermassen deutlich formuliert ;-)

Gruß Lock
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
Ja, ist verständlich formuliert. Was wir oben schon ein paar mal geschrieben haben, hast du noch immer nicht korrigiert.



Um eine Weiterleitung zu erreichen habe ich mehrere /etc/apache2/sites-enabled/server1.conf erstellt.
S.o. das kommt nicht in sites-enabled sondern in sites-available rein und wird dann rübergelinkt.

[src=apache] <VirtualHost *:80>
ServerNamej itsie.dyndns,org
ProxyPreserveHost On
DocumentRoot /var/www/html # eigentlich auch sinnlos, da du alles per Proxy weiterschickst.
ProxyPass /.well-known ! # wozu?
ProxyPass / http://192.168.0.50:80/ # sind die url-Tags vom Forum? Die sind da falsch.
ProxyPassReverse / http://192.168.0.50:80/ # falsche url-Tags
RewriteEngine on # eigentlich sinnlos, da du sowieso alles bis auf die .well-known an die .50 weiterleitest.
RewriteCond %{SERVER_NAME} =itsie.dyndns,org # sinnlos + siehe oben, das = steht nicht in der Apache-Doku
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent] # sinnlos.
</VirtualHost>[/src]
Wenn auch https verwendet wird, musst du noch einen VirtualHost für Port 443 definieren. Jetzt ist die Frage, ob Jitsi und Nextcloud wie wild zwischen http oder https wechseln. Falls nicht, würde ich intern rein auf http setzen.

Also Minimalbeispiel für Dein Jitsi:
[src=apache]
<VirtualHost *:80>
ServerNamej itsie.dyndns,org
ProxyPreserveHost On
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/
</VirtualHost>

<VirtualHost *:443>
ServerNamej itsie.dyndns,org
ProxyPreserveHost On
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/
</VirtualHost>
[/src]

Probier aus, ob das läuft und leg dann ggf. noch die beiden VirtualHost-Sektionen für nextcloud an. Und wenn du von außen nur https zulässt, kannst du Dir sogar noch den ersten VirtualHost-Block sparen.
 

Lock

NGBler

Registriert
25 März 2020
Beiträge
72
  • Thread Starter Thread Starter
  • #12
Hallo,

danke für die Hilfestellung und den wichtigen Hinweis mit

/etc/apache2/sites-available

Ich habe jetzt die Inhalte von sites-enabled nach etc/apache2/sites-available kopiert.
Danach habe ich den Apache neu gestartet.
Leider brachte das keinen Erfolg.:(

Ich habe dann die server1.conf bearbeitet.

[src=apache]<VirtualHost *:80>
ServerName videomeet.mine.nu
ProxyPreserveHost On
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/
</VirtualHost>

<VirtualHost *:443>
ServerName videomeet.mine.nu
ProxyPreserveHost On
ProxyPass / http://192.168.0.50:443/ -----Hier habe ich die Ports auf 443 gestellt
ProxyPassReverse / http://192.168.0.50:443/ -----Hier habe ich die Ports auf 443 gestellt
</VirtualHost>
[/src]

Apache neu gestartet, leider ohne Erfolg.
Ich teste meine Webseiten immer über diese Seite
http://free-website-translation.com/?de
dann werden meine Seiten von ausserhalb aufgerufen.

Hier erhalte ich die Meldung:

Die angefragte Seite hat eine Weiterleitung zu sich selbst versucht, was zu einer Endlosschleife führen könnte.

Kann hier was falsch sein, weil beide auf die gleiche
S.o. das kommt nicht in sites-enabled sondern in sites-available rein und wird dann rübergelinkt.

IP Linken.
ProxyPass / http://192.168.0.50:80/
ProxyPassReverse / http://192.168.0.50:80/


S.o. das kommt nicht in sites-enabled sondern in sites-available rein und wird dann rübergelinkt.

Reicht hier das Kopieren, oder muss ich was anderes beachten.


Beste Grüße Lock
 

drfuture

Zeitreisender
Teammitglied

Registriert
14 Juli 2013
Beiträge
8.728
Ort
in der Zukunft
Mit Link ist ein Symbolischer Link gemeint "ln -s ..... ".

Die Weiterleitung kann gut und gerne auch von der Webanwendung selbst kommen - das heißt dein Reverse-Proxy würde funktionieren.
Zum Testen von etwas bitte am besten immer die minimalste komplexität verwenden die für das zu testende Szenario notwendig ist.

Im deinem jetzigen Aufbau kannst du unmöglich feststellen wo der Fehler liegt.

- Eventuell reagiert die "Free-website-Translation" Seite komisch bei dyndns Adressen?
- Eventuell ist Nextcloud / Jitsi falsch konfiguriert?
- Eventuell passt der Reverse-Proxy nicht?
- Vielleicht passt auch der Apatche von Nextcloud nicht...?

Um festzustellen das zumindest die Webserver korrekt funktionieren würde ich im Grunde sogar ohne SSL arbeiten.

Das heißt auf einem System, z.B. das mit Nextcloud einen vhost mit einem leeren Basisverzeichnis einrichten der auf nextcloud.dyndns.org hört.
In das Verzeichnis kommt dann eine index.html in der einfach nur "Hallo ich bin`s die Nexcloud-Seite" ... steht.
Dann gehst du, wie oben vorgeschlagen, mit dem Handy übers Mobilfunknetz oder du machst einen Hotspot auf und gehst mit dem Laptop darüber auf die Seite und schaust was passiert.

Mir fallen in jedem Fall ohne Test 2 Fehler auf:

- Bei der SSL-Konfiguration (Daher wäre ein Test ohne erst einmal besser) am Reverse Proxy fehlt die Definition des SSL-Zertifikats on SSL-On

SSLEngine on
SSLCertificateFile /---/public.pem
SSLCertificateKeyFile /---/privkey.pem
SSLCertificateChainFile /---/chain-class2.pem

Wie oben beschrieben ruft der Reverse-Proxy die Seiten des internen Webservers von z.B. Nextcloud ab. Daher ist dann die Aufrufende URL auch nicht mehr "nextcloud.dyndns.org" sondern laut Doku ein Eintrag aus der Proxypass-Direktive ... leider steht in der Doku nicht so wirklich was genau?
Alternativ kann "ProxyPreserveHost On" gesetzt werden damit der von extern kommende Hostname im Header an den internen Server weitergegeben wird.
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
/etc/apache2/sites-available

Ich habe jetzt die Inhalte von sites-enabled nach etc/apache2/sites-available kopiert.
Nicht kopieren sondern verschieben.
[src=bash]cd /etc/apache2/sites-enabled
mv * ../sites-available/
cd ../sites-available
ln -s ../site-enabled/*[/src]
Das ist übrigens die Debian-Syntax. Andere Distributionen arbeiten nicht mit sites-available usw. Das Ganze hat den Sinn, dass du VHosts nach Lust und Laune konfigurieren, die aber gezielt aktivieren und deaktivieren kannst. In irgendeiner Apache-Config-Datei werden dann alle Configs aus /etc/apache2/sites-enabled geparst.

Im Grunde genommen hat damit Deine ursprüngliche Konfiguration schon soweit funktioniert, dass die Vhosts eingelesen wurden. Es war halt nur etwas ungünstig platziert.

Ich habe dann die server1.conf bearbeitet.

[src=apache]<VirtualHost *:443>
ServerName videomeet.mine.nu
ProxyPreserveHost On
ProxyPass / http://192.168.0.50:443/ -----Hier habe ich die Ports auf 443 gestellt
ProxyPassReverse / http://192.168.0.50:443/ -----Hier habe ich die Ports auf 443 gestellt
</VirtualHost>
[/src]
Ich hatte da bewusst die 80 verwendet. Ich glaub, du hast das Prinzip nicht nicht ganz verstanden.

[src=apache]<VirtualHost *:443> #Dein Apache hört auf alle Anfragen auf Port 443
ServerName videomeet.mine.nu # Wenn im HTTP-Header der Server videomeet.mine.nu aufgerufen wurde, hast du hier einen Match
ProxyPreserveHost On # videomeet.mine.nu bleibt im HTTP-Header erhalten als Anfrager.
ProxyPass / http://192.168.0.50:80 # Die Anfrage wird dann intern an die 192.168.0.50 auf Port 80 weitgerleitet.
ProxyPassReverse / http://192.168.0.50:80 # Und was von der .50 zurückkommt wird wieder nach draußen geschickt.
</VirtualHost>
[/src]
Intern ist Port 80 erst mal sinnvoller. Ansonsten müsstest du ein SSL-Zertifikat auf dem Webserver von 192.168.0.50 konfiguriert haben. Bei Port 80 sparst du Dir das.

Der Unterschied zwischen ProxyPass und Redirect (RewriteRule) ist:
Beim Redirect wird die Anfrage an eine neue URL umgeleitet. Der Aufrufer der URL bekommt das auch mit. D.h. im Browser ändert sich die URL. Beim ProxyPass leitet der Apache intern die Anfrage an eine andere Applikation, einen anderen Port oder eine andere Adresse weiter. Der Aufrufer der URL bekommt das aber nicht mit. Er sieht nur den Apache auf Port 80 oder 443 (was im VirtualHost konfiguriert ist). Wie ich bereits oben mal erwähnt hab, verwenden wir ProxyPass ziemlich ausgiebig in der Arbeit, um lokale Tomcats, Glassfische oder andere Application Server abzuschotten. Über den Apache konfigurieren wir den Zugang per HTTPS mit Zertifikat auf Port 443 und eventuell noch LDAP-Authentifizierung. Und hinter der lokalen Firewall verborgen arbeitet der Application Server, der nur über Localhost durch den Apache erreicht werden kann. Hat den Vorteil, dass wir ein mit Templates standardisiertes Vorgehen haben und uns die lokale Anwendung ziemlich egal ist.

Und wie DrFuture schon mal geschrieben hat, solltest du erst mal das komplexe Gebilde auf die einzelnen Schritte runterbrechen. D.h. sinnvoll wäre erst mal der Check, ob die Webanfrage auf der 192.168.0.38 ankommt. Dazu kommentierst du mal das ProxyPass aus und legst eine index.html mit Hallo ins DocumentRoot
[src=apache]<VirtualHost *:443>
ServerName videomeet.mine.nu
DocumentRoot=/var/www/html
</VirtualHost>

<Directory /var/www/html>
Options Indexes
AllowOverride None
Require all granted
</Directory>[/src]

Und in /var/www/html legst du eine index.html mit "hallo" an.

Wenn das klappt, weißt du schon mal, dass der Raspi von außen erreichbar ist über https. Dann kannst du den o.g. VHost wieder verwenden mit dem ProxyPass. Auf der 192.168.0.50 lässt du mal einen tcpdump laufen, d.h.
[src=bash]tcpdump -v -i eth0 host 192.168.0.38 and port 80[/src]
Wenn beim Aufruf der Adresse von außen, dann das tcpdump fleißig Nachrichten schreibt, weißt du, dass auch diese Verbindung (außen -> Raspi -> jitsi-Server) klappt.
 
Zuletzt bearbeitet:

Lock

NGBler

Registriert
25 März 2020
Beiträge
72
  • Thread Starter Thread Starter
  • #15
Hallo zusammen,

erst mal vielen Dank das ihr so geduldig mit mir seid.:T

Ich hoffe das ich eure Anweisung richtig verstanden habe und beschreibe einmal was ich gemacht habe.

Habe das ausgeführt:
[src=bash] cd /etc/apache2/sites-enabled
mv * ../sites-available/
cd ../sites-available
ln -s ../site-enabled/*[/src]



unter
/etc/apache2/sites-available
habe ich die server1.conf erstellt
mit diesem Inhalt.

[src=apache] <VirtualHost *:443>
ServerName videomeet.mine.nu
DocumentRoot=/var/www/html
</VirtualHost>

<Directory /var/www/html>
Options Indexes
AllowOverride None
Require all granted
</Directory>[/src]

Danach habe ich den Apache neu gestartet.


service apache2 restart


Unter
/var/www/html
liegt schon eine index,html deshalb habe ich keine neue erstellt.

Von einem anderen Debian System im LAN habe ich dann das ausgeführt und leider nur das erhalten:

tcpdump -v -i eth0 host 192.168.0.38 and port 80
[src=bash]tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes[/src]

Von ausserhalb komme ich auch nicht auf
videomeet.mine.nu/

In der Fritzbox habe ich diese Port weitergeleitet an den Proxy:
raspberrypi
192.168.0.38
HTTPS-Server
HTTP-Server
443
80
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
Ich probiers jetzt mal anders (nachdem ich Jitsi auch schon aufgesetzt hab und der mitunter eventuell eh deinen Proxy zerschießt, ist das vielleicht so rum sinnvoller):

Auf deinem Jitsi-Server deaktivierst du bitte die Jitsi-Config. Nur noch die 000-default.conf aktiv lassen. Das überprüfst du bitte, indem du den Server aus dem internen Netz aufrufst. Meldet sich da Debian mit seiner "It Works!"-Seite, bist du an der Stelle schonmal richtig.

Deinem HTTP- und HTTPS-Server, den du ja als Proxy nutzen möchtest, spendierst du bitte eine feste IP. Ob du das mit deinem Router anstellst oder den Server selbst vom DHCP abklemmst und per Static IP konfiguriest, ist egal. Wichtig ist nur, dass er nicht auf blöd mal ne andere IP bekommen kann. Anschließend leitest du genau Port 80 und Port 443 auf diese IP weiter.

Mit deinen anderen zwei Servern verfährst du bitte ebenso. Feste IPs. Egal wie. Nichts ist ärgerlicher, als Umleitungen ins Nichts.

Anschließend erstellst du auf deinem HTTP-Server eine Config in sites-available, die nichts anderes tut als eine Umleitung von Port 80 auf Port 443 und nennst sie http.conf:

[src=apache]<VirtualHost *:80>
RewriteEngine on
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
Errorlog ${APACHE_LOG_DIR}/http_error.log
Customlog ${APACHE_LOG_DIR}/http_access.log combined
</VirtualHost>[/src]

Damit wird jetzt ALLES, egal von woher, erstmal auf HTTPS gezogen. Damit merzen wir mal eine Fehlerquelle aus. Du deaktivierst bitte mit a2dissite alle Sites. Alle. Es darf kein Link und keine Datei mehr in sites-enabled sein. Anschließend tippst du

[src=bash]sudo a2ensite http.conf
sudo systemctl restart apache2[/src]

Rufst du jetzt die Seite (von intern oder extern auf, MUSS ein "Server antwortet nicht" auf HTTPS kommen. Kommt das nicht, hast du woanders was vergurkt.
Kommt es aber, machen wir weiter:
Neue Config in sites-available, diesmal nennst du sie https.conf:

[src=apache]<VirtualHost *:443>
ServerName DEINEDOMAIN.TLD
DocumentRoot /var/www/html

SSLEngine on
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Errorlog ${APACHE_LOG_DIR}/https_error.log
Customlog ${APACHE_LOG_DIR}/https_access.log combined
</VirtualHost>[/src]

Anschließend wieder:
[src=bash]sudo a2ensite https.conf
sudo systemctl restart apache2[/src]

Jetzt solltest du eine Zertifikatswarnung bekommen (weil das die Snakeoil-Zertifikate sind, die Debian am Anfang generiert) und wenn du das Risiko akzeptierst, die schnuckelige Debian-"It Works!"-Seite vom Apachen. Wenn bis dahin alles geklappt hat, können wir weiter machen. Erstmal aber soweit kommen.
 
Zuletzt bearbeitet:

Lock

NGBler

Registriert
25 März 2020
Beiträge
72
  • Thread Starter Thread Starter
  • #17
Hallo zusammen,

also ich habe die Tage versucht das umzusetzen was hier geschrieben wurde.
Da ich an meinem Jitsi-Mett Server nicht verändern wollt, habe ich bei meiner ProxMox Maschine ein Debian mit Apache2 Aufgesetzt.
Hier habe ich schon eine default index.html und musste nicht umändern.

Alle Geräte haben eine Statische IP !



Mit deinen anderen zwei Servern verfährst du bitte ebenso. Feste IPs. Egal wie. Nichts ist ärgerlicher, als Umleitungen ins Nichts.

Anschließend erstellst du auf deinem HTTP-Server eine Config in sites-available, die nichts anderes tut als eine Umleitung von Port 80 auf Port 443 und nennst sie http.conf:

Code (Apache/.htaccess):

<VirtualHost *:80>
RewriteEngine on
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
Errorlog ${APACHE_LOG_DIR}/http_error.log
Customlog ${APACHE_LOG_DIR}/http_access.log combined
</VirtualHost>

Ich habe die http.conf mit dem Inhalt erstellt, ich sehe aber die VirtualHost *:80 aber sehe nicht die Umleitung auf 443 :eek:
Beziehungsweise verstehe ich die Syntax nicht.


[src=php]<VirtualHost *:443> #Dein Apache hört auf alle Anfragen auf Port 443
ServerName videomeet.mine.nu # Wenn im HTTP-Header der Server videomeet.mine.nu aufgerufen wurde, hast du hier einen Match
ProxyPreserveHost On # videomeet.mine.nu bleibt im HTTP-Header erhalten als Anfrager.
ProxyPass / http://192.168.0.50:80 # Die Anfrage wird dann intern an die 192.168.0.50 auf Port 80 weitgerleitet.
ProxyPassReverse / http://192.168.0.50:80 # Und was von der .50 zurückkommt wird wieder nach draußen geschickt.
</VirtualHost>[/src]
@musv Nach deiner Syntac sollte doch alles klappen und logisch sein. Adressen stimmen und die IP Adressen,
leider kein Erfolg.

Habt ihr eventuelle Alternative Hilfestellungen ?
Gruß

Lock
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@Lock: Die Default-HTML hast du überall auf Debian, und an deinem Jitsi hättest du nix ändern müssen, sondern nur die Seite disablen. Das ist der Grund, warum das Links sind, eben damit man nix verändern muss.

Und wenn du genau liest, hab ich dir die Umleitung exakt so geschrieben, wie sie funktioniert. HTTPS ist auf 443, weil das der Standardport ist.

Nochmal, bau bitte EXAKT das nach, was ich dir gesagt hab. Solltest du wieder selber denken versuchen, bin ich raus.
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.453
Ort
/dev/null
@musv Nach deiner Syntac sollte doch alles klappen und logisch sein. Adressen stimmen und die IP Adressen,
leider kein Erfolg.
Ja, aber auch meinen eigentlichen Vorschlag hast du oben übersprungen. Genau wie Metal_Warrior wollte ich mit der selbst erstellen index.html bei Dir erst mal sicherstellen, dass du:
  1. von außen erst mal auf Deinem Apache landest und der eine Seite ausgibt.
  2. wenn das klappt, der Apache die Umleitung von http auf https hinbekommt und dabei wieder die lokale Seite auf Deinem Apache ausgibt (diesmal über https).
  3. wenn das klappt, der Apache per Proxy auf den Jitsi-Rechner weiterleitet und dort was anfragt (deswegen tcpdump).
  4. wenn das klappt, der Jitsi-Server auf den Apache-Request antwortet.
Dein Problem dabei ist, dass du von Schritt 1 gleich zu Schritt 4 springst und die Zwischenschritte ignorierst. Dafür brauchst du kein Proxmox, keine zusätzlichen VMs.

Arbeite bitte die einzelnen Schritte von Metal_Warriors Anleitung ab!
 

Lock

NGBler

Registriert
25 März 2020
Beiträge
72
  • Thread Starter Thread Starter
  • #20
Hallo zusammen,

sorry für die Missverständnisse, ich sehe den Wald vor lauter Bäumen nicht mehr. Ich bin sehr dankbar das ihr so nett seid und mir hier weiterhelfen wollt.

Ich fange nochmal an, Schritt für Schritt.


Deinem HTTP- und HTTPS-Server, den du ja als Proxy nutzen möchtest, spendierst du bitte eine feste IP. Ob du das mit deinem Router anstellst oder den Server selbst vom DHCP abklemmst und per Static IP konfiguriest, ist egal. Wichtig ist nur, dass er nicht auf blöd mal ne andere IP bekommen kann. Anschließend leitest du genau Port 80 und Port 443 auf diese IP weiter.

Mit deinen anderen zwei Servern verfährst du bitte ebenso. Feste IPs. Egal wie. Nichts ist ärgerlicher, als Umleitungen ins Nichts.

Habe ich gemacht, alle Geräte haben eine Statische IP.

Anschließend erstellst du auf deinem HTTP-Server eine Config in sites-available, die nichts anderes tut als eine Umleitung von Port 80 auf Port 443 und nennst sie http.conf:

Auf dem Proxy habe ich die Datei angelegt:
nano /etc/apache2/sites-available/http.conf

Inhalt:
[src=apache] <VirtualHost *:80>
RewriteEngine on
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L]
Errorlog ${APACHE_LOG_DIR}/http_error.log
Customlog ${APACHE_LOG_DIR}/http_access.log combined
</VirtualHost>
[/src]
Ich geben dann
a2dissite
ein
[src=apache]
ur choices are: 000-default
Which site(s) do you want to disable (wildcards ok)?[/src]

bestätige mit Enter.


Prüfe /etc/apache2/sites-enabled - ob hier alle leer ist:

[src=apache]/etc/apache2/sites-enabled# ls -la
total 8
drwxr-xr-x 2 root root 4096 Nov 23 19:19 .[/src]

Dann kommt:

[src=apache]a2ensite http.conf
Site http already enabled
und
systemctl restart apache2[/src]

Rufst du jetzt die Seite (von intern oder extern auf, MUSS ein "Server antwortet nicht" auf HTTPS kommen. Kommt das nicht, hast du woanders was vergurkt.
Kommt es aber, machen wir weiter:

Hier muss ich nochmal nachfragen, du meinst als Server den Jitsi.Server, ist das richtig.
Wenn ich die dyndns Adresse eingeben bekomme ich :

[src=apache]Die Website ist nicht erreichbar

hat die Verbindung abgelehnt.
Versuchen Sie Folgendes:

Verbindung prüfen
Proxy und Firewall prüfen
ERR_CONNECTION_REFUSE[/src]D

Diese Meldung bekomme ich auch über mein Handy, also über ein extrenen Netz.


Wenn ich die Lokale IP aufrufe :
192.168.0.50/
erhalte ich diese Meldung:

[src=apache]Dies ist keine sichere Verbindung
Hacker könnten versuchen, Ihre Daten von 192.168.0.50 zu stehlen, zum Beispiel Passwörter, Nachrichten oder Kreditkartendaten. Weitere Informationen
NET::ERR_CERT_COMMON_NAME_INVALID[/src]

Wobei das glaube ich nicht interessant ist.
Was habe ich den bis hier falsch gemacht?

cat access.log | pastebinit -b slexy.org
http://slexy.org/view/s2C2O2uNa6

cat error.log | pastebinit -b slexy.org
http://slexy.org/view/s2viA52CP8

cat http_access.log | pastebinit -b slexy.org
http://slexy.org/view/s20mLEejKl

Ich habe nochmal die logs hochgeladen.

Danke nochmals für eure Hilfe.:T
 
Oben