Es geht nicht darum, ob Du es brauchst oder nicht brauchst. Es geht darum, dass es funktioniert, wenn man will bzw. wenn man sshd-Server und ssh-Client richtig konfiguriert, denn ich benutze ssh mit pubkey und ohne pubkey (d. h. nur mit Passwort), im WG-Tunnel.
Apache2 Reverse-Proxy: Übermittelte Webseite wird im Internet ohne Bilder angezeigt
-
Dennis89 -
30. Juli 2021 um 15:02 -
Erledigt
Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
-
-
Apache2 Reverse-Proxy: Übermittelte Webseite wird im Internet ohne Bilder angezeigt? Schau mal ob du hier fündig wirst!
-
Es geht nicht darum, ob Du es brauchst oder nicht brauchst. Es geht darum, dass es funktioniert, wenn man will bzw. wenn man sshd-Server und ssh-Client richtig konfiguriert, denn ich benutze ssh mit pubkey und ohne pubkey (d. h. nur mit Passwort), im WG-Tunnel.
Wie in #28 zu sehen wird im wg0 genattet. Das könnte die Probleme erklären.
Das Nat ist an der Stelle auch überflüssig da der Tunnel nur zwischen den zwei Hosts laufen soll. -
Wie in #28 zu sehen wird im wg0 genattet.
An welcher Stelle in #28 erkennst Du, dass im wg0 genattet wird?
-
An welcher Stelle in #28 erkennst Du, dass im wg0 genattet wird?
Hast recht, war nur ein Forward, kein Masquerade. Asche auf mein Haupt.
-
Ich meine zum Beispiel dieses Thema hier. Da wird auch empfohlen 'PasswordAuthentication no' zu setzen. Das habe ich wieder gemacht.
In dem Thema steht PermitEmptyPasswords. PasswordAuthentication ist für die Passwortabfrage, wenn du die am Server no setzt, kann es nicht gehen, da du ja noch keine Keys hast. Vergleiche nochmal die SSH-Konfigdateien, am Zero steht doch
Code
Alles anzeigen# The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 # # # # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes
-
Hallo und Danke für die Antworten.
Ich habe beide Dateien verglichen und habe auch 'PasswordAuthentication' in beiden Dateien wieder auf 'yes' gesetzt. Zur Sicherheit nicht nur den 'ssh.service' neugestartet sondern den Pi und den VServer. Das Ergebnis ist unverändert.
Ich habe hier die sshd_conf des Servers:
Code
Alles anzeigendennis@localhost:~$ cat /etc/ssh/sshd_config # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. Include /etc/ssh/sshd_config.d/*.conf #Port 51820 #AddressFamily any #ListenAddress 192.168.200.1 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes # Expect .ssh/authorized_keys2 to be disregarded by default in future. #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes GatewayPorts yes X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes PrintMotd no #PrintLastLog yes #TCPKeepAlive yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # Allow client to pass locale environment variables AcceptEnv LANG LC_* # override default of no subsystems Subsystem sftp /usr/lib/openssh/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server
und hier die des Pis:
Code
Alles anzeigenSpike@raspberrypi:~ $ cat /etc/ssh/sshd_config # $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 PubkeyAuthentication yes # Expect .ssh/authorized_keys2 to be disregarded by default in future. #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes PrintMotd no #PrintLastLog yes #TCPKeepAlive yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # Allow client to pass locale environment variables AcceptEnv LANG LC_* # override default of no subsystems Subsystem sftp /usr/lib/openssh/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server
Die Datei unterscheidet sich zwar durch Include /etc/ssh/sshd_config.d/*.conf aber 'sshd_config.d' ist leer:
Codedennis@localhost:/etc/ssh/sshd_config.d$ ls -la total 8 drwxr-xr-x 2 root root 4096 Feb 26 2020 . drwxr-xr-x 4 root root 4096 Aug 3 15:32 .. dennis@localhost:/etc/ssh/sshd_config.d$
Auf dem Pi besteht der Ordner gar nicht.
Dann gibt es noch die ssh_config, die sieht auf dem Server und dem Pi gleich aus. Dort hat man eine Option die sich 'Tunnel' nennt, aber da beide Dateien gleich sind, wird man da nicht rumschrauben müssen?
wenn man sshd-Server und ssh-Client richtig konfiguriert
Das ist für mich leider sehr schwierig, weil ich mit meinem beschränkten Wissen in diesem Gebiet der Meinung bin, dass das soweit hinhaut.
Danke und Grüße
Dennis
-
Hallo zusammen,
ich habe es geschafft
Also das Problem um das es eigentlich ging, war ja dass die Grafana-Panels nicht auf meiner Webseite angezeigt wurden, wenn ich diese über den VServer aufrufe. Dann kam das Problem, dass die Bilder auch nicht angezeigt wurden. Diese Probleme sind jetzt gelöst. Das Problem mit der SSH-Verbindung besteht zwar noch, diese benötige ich aber nicht.
Was ich gemacht hab:
Raspberry PI Zero:
Hier liegt meine Webseite. Diese beinhaltet Bilder und Grafana-Panels.
Hier ist es wichtig, dass bei den Bildern der Pfad mit angegeben wird. Aber nicht der Ordner in dem sie liegen, sondern die IP-Adresse des Pi's:
Code<div id="hello"> <img id="welcome" src="http://192.168.0.216/welcome.png" alt="Begrüßung"> </div>
Für das Grafana-Panel sieht das so aus:
Code<iframe id="temperature" src="http://192.168.0.216:3000/d-solo/qbD3cJRgk/temperatur?orgId=1&refresh=1m&theme=light&panelId=4" frameborder="0"></iframe>
In /etc/wireguard/ liegt die wg0.conf mit diesem Inhalt:
CodePrivateKey = PRIVATE KEY VOM PI Address = 192.168.200.2/32 DNS = 1.1.1.1 [Peer] PublicKey = PUPLICKEY VOM SERVER Endpoint = SERVER IP:51820 AllowedIPs = 192.168.200.0/24 PersistentKeepalive = 30
Diese mit wg-quick up wg0 aktivieren.
Auf dem VServer Apache2 und WireGuard installiert.
In /etc/wireguard/ liegt die wg0.conf mit diesem Inhalt:
Code
Alles anzeigen[Interface] Address = 192.168.200.1/24 ListenPort = 51820 PrivateKey = PRIVATEKEY SERVER PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; # Client1 [Peer] PublicKey = PUPLICKEY PI AllowedIPs = 192.168.200.2/32
Diese mit wg-quick up wg0 aktivieren.
Port 51820 UDP freigeben.
Datei /etc/apache2/sites-available/rproxy.conf mit folgendem Inhalt erstellen:
Code<VirtualHost *:80> ProxyPreserveHost On ProxyPass / http://192.168.200.2/ ProxyPassReverse / http://192.168.200.2/ </VirtualHost>
Danach folgende Befehle ausführen:
a2dissite 000-default
a2ensite rproxy
a2enmod proxy
a2enmod proxy_http
systemctl restart apache2
Das wars eigentlich
Wenn ich das so sehe, eigentlich erschreckend wie viel Zeit das in Anspruch genommen hat. (Ich hoffe ich habe nichts vergessen).
Ich möchte mich bei ALLEN BEDANKEN die mir bei diesem Projekt geholfen haben!
Das war sehr lehrreich für mich, auch wenn ich das ein oder andere graue Haar entdeckt habe
Schönes Wochenende
Dennis
-
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o &i -j ACCEPT;
Typo: %i
-
Danke @Ilutz, habe es verbessert.
Habe mich aber auch zu früh gefreut. Wenn ich die Seite mit dem Laptop(FireFox) aus dem gleichen W-lan wie dass das der Pi verwendet, aber über die IP des VServers aufrufe, funktioniert alles perfekt. Also mit http://VSERER-IP/PHP-DATEI.php
Gebe ich das auf einem Smartphone ein und nutze die mobilen Daten, dann zeigt mir Safari anstelle von Bildern weise Kästen an mit Aalternativtext. An der Stelle an der die Grafana-Panels sind, ist auf der Webseite gar nichts zu sehen.
Mit Chrome und Samsung-Internet werden immerhin ein paar Bilder angezeigt, aber die Grafana-Panels auch nicht.
Wenn ich mit den Smartphones wieder ins W-lan wechsle, dann wird die Seite perfekt angezeigt.
Heute Mittag kann ich das mal noch aus einem "fremden" W-lan testen.
Kann sich das unterschiedliche Verhalten jemand erklären?
Danke und Grüße
Dennis
-
Innerhalb von deinem Heimnetzwerk (und WLAN) kannst du die 192.168.0.216 erreichen. Von außerhalb deines Heimnetzwerkes geht es nicht. Denn der Webbrowser von den Clients versucht diese private IP-Adresse zu erreichen. Dir ist das einmal selbst aufgefallen, dass auch der VPS deine 192.168.0.216 gar nicht erreichen kann.
Hast du dir mal die Seite angesehen?
-
Hallo und Danke für deine Antwort.
Ich glaube du hast mich falsch verstanden. Das ich '192.168.0.216' nur innerhalb des Heimnetzwerks erreichen kann ist mir klar. Aber diese IP-Adresse habe ich gar nicht benutzt. Also ich nutzte jetzt nur noch die IP des VServers, auch wenn ich mich im Heimnetzwerk befinde. Da sollten die Daten doch den selben "Weg" nehmen, wie wenn ich aus einem anderen Netzwerk oder mit den mobilen Daten über die IP-Adresse des VServers versuche die Webseite aufzurufen?
Gerade habe ich es mit der W-lan Verbindung aus einem anderen Netzwerk getestet. Dabei werden die Panels und ein Bild nicht angezeigt, andere Bilder werden aber angezeigt, welche mit Zugriff aus den mobilen Daten nicht angezeigt werden. Also ein ganz unterschiedliches Verhalten.
Für mein Verständnis: Macht es einen Unterschied von wo aus ich die Webseite über die IP des VServers aufrufe? Ich dachte bis jetzt, dass das keinen Unterschied macht.
Danke für den Link, den schaue ich mir nachher mal genauers an
Grüße
Dennis
-
Wahrscheinlich sind die "funktionierenden Bilder" noch im Browser-Cache vorhanden. Bei deinem HTML-Code benutzt du die 192.168.0.216 für die Bilder. Das geht so nicht, weil die anderen Clients keinen Raspberry mit den Bildern unter der 192.168.0.216 in ihrem Netzwerk haben.
Nochmal deutlich: Die Adresse wird von jedem x-beliebigen Client = Webseitenbesucher direkt aufgerufen. Die Bilder gehen nicht durch den Reverse Proxy und auch nicht durchs VPN, sondern daran vorbei. Daher klappt es nur innerhalb von deinem Netzwerk.
-
Vielen Dank, da hatte ich den Denkfehler.
Jetzt verstehe ich, wieso das nur im Heimnetzwerk funktioniert.
Also muss ich die Adresse der Bilder ändern.
Durch mein Revers-Proxy ist es ja so, das wenn ich die VSERVER_IP/*.php aufrufe, wird die Anfrage durch den VPN-Tunnel an den Pi weitergeleitet, der Stellt die *.php-Datei bereit und der VServer gibt sie dann aus.
Meine Bilder liegen im gleichen Ordner wie meine PHP-Datei, dann war jetzt mein Gedanke, dass ich für die Adresse der Bilder, die IP des VServers verwende. Da der Link direkt aufgerufen wird, müsste dass dann doch auch wie beim Aufruf der PHP-Datei ablaufen?
Bei dem Versuch bekomme ich aber einen Error:
CodeProxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request Reason: Error reading from remote server
Muss ich da noch extra was konfigurieren, damit die Bilder auch umgeleitet werden? Ist da die Firewall mit im Spiel und blockiert irgendwie irgendwas?
Man oh man, das ist ja was
Vielen Dank und Grüße
Dennis
-
Wenn dein RPi Pakete zwischen den Netzen WG und Intern hin und her schieben soll, muss imho ip-forwarding auf dem RPi aktiv sein.
sysctl net.ipv4.ip_forward
Und was sagt ip r g 192.168.200.1 auf dem Rpi?
-
Vielleicht hilft dir dieser alte Beitrag noch weiter.
-
Danke für die Antworten.
sysctl net.ipv4.ip_forward
Das zeigt mir an, dass es deaktiviert ist. Mit ysctl -w net.ipv4.ip_forward=1 habe ich es aktiviert und dann den Pi neugestartet.
Als Adresse der Bilder habe ich bei einem die IP des VServers eingetragen. Das wird nicht angezeigt auch nicht im Heimnetzwerk.
Vielleicht hilft dir dieser alte Beitrag noch weiter.
Hier soll man die Datei 'httpd.conf' ändern. Die habe ich gar nicht auf dem VServer. Laut dieser Seite kann ich die Änderungen in die 'apache2.conf' schreiben. Das habe ich gemacht und den Apache danach neugestartet. Brachte leider keine Änderung.
In der error.logs vom VServer habe ich das gefunden:
Code[Sun Aug 08 16:21:58.028526 2021] [proxy_http:error] [pid 10448:tid 139940729956096] (70007)The timeout specified has expired: [client 37.201.7.84:12920] AH01102: error reading status line from remote server 192.168.200.2:80 [Sun Aug 08 16:21:58.028629 2021] [proxy:error] [pid 10448:tid 139940729956096] [client 37.201.7.84:12920] AH00898: Error reading from remote server returned by /Spike.png
In other_vhosts_access.log das:
Codelocalhost.localdomain:80 37.201.7.84 - - [08/Aug/2021:16:17:10 +0000] "GET /Schildis.php HTTP/1.1" 200 1275 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0" *VSERVER-DNS-NAME*:443 37.201.7.84 - - [08/Aug/2021:16:16:57 +0000] "GET /Spike.png HTTP/1.1" 502 5848 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0"
Grüße
Dennis
-
Mit sysctl -w net.ipv4.ip_forward=1 habe ich es aktiviert und dann den Pi neugestartet
.. und es damit wieder abgeschaltet. sysctl -w ist nicht persistent, ändere /etc/sysctl.conf bzw. lege ein *.conf file in /etc/sysctl.d/ dafür an.
-
Oh na toll, Danke.
Habe die '#' vor net.ipv4.ip_forward=1 entfernt. Den Pi neugestartet, dann nochmals geschaut ob sich die Datei geändert hat, der Eintrag hat sich nicht geändert. Am Verhalten der Webseite allerdings auch nichts.
Grüße
Dennis
-
Hallo,
ich melde mich nochmal zurück, da ich leider kein Stück weiter gekommen bin.
Ich muss doch irgendwie sagen können, dass der VServer die Bilder auf dem Pi findet.
Auf dem Pi hat die Apache2 000-default.conf den Eintrag:
DocumentRoot /media/website/
Gibt es für den VServer und dir rproxy.conf nicht eine ähnliche Option?
Danke und Grüße
Dennis
-
Gibt es für den VServer und dir rproxy.conf nicht eine ähnliche Option?
Wozu sollte das gut sein?
Der reverse-Proxy nimmt Anfragen (bei dir vom WAN) entgegen, leitet sie an den definierten Host (hier im LAN/VPN) weiter und sorgt dafür, dass dessen Anworten ans WAN ausgeliefert werden.
Verkürzt: Da gibt es kein DocumentRoot, weil der rproxy-vhost selbst keine Inhalte anbietet.
-
Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!