Dotaz: Jak funguje https přes reverse proxy server?

[HUGO]

Zdravim. Mam stroj (s názvem třeba AAA) ktery podle nazvu domeny posila pozadavky na jine stroje. Http funguje naprosto v poradku ale https ne. Pokud ze stroje AAA posilam https pozadavek na BBB, na kterem stroji ma byt nainstalovany ssl certifikat pro tu danou domenu? Na stroji AAA nebo na stroji BBB? Nebo snad na obou? To neumí proxy predat jen tak, aby se certifikat overoval az na koncovem stroji?

Když zadám požadavek do prohlizece a nez se to dostane na pozadovany stroj tak to projde pres desitky stroju a taky na kazdem neni nainstalovany pozadovany certifikat.

Jak to tedy je? Ví někdo? Díky.

---

---

Odpovědi

[Jendа]

Když zadám požadavek do prohlizece a nez se to dostane na pozadovany stroj tak to projde pres desitky stroju a taky na kazdem neni nainstalovany pozadovany certifikat.

Jenže ty stroje, přes které to prochází, se nazývají routery, a operují na L3. Proxy operuje na L7.

A k řešení dotazu: záleží, jestli ti stačí spojení přepojit na správný stroj, pak proxy dešifrování provádět nebude a jenom se koukne na SNI hlavičku, nebo chceš dělat něco složitějšího, pak je potřeba TLS spojení terminovat na proxy (a pokud je síť za ní důvěryhodná, tak se naopak neprovozuje TLS na koncovém webserveru).

[HUGO]

záleží, jestli ti stačí spojení přepojit na správný stroj

Ano, myslim, ze to by mi stacilo a certifikat bych nainstaloval jen na cilovem stroji. Poradis jak toho docílit?

[HUGO]

Instalaci certifikatu nepotrebuji a proxy bezi na Apache2. Děkuji

[Jendа]

Na Apache nevím, ale třetí odkaz z gůglu ukazuje jak to udělat u jiných proxy.

[HUGO]

Tak to uz je na me moc vysoka divci. Zkusim neco pohledat a treba nekdo jeste poradi. Zatim diky.

PS: a pres proxy muzu prohnat i port 22?

[Jendа]

PS: a pres proxy muzu prohnat i port 22?

Ne, SSH neposílá žádné informace, kvůli kterým by dávalo použití proxy smysl.

[Jendа]

PS: a pres proxy muzu prohnat i port 22?

(jak by sis představoval že bude vypadat výsledek/čeho tím chceš dosáhnout?)

[Peter Golis]

PS: a pres proxy muzu prohnat i port 22?

Áno, môžeš. Ale nie som si istý či naozaj chceš ssh over http proxy a nie klasický PAT.

[Josef Kufner]

PS: a pres proxy muzu prohnat i port 22?

SSH a HTTPS si spolu nerozumí, ale existuje například sslh, které podle začátku protokolu detekuje, co to je zač a pošle to odpovídající službě na jiný port. Nevýhoda je, že cílová služba nevidí vzdálenou IP adresu, což u může vadit (logy, zabezpečení).

[Semo]

Na strankach sslh je pomerne dlhy navod ako rozchodit s pomocou lokalneho fw forwardovanie spojeni so zachovanim source-IP, ale osobne som to neskusal.

[pc2005]

Pokud se chceš z jednoho stroje připojit na jiný v síti, které na sebe přímo nevidí, ale mají jeden společný uzel. Tak můžeš použít ssh ProxyJump (volba -J). Je ale jen na novějších verzích ssh (která musí být na každém hopu).

[HUGO]

Samozrejme neni problem nahradit apache nginx-em, pokud by to bylo lepsi nebo vhodnejsi, http me uz dneska vubec nezajima, jde mi jen o https.

[MMMMMMMMM]

Já používám jako reverzní proxy nginx, s HTTPS nemá problém. Inspirace např. https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-with-ssl-as-a-reverse-proxy-for-jenkins

[HUGO]

