Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- it:server:http-reverzni-proxy-server [2023/01/16 12:42] – Petr Nosek
+++ it:server:http-reverzni-proxy-server [2024/01/03 18:39] (aktuální) – [problém] Petr Nosek
@@ Řádek 13: / Řádek 13: @@
 <code bash>
-sudo a2enmod proxy proxy_http proxy_balancer lbmethod_byrequests rewrite
+sudo a2enmod proxy proxy_http proxy_balancer lbmethod_byrequests rewrite headers
 sudo systemctl restart apache2
 </code>
@@ Řádek 75: / Řádek 75: @@
-==== problém ====
+==== problém - Lost Connection.. ====
 Problém byl, že u Node REDu apache nefungoval jak má. Po chvíli Node RED vypisoval hlášení: "Lost connection..". Hledal jsem v [[https://discourse.nodered.org/t/node-red-shows-lost-connection-to-server-reconnecting-beacuse-of-websocket-connection-to-wss-comms-api-failed/61220/4|diskusích]] a nenašel jsem uspokojivé řešení, které by fungovalo. Nakonec jsem na podnět v diskusích přešel na nginx - ten byl skutečně řešením.
@@ Řádek 143: / Řádek 143: @@
 </code>
+**Bohužel jsem zjistil, že konfigurace nebyla dostačující.** Webové rozhraní fungovalo, ale když jsem se snažil použít klienta na automatickou synchronizaci, tak klient měl problém s https protokolem. Prozatím jsem hledání řešení vzdal, protože jsem ani po několika hodinách nebyl úspěšný.
 ==== PiHole ====
@@ Řádek 153: / Řádek 155: @@
+Stejně služba nefungovala jak má, protože se mi nevypisovala uložená data. Pak jsem narazil na tuto diskusi s řešením: https://www.reddit.com/r/Actualfixes/comments/ulzrbj/fix_pihole_behind_proxy_error_invalid_json/
+Řešení popisuje, že je potřeba přizpůsobit nastavení lighttpd v docker kontejneru. V docker konterjneru přidat do souboru ///etc/lightttpd/external.conf// tento řádek (nastavit tam IP adresu serveru):
+<code>
+setenv.add-environment = ( "VIRTUAL_HOST" => "<your-domain>" )
+</code>
+Řešení bude funkční pouze do chvíle aktualizaci kontejneru. Proto jsem do docker compose souboru přidal tento řádek:
+<code>
+volumes:
+  - /mojecesta/external.conf:/etc/lighttpd/external.conf
+</code>
+Nejprve ale bylo potřeba na disku vytvořit soubor /mojecesta/external.conf jinak se mi nepodařilo kontejner spustit.
+Pak jsem ale našel lepší řešení v [[https://github.com/pi-hole/docker-pi-hole#environment-variables|dokumentaci docker Pi Hole kontejneru]]. Výsledná konfigurace pro docker-compose pak vypadá takto:
+<code yaml>
+pihole:
+  container_name: pihole
+  image: pihole/pihole:latest
+  ports:
+  - "8089:80/tcp"
+  - "53:53/tcp"
+  - "53:53/udp"
+  - "67:67/udp"
+  environment:
+  - TZ=Etc/UTC
+  - WEBPASSWORD=supertajneheslo
+  - INTERFACE=eth0
+  - VIRTUAL_HOST=192.168.1.20
+  volumes:
+  - ./volumes/pihole/etc-pihole:/etc/pihole
+  - ./volumes/pihole/etc-dnsmasq.d:/etc/dnsmasq.d
+    #- ./volumes/pihole/external.conf:/etc/lighttpd/external.conf
+  dns:
+  - 127.0.0.1
+  - 1.1.1.1
+  cap_add:
+  - NET_ADMIN
+  restart: unless-stopped
+</code>
+V závěru jsem objevil ještě jeden problém. Pi Hole po přihlášení přesměrovává na IP_ADRESA_SERVER/admin . Takže po přihlášení do Pi Hole jsem přesměrován mimo reverzní proxy. Nakonec jsem to vyřešil tak, že jsem Pi Hole spustil na IP_ADRESA_SERVER/admin namísto /pihole. Funkční konfigurace Apache pak vypadá takto:
+<code>
+RewriteRule ^(.*)/pihole/$ $1/admin/ [R]
+ProxyPass /admin/ http://localhost:8089/admin/
+ProxyPassReverse /admin/ http://localhost:8089/admin/
+</code>
+Setkal jsem se s problémem, když jsem pihole nemohl nastartovat, protože port 53 byl obsazený již nějakou jinou službou. V mém případě to byl connect manager. Pomohla editace souboru **/etc/connman.prefs** (v distribuci OSMC je soubor tady **/etc/osmc/prefs.d/connman**) a nastavit:
+<code>
+dnsproxy=no
+</code>
+A pak restartovat connection managera:
+<code bash>
+systemctl restart connman
+</code>
+Další tipy k samotnému Pi Hole:
+{{youtube>62j2UB3No3E?}}
+A tady odkaz na servery s blocklisty:
+  * https://avoidthehack.com/best-pihole-blocklists
+  * https://firebog.net/
 ===== Nginx =====
@@ Řádek 255: / Řádek 333: @@
 </code>
-===== limit, který jsem nevyřešil =====
-Pokud máme doménu, tak je to všechno v pořádku. Každou službu můžeme zařadit pod subdoménu. V mém případě tedy Node RED běží pod doménou garmin.cn a portainer pod portainer.garmin.cn.
-Problém ovšem nastává, když jsem v lokální síti a nevyužívám lokální [[it:iot:hodinky-garmin-api-call|dns]]. V tu chvíli chci volat pouze IP adresu a za ni lomítkem určit službu. Tedy například: 192.168.1.20/portainer. A to se mi právě nepodařilo vyřešit.
-Jedna služba přes reverzní proxy obsadí IP adresu: 192.168.1.20 a už není možné pracovat se složkama alá 192.168.1.20/portainer, protože to už se snaží obsluhovat Node RED.