Problém je, že musíš řešit všechny certifikáty u všech domén přímo na proxy serveru. Něco bez certifikátů nemáš? Nemůžu nic najít :(

[MP]

HAProxy s TCP proxy. Ale ma to sva negativa, ktere se te tykat nemusi.

[HUGO]

Díky, tohle řešení nechci. Jinak opravdu nikdo neporadí? Aspoň co mám přesně hledat, nějaké klíčová slova pro goole. Návodů jsem našel spousty ale všechny jsou s ssl certifikátem přímo v tom proxyserveru.

[Filip Jirsák]

Když bude certifikát na tom proxy serveru, je to HTTP/HTTPS reverzní proxy. Když má být až na cílovém serveru, je to TCP proxy (umí to třeba nginx nebo HAProxy) a nebo prostě jen přesměrování portu (DNAT). Mezi nimi je ještě drobný rozdíl, ale pro to, co jste zatím popsal, není důležitý – TCP proxy proxy funguje tak, že TCP spojení je zakončené na proxy serveru, odkud je navázáno nové spojení k cílovému serveru, a data se mezi těmito spojeními kopírují. DNAT funguje tak, že se modifikují přímo procházející pakety, takže paket od klienta, i když pozměněný, dorazí až k cílovému serveru.

[HUGO]

To si ale protiřečíš, psal jsi, že:

Když bude certifikát na tom proxy serveru, je to HTTP/HTTPS reverzní proxy.

Když má být až na cílovém serveru, je to TCP proxy

uvedl jsi tedy dvě možnosti

TCP proxy proxy funguje tak, že TCP spojení je zakončené na proxy serveru

a teď z té druhé možnosti děláš zase tu první, tak jak to tedy je? ;)

[Filip Jirsák]

Uvedl jsem dvě možnosti – HTTP/HTTPS reverzní proxy server, který rozumí protokolu HTTP a pro jiný protokol nejde použít, a TCP proxy, která pracuje na nižší vrstvě a aplikační protokol ji vůbec nezajímá. A funkci TCP proxy je možné realizovat dvěma způsoby, jedním je skutečný proxy server, ve kterém je spojení zakončeno a on navazuje spojení nové, nebo lze jednoduchou TCP proxy realizovat i jen s pomocí DNATu.

[HUGO]

Čili mám nainstalovat Nginx a z něj udělat proxy server? To už jsem ale dělal, tady je konfigurace, stejně to nefunguje, co je špatně?

server {
  listen 443;
  server_name www.domena1.net;

  location / {
    proxy_pass              https://192.168.1.101;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout   150;
    proxy_send_timeout      100;
    proxy_read_timeout      100;
    proxy_buffers           4 32k;
    client_max_body_size    8m;
    client_body_buffer_size 128k;
  }
}


server {
  listen 443;
  server_name www.domena2.net;

  location / {
    proxy_pass              https://192.168.1.102;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout   150;
    proxy_send_timeout      100;
    proxy_read_timeout      100;
    proxy_buffers           4 32k;
    client_max_body_size    8m;
    client_body_buffer_size 128k;
  }
}

[Filip Jirsák]

Tohle je konfigurace, kdy nginx naslouchá na portu 443, ale očekává tam HTTP spojení, ne HTTPS. Fungovalo by vám to, ale musel byste do prohlížeče zadat adresu http://www.domena1.net:443. To ale asi nechcete.

Klasická konfigurace je, že byste měl SSL zakončené na nginxu, tím pádem musí mít Nginx serverové certifikáty s privátním klíčem. Tj. za listen 443 by muselo být ssl a musela by tam být konfigurace certifikátů, případně další konfigurace SSL:

server {
    listen              443 ssl;
    server_name www.domena1.net;
    ssl_certificate     www.domena1.net.crt;
    ssl_certificate_key www.domena1.net.key;
    …
}

Vy asi chcete TCP proxy, tj. SSL zakončené až na cílovém serveru. Pak moc nevidím důvod mít tam v roli TCP proxy HTTP(S) server, protože dovnitř SSL spojení neuvidí, jenom si z SNI na začátku spojení přečte, kam má to spojení předat. Ale nginx umí i tohle, příklad konfigurace je v Module ngx_stream_ssl_preread_module. Ale já jsem nginx jako TCP proxy nikdy nepoužíval, takže víc než tenhle odkaz a odkaz na dokumentaci TCP/UDP proxy nginxu vám asi neporadím.

[HUGO]

Vy asi chcete SSL zakončené až na cílovém serveru.

Ano

Pak moc nevidím důvod mít tam v roli TCP proxy HTTP(S) server, protože dovnitř SSL spojení neuvidí, jenom si z SNI na začátku spojení přečte, kam má to spojení předat.

Tak pokud není důvod mít tam v roli TCP proxy HTTP(S) server, tak jak to udělat?

A co třeba spustit nějaký DNS server, ten by neuměl podle názvu domény poslat všechny požadavky https a https na příslušnou vnitřní IP adresu?

[V.]

Co vlastně řešíte? Potřebujete někde v LANce nasdílet data? Dyť to nemusí jít přes "proxz server", dá se to jen routovat.
Tj. = internet = router = https server.
A hele, povolit abclinuxu.cz i google.com pro captchu ...

[HUGO]

Přes router by to šlo jen za předpokladu, že by každá doména jela na jiném portu a já porty potřebuji mít pro všechny domény stejné jak pro 80 tak i 443.

[V.]

A) Kde se řeší nějaká logika, na vstupu do sítě z internetu nebo jinde?
B) jak moc jsou kolizní relace fqdnX a ipadresaX?
C) Přeposílání http provozu se dělá něčím, co tomu rozumí, pokud chcete odlišit cílové fqdn a ip.
D) Opravdu se to dneska (doufám pořád ještě) dělá tak, že z internetu se jde na balancer a není vidět vnitřní struktura. A https je zakončeno na prvním inteligentním hopu mezi internetem a vnitřní sítí.

[vencour]

Jinak pokud tohle řešíte v práci a obcházíte "nějaký aktuální stav", tak je to na "závažné porušení Zákoníku práce", už vzhledem k GDPR.
Jo, klidně si mlžte, proč to vlastně chcete.

[Filip Jirsák]

tak je to na "závažné porušení Zákoníku práce", už vzhledem k GDPR.

GDPR nemá se zákoníkem práce nic společného, týká se ochrany osobních údajů. A je účinné až od 25. května 2018.

[vencour]

Ok, téma "hrubé porušení pracovní kázně", i neúmyslné nasdílení firemních dat apod.
Stačí?

[HUGO]

A co má společného GDPR s předáním http či https požadavků ?

[vencour]

Cílem GDPR je mít vše "zajímavé" pod kontrolou. Mít o tom přehled, znát flow.
Když si tam uděláte nějakou vlastní cestu mimo oficiální kanály, asi vás nebudou mít rádi. A pokud by vznikla okolo GDPR nějaká panika, tak je lepší neprovokovat žádnou partyzánštinou.

[HUGO]

Když si tam uděláte nějakou vlastní cestu mimo oficiální kanály, asi vás nebudou mít rádi.

Tak že použití proxy serveru se jedná o neoficiální kanál?

[vencour]

Měl by mít nějakou autorizovanou správu, přeposílat logy na centrální syslog a být jedinečný v rámci firmy.
Co mne napadá v první řadě.

[DarkKnight]

A co to ma spolecneho s pouzitim HTTP proxy serveru pro prichozi traffic?

[vencour]

Konkrétně aspoň něco bude vidět v logu.

[Filip Jirsák]

Tak pokud není důvod mít tam v roli TCP proxy HTTP(S) server, tak jak to udělat?

Stačilo by použít nějaký TCP proxy server, který umí směrovat podle SNI. Ale pokud tam chcete přesměrovávat i HTTP, stejně tam potřebujete použít HTTP proxy server, takže pak je nginx dobrá volba.

A co třeba spustit nějaký DNS server, ten by neuměl podle názvu domény poslat všechny požadavky https a https na příslušnou vnitřní IP adresu?

DNS žádné HTTP a HTTPS požadavky nikam neposílá. DNS jenom přeloží název na IP adresu.

Nejlepší by bylo, kdybyste napsal, jaký problém řešíte. Takhle se jen pokoušíme trefit do nějaké vaší představy o řešení.

[HUGO]

Nejlepší by bylo, kdybyste napsal, jaký problém řešíte. Takhle se jen pokoušíme trefit do nějaké vaší představy o řešení.

Řeším stále ten stejný problém. Mám nainstalovaný na serveru proxmox a v něm několik virtuální serverů (VM-100, VM-101, VM-102 atd..) a každou doménu chci nasměrovat na samostatný virtuální server tak, aby se vyžadovaly SSL certifikáty až na cílových virtuálních strojích a taky aby byly v každém log ip adresa uživatele který přišel na stránky, ne ip adresa proxy serveru. To je všechno.

[vencour]

Ok, kolik funkčních IP adres na interfejsech má samotný proxmox? Jakou bránu (gateway) mají ty virtuály? Přes co všechno chodí provoz do toho proxmoxu? Mají ty virtuály něco společného nebo jsou navzájem nezávislé? Maj ty domény něco společného, každá jedna jednotlivě?
Kdybych měl na hypervizoru bridge a ve virtuálu web sevrery, tak můžu pustit provoz přímo. Takže proč Vám tohle nevyhovuje?

[vencour]

Mimochodem co to máte za certifikáty a domény, že http jde a https nejde? Jste si jist, že máte dobře konfiguraci cílových web serverů?

[HUGO]

kolik funkčních IP adres na interfejsech má samotný proxmox?

Všechny domény jsou nasměrovány na jedinou IP adresu.

Jakou bránu (gateway) mají ty virtuály?

IP adresu přiděluje DHCP server podle MAC adresy toho virtuálu (Address Reservation)

Přes co všechno chodí provoz do toho proxmoxu?

Nerozumím otázce

Mají ty virtuály něco společného nebo jsou navzájem nezávislé?

Co například můžou mít společné?

Maj ty domény něco společného, každá jedna jednotlivě

Co například můžou mít společné?

Kdybych měl na hypervizoru bridge a ve virtuálu web sevrery, tak můžu pustit provoz přímo. Takže proč Vám tohle nevyhovuje?

A "kdo/co" by se v takovém případě staralo o to na jaky server poslat požadovanou doménu?

[vencour]

To byly otázky na ověření toho, co chcete udělat, zda to dává smysl.

[Filip Jirsák]

Třeba to o těch IP adresách klientů jste teď napsal poprvé, pokud vím.

Tohle má jedno jednoduché řešení – doménové záznamy nasměrovat přímo na IP adresy těch virtuálních strojů. Proxy server totiž zakončí TCP/IP spojení od klienta a k cílovém serveru naváže nové spojení, cílový server tedy vidí IP adresu proxy serveru. Normálně se to řeší tak, že proxy server přidá IP adresu klienta do HTTP komunikace jako další hlavičku, což ale v tomto případě nejde, když chcete SSL spojení předávat beze změny až na cílový server. Všechno se bude normálně routovat, nepotřebujete žádný proxy server, bude to velmi jednoduché. Akorát potřebujete dostatek veřejných IP adres – ale nic o jejich nedostatku jste nepsal.

Pak je tu druhá možnost, použít předávání IP adresy klienta zvláštním protokolem (Proxy Protocol), který původně vznikl pro HAproxy. To ovšem musí podporovat i cílový HTTP(S) server. A jako proxy samozřejmě musíte použít něco, co ten Proxy Protocol umí – např. právě HAproxy (nginx jako klient to pokud vím nepodporuje).

[Filip Jirsák]

Mimochodem, SSL certifikáty až na cílových virtuálních strojích i v každém log ip adresa uživatele opět není popis problému, ale řešení. Nevíme, proč chcete SSL certifikáty až na cílových strojích – možná je ten požadavek úplně zbytečný a jen to celé komplikuje. Mimochodem, před pár lety by to bylo úplně neřešitelné, protože šifrovaná komunikace je šifrovaná proto, aby nikdo neviděl přenášený obsah, takže byste z venku prostě nezjistil, které doménové jméno je v tom HTTPS požadované. Až před pár lety se udělal ústupek kvůli nedostatku IPv4 adres, a požadované doménové jméno se začalo přidávat do HTTPS i v nešifrované podobě (SNI). Pořád to ale nemusí podporovat všichni klienti, takže pokud byste k těm virtuálním serverům přistupoval pomocí nějakých HTTPS klientů nepodporujících SNI, stejně vám nezbyde nic jiného, než mít každý server na jiné IP adrese. Jenže to je právě ten problém, že pořád nevíme, co řešíte – místo abyste popsal svůj problém, pořád jenom dáváte návrhy na řešení.

[HUGO]

A pokud tedy nastavím SSl certifikáty přímo v tom proxy serveru a dál bude komunikace na cílový server nešifrovaná, zjistím na tomto koncovém stroji, jaký přesně název domény uživatel zadal nebo to nezjistím? Ptám se z důvodu toho, zda na cílovém stroji můžu použít v Apache konfiguraci VirtualDocumentRoot, zda bude podle čeho rozlišit jednotlivé požadavky?

[Filip Jirsák]

Zjistíte to, přesný název domény posílá prohlížeč v hlavičce Host (dříve to také nebylo pravidlo, ale to platilo tak před dvaceti roky) a proxy server tu hlavičku nijak nemění a pošle jí dál. Pokud byste chtěl, ani komunikace mezi proxy serverem a cílovým serverem nemusí být nešifrovaná, proxy server se k cílovému serveru může připojit také přes HTTPS.

[HUGO]

Super, a co ty IP adresy v logu? Co je potřeba nastavit aby tam byly IP adresy uživatelů a ne IP adresy toho proxy serveru?

[Filip Jirsák]

Tohle si nastavíte v konfiguraci serveru pro HTTP:

proxy_set_header        Host                    $http_host;
proxy_set_header        X-Real-IP               $remote_addr;
proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
proxy_set_header	X-Forwarded-Port	80
proxy_set_header	X-Forwarded-Proto	http

A tohle pro HTTPS server:

proxy_set_header        Host                    $http_host;
proxy_set_header        X-Real-IP               $remote_addr;
proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
proxy_set_header	X-Forwarded-Port	443
proxy_set_header	X-Forwarded-Proto	https

Nginx tak předá informace o původním spojení (IP adresa klienta, port, protokol, požadované hostname) do HTTP hlaviček, odkud si je cílový server převezme. Cílový server k tomu musí být nakonfigurován, aby ty hlavičky neakceptoval od každého klienta, ale jenom od konkrétního proxy serveru. Např. Apache pro to má mod_remoteip, Nginx má modul ngx_http_realip_module.

[HUGO]

Tak jsem to všechno rozjel, ale ty IP adresy prostě nechodí, sedím u toho nonstop 24 hodin ale nejde to. Můžeš mi prosím ještě poradit jak přesně nastavit ten Apache (mod_remoteip)? Zkusil jsem snad všechno možné a nic. Nevím zda mám použít i RemoteIPProxyProtocolExceptions, jelikož ten je platný až od verze 2.4.31 a já mám 2.4.18 a netuším jak nainstalovat do debianu 9 tak novou verzi apache :(

[HUGO]

EDIT

Mám verzi 2.4.25, ne 2.4.18.

[Filip Jirsák]

Podle mne by mělo stačit nastavit

RemoteIPHeader X-Real-IP
RemoteIPInternalProxy X.X.X.X

kde za X.X.X.X dosadíte IP adresu toho nginx serveru tak, jak ji vidí Apache.

[HUGO]

Tak taky ne, v logu je stále jen jedna IP (proxy server).

Nastavení Nginx

server {
	listen 443 ssl;
	server_name example.com;

	ssl_certificate /example.com.pem;
	ssl_certificate_key /example.com.key.pem;

	location / {
		proxy_pass		http://192.168.0.101;

		proxy_set_header	Host			$http_host;
		proxy_set_header	X-Real-IP		$remote_addr;
		proxy_set_header	X-Forwarded-For		$proxy_add_x_forwarded_for;
		proxy_set_header	X-Forwarded-Port	80;
		proxy_set_header	X-Forwarded-Proto	https;

		proxy_connect_timeout	150;
		proxy_send_timeout	100;
		proxy_read_timeout	100;
		proxy_buffers		4	32k;
		client_max_body_size	8m;
		client_body_buffer_size	128k;
	}
}

Nastavení Apache

<VirtualHost *:80>
    ServerName example.com
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    
    RemoteIPHeader X-Real-IP
    RemoteIPInternalProxy 192.168.0.99
    
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Modul remoteip jsem povolil

a2enmod remoteip

Apache jsem restartoval

systemctl restart apache2

Soubor access.log

192.168.0.99 - - [08/Apr/2018:01:27:06 +0200] "GET / HTTP/1.0" 200 260 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0"
192.168.0.99 - - [08/Apr/2018:01:27:14 +0200] "GET / HTTP/1.0" 200 262 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0"
192.168.0.99 - - [08/Apr/2018:01:29:05 +0200] "GET / HTTP/1.0" 304 142 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0"

[Filip Jirsák]

Nakonfigurujte si combined formát logu, aby se místo hostname logovala hlavička X-Real-IP:

LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

[HUGO]

Tak tohle jediný nefunguje

LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

ale tohle ano

LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" warn

LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" info

LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" notice

LogFormat "%{X-Real-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" debug

Mám tedy nechat něco jiného než combined?

BTW: a to co tady psal uživatel vencour o GDPR, můžu takovou konfiguraci ve finále legálně používat nebo ne? Nerad bych se dostal do nějakých problémů.

[vencour]

Ad GDPR byste měl být identifikovaný, částí flow zajímavých dat.
První věc, co hledá auditor, je nějaká dokumentace a soulad s realitou.
Pokud nezpracováváte a neukládáte osobní data, jste nezajímavý pro GDPR.
Omloubám se za pozdní odpověď.

[Filip Jirsák]

Ten druhý parametr pojmenovává příslušný formát logovaných záznamů, můžete si ho pojmenovat jak je libo, třeba bflmspvz.

S GDPR to nijak nesouvisí. Pokud to máte v nějaké síti, která vám nepatří (ve firemní, školní apod.), musíte se domluvit se správci té sítě, jestli něco takového můžete používat.

[HUGO]

OK, tím bych to asi uzavřel. Velmi děkuji za trpělivost a velkou pomoc. Nech se daří.

[Kkt1]

Kazda domena z tech x koncovych stroju ma svuj vlastni certifikat? Na proxy urcis jenom cestu a ssl ukoncis na koncovych strojich. Nebo to udelas tak ze ssl ukoncis na proxy a pak posilas na koncove stroje nesifrovany trafic. V cem je problem? Napsat konfiguraci? Pouzivas httpd nebo neco jineho?

[HUGO]

Kazda domena z tech x koncovych stroju ma svuj vlastni certifikat?

Ano

Na proxy urcis jenom cestu a ssl ukoncis na koncovych strojich.

Tuto variantu bych chtěl ale nevím jak.

Nebo to udelas tak ze ssl ukoncis na proxy a pak posilas na koncove stroje nesifrovany trafic.

Takto to nechci

V cem je problem? Napsat konfiguraci?

Ano, napsat konfiguraci

Pouzivas httpd nebo neco jineho?

Na tuto otázku nedokážu přesně odpovědět jelikož ji nerozumím:(

[HUGO]

Mám nainstalovaný Apache ale můžu doinstalovat i Nginx a Apache odstranit

[vencour]

Co přesně má být výsledkem?
Best practice je na reverzní proxy zakončit z internetu https a dotahovat do proxy z backendů obsah.

[HUGO]

Co přesně má být výsledkem?

Potřebuji aby proxy přesměrovalo https (podle nazvu domény) na danou IP adresu, ale bez toho, abych nemusel ssl certifikáty řešit v tom proxy ale až na cílovém stroji. Něco takového ale nefunguje to.

server {
  listen 443;
  server_name www.domena1.net;

  location / {
    proxy_pass              https://192.168.1.101;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout   150;
    proxy_send_timeout      100;
    proxy_read_timeout      100;
    proxy_buffers           4 32k;
    client_max_body_size    8m;
    client_body_buffer_size 128k;
  }
}


server {
  listen 443;
  server_name www.domena2.net;

  location / {
    proxy_pass              https://192.168.1.102;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout   150;
    proxy_send_timeout      100;
    proxy_read_timeout      100;
    proxy_buffers           4 32k;
    client_max_body_size    8m;
    client_body_buffer_size 128k;
  }
}

[Josef Kufner]

Tímhle právě zakončíš HTTPS. Mezi proxy a cílovým strojem máš druhé HTTPS, které s tím prvním od klienta nemá nic společného.

Pokud vím, nginx toto neumí, ale existuje nějaký 3rd-party modul – nezkoušel jsem ho. Zkus HAProxy, ta by to umět měla.

[vencour]

Na tohle - https://serverfault.com/questions/84821/apache-proxypass-with-ssl jste koukal?

[HUGO]

Ne, to jsem nenašel, hned na to jdu mrknout.

[HUGO]

Tak jsem do prázdné konfigurace vložil dvě domény

<VirtualHost *:443>
  ServerName www.domena1.net
  SSLProxyEngine On
  SSLProxyCheckPeerCN on
  SSLProxyCheckPeerExpire on
  ProxyPass / https://192.168.0.101
  ProxyPassReverse / https://192.168.0.101
</VirtualHost>

<VirtualHost *:443>
  ServerName www.domena2.net
  SSLProxyEngine On
  SSLProxyCheckPeerCN on
  SSLProxyCheckPeerExpire on
  ProxyPass / https://192.168.0.102
  ProxyPassReverse / https://192.168.0.102
</VirtualHost>

Ale Apache nejde restartovat, journalctl -xe vypíše

-- Unit apache2.service has failed.
--
-- The result is failed.
Mar 20 01:36:09 100 systemd[1]: apache2.service: Unit entered failed state.
Mar 20 01:36:09 100 systemd[1]: apache2.service: Failed with result 'exit-code'.
Mar 20 01:38:17 100 systemd[1]: Starting The Apache HTTP Server...
-- Subject: Unit apache2.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit apache2.service has begun starting up.
Mar 20 01:38:18 100 apachectl[1683]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 0.0.0.100. Set the 'ServerName' directive global
Mar 20 01:38:18 100 apachectl[1683]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
Mar 20 01:38:18 100 apachectl[1683]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
Mar 20 01:38:18 100 apachectl[1683]: no listening sockets available, shutting down
Mar 20 01:38:18 100 apachectl[1683]: AH00015: Unable to open logs
Mar 20 01:38:18 100 apachectl[1683]: Action 'start' failed.
Mar 20 01:38:18 100 apachectl[1683]: The Apache error log may have more information.
Mar 20 01:38:18 100 systemd[1]: apache2.service: Control process exited, code=exited status=1
Mar 20 01:38:18 100 systemd[1]: Failed to start The Apache HTTP Server.
-- Subject: Unit apache2.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit apache2.service has failed.
--
-- The result is failed.
Mar 20 01:38:18 100 systemd[1]: apache2.service: Unit entered failed state.
Mar 20 01:38:18 100 systemd[1]: apache2.service: Failed with result 'exit-code'.

Co je prosím špatně? Díky

[houska]

Mar 20 01:38:18 100 apachectl[1683]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
Mar 20 01:38:18 100 apachectl[1683]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443

Nemuze se pripojit na port 443 - uz na nem nejspis neco posloucha.