Dotaz: Přesměrování https na jiný stroj

[Milan Uhrák]

Dobrý den.

Pokouším se přesměrovat dotaz na jeden server ( viditelný zvenčí ) na jiný ( zvenčí nedostupný ) - je to vlastně virtuál v lokální síti.

http funguje bez problémů, toto mám na tom viditelném serveru :

<VirtualHost *:80>
   ServerAdmin webmaster@server.cz
   ServerAlias test.server.local
   ServerName test.server.cz

   ProxyPass / http://test.server2.local/
   ProxyPassReverse / http://test.server2.local/

</VirtualHost>

chtěl bych přesměrovat i https a ideálně volání z http přecvaknout na https. Ale ani obyčejné přesměrování se mi nedaří.

na virtuálu je tento virtualhost :

<IfDefine SSL>
<IfDefine !NOSSL>

<VirtualHost *:443>

	ServerName "test.server.cz"
	ServerAlias "test.server.local, test.server2.local "
	DocumentRoot "/srv/www/test"
	ErrorLog /var/log/apache2/ssl_test_error.log
	CustomLog /var/log/apache2/ssl_test_custom.log   ssl_combined
	LogLevel warn

	SSLEngine on
	SSLProtocol all -SSLv2 -SSLv3
	SSLCipherSuite ALL:!aNULL:!eNULL:!SSLv2:!LOW:!EXP:!MD5:@STRENGTH

	SSLCertificateFile /etc/apache2/ssl.crt/https_2018.crt
	SSLCertificateKeyFile /etc/apache2/ssl.key/https_2018.key
	SSLCACertificateFile /etc/apache2/ssl.crt/Servers.crt

	
        <Directory /srv/www/test>
        AllowOverride None
        Options +ExecCGI -Includes
        <IfModule !mod_access_compat.c>
            Require all granted
        </IfModule>
        <IfModule mod_access_compat.c>
            Order allow,deny
            Allow from all
        </IfModule>
        </Directory>



</VirtualHost>                                 

</IfDefine>
</IfDefine>

a z viditelného serveru se to pokouším přesměrovat podobně jako http provoz, ale nedaří se mi. různé návody, co jsem našel, nejsou úplně na stejný případ, a vždy se to někde sekne.

Když v LAN zavolám https://test.server2.local, tak mně prohlížeč pochopitelně seřve kvůli certifikátu, ale jinak to běží. Ale přesměrovat to nedokážu.

Děkuji předem za nějakou tu nápovědu Milan

---

---

Odpovědi

[Milan Uhrák]

Pokud se certifikát nelíbí tvému prohlížeči, asi se nebude líbit ani tomu přesměrovávajícímu proxy serveru a odmítne to předat dál.

[Milan Uhrák]

no právě ... certifikát na tom virtualhostu ( server2) je pro test.server ( lépe řečeno *.server.local a *.server.cz ) ne pro test.server2. Ale je vůbec možné to nějak přesměrovat ?

Například z https přesměrovat ( pomocí proxy ) na http toho vnitřního serveru ? Třeba takto :

<VirtualHost *:443>
   ServerAdmin webmaster@jednota.podborany.cz
   ServerAlias test.server.local
   ServerName test.server.cz

   ProxyPass / http://test.server2.local/
   ProxyPassReverse / http://test.server2.local/

   SSLEngine On
   SSLProtocol all -SSLv2 -SSLv3
   SSLCipherSuite ALL:!aNULL:!eNULL:!SSLv2:!LOW:!EXP:!MD5:@STRENGTH

   SSLCertificateFile /etc/apache2/ssl.crt/https_2018.crt
   SSLCertificateKeyFile /etc/apache2/ssl.key/https_2018.key
   SSLCACertificateFile /etc/apache2/ssl.crt/Servers.crt
...


</VirtualHost>

No pokládám otázku .. říkám si zkusím a ono to zevnitř nefunguje .. nevím proč, nahodí se mi server2 do adr. řádku, certifikát neplatí (viz výše), ale zvenčí jen upozornění, že vydavatel není znám ( samopodepsaný ) ...

Takže jak to vypadá, tohle je částečné řešení.

Uvědomuji si tu krkolomnost toho co dělám, žádám jeden secure server1 aby mi podal obsah z jiného secure serveru2, kde je cerifikát jen na ten server1...

Aby přesměrování vůbec fungovalo, musí mít ten druhý server i jiné doménové jméno, čímž se narušuje ten secure provoz .. no je to maglajz. Mohl bych na server2 dodělat certifikát, jen jsem nevěděl, zda tím jen nezkomplikuji celý problém ...

Děkuji za radu, která mně nasměrovala.

[Josef Kufner]

Asi to moc komplikuješ. Jsou to dvě samostatná spojení. Jedno jde zvenčí na veřejný proxy server, druhé jde z proxy serveru na vnitřní hostující server. Obě musí fungovat, aby to fungovalo celé. Třetí spojení může být z vnitřní sítě na vnitřní server.

V první řadě si sežeň důvěryhodný certifikát. Třeba od Let's Encrypt. Můžeš k tomu použít ten veřejný proxy server, aby se to umělo samo ověřit. Do Let's Encrypt klienta nastav hook, který po SSH zkopíruje aktualizovaný certifikát na druhý server (a reloadne web server).

Veřejný DNS záznam nastav tak, aby pro okolní svět ukazoval na proxy server. DNS server ve vnitřní síti pak může ukazovat rovnou na hostující server uvnitř sítě. Oba servery nastav tak, aby obsluhovaly ten jeden stejný název. Klienti venku tedy dostanou odpověď od jiného serveru než klienti uvnitř. Oba však uvidí validní HTTPS certifikáty a nebudou tušit nic podlého.

Pak už stačí jen nastavit to přesměrování stejně, jako to máš na prosté HTTP.

[majales]

Ahoj, a nechybí ti v konfiguraci na rproxy toto:

SSLProxyEngine On

samosebou musíš mít příslušné apache moduly pro proxy a SSL.

[Filip Jirsák]

Zajímavé :) Zatímco jsem ladil vzhled toho webu, asi se něco překonfigurovalo, a teď to funguje přesně jak jsem chtěl a dokonce i vnitřní přesměrování ( což je samozřejmě zbytečné ) začalo normálně fungovat. Tak nevím - asi jsem zanedbal cache nebo co.

Tím je problém vyřešen, a já všem děkuji za snahu, postřehy a rady které mně nakoply. Lets encrypt neřeším, je to web pro vnitřní potřebu zaměstnanců, navenek funguje jen pro možnost jejich přístupu k datům pokud jsou na cestách nebo doma. Náš certifikát povětšinou už mají jako důveryhodný ( obdoba toho webu tu běží už léta, ale nová verze žádá php7, tak jsem to zkusil takto obejít ). Bohužel, ten server tu běží už opravdu dlouho a na přeinstzalaci teď nemám sil. V důsledku prvotního návrhu jsem si nerozsekal jednotlivé služby na virtuály a tak teď to musím takto látat.

Díky moc Milan

[Filip Jirsák]

Ještě bych doplnil, že pokud ten Apache dělá jen reverzní proxy server, je to trochu kanón na vrabce. Nejčastěji se na tohle používá asi nginx (i když i ten pro tenhle případ toho umí zbytečně moc), případně HAproxy. Přesně pro tuhle vaší konfiguraci najdete pro nginx spoustu návodů. Apache to zvládne také, ale asi bude potřebovat víc zdrojů a nejspíš nezvládne tak silný provoz, jako nginx (což asi nemusíte řešit).

[Milan Uhrák]

Na tom serveru1 ( viditelném ) běží více virtualhostů, a ty se používají. Provoz tam není jako na soroznamu.cz, možná tak 5-6 připojení současně. Až dokončím migraci na normální stroj, prostě jen přesměruju porty. Jedna aplikace byla zoufale stará, aktualizace na původním serveru nemožná a tohle bylo (testované) řešení.

Co se týče provozu ( zátěže ), tak zrovna tohle přesměrování asi nebude nic extra, apač jen předává požadavky dále a přijaté data šifruje a posílá zpět. Nebo se pletu ?

[Filip Jirsák]

Co se týče provozu ( zátěže ), tak zrovna tohle přesměrování asi nebude nic extra, apač jen předává požadavky dále a přijaté data šifruje a posílá zpět. Nebo se pletu ?

Jenže na to „jen předání“ musíte mít celý proces Apache (resp. několik procesů), Apache ten požadavek zpracuje úplně stejně, jako kdyby ho měl následně předat třeba modulu pro PHP, a předá ho modulu pro reverzní proxy. Při nízkém provozu to není potřeba řešit, zvlášť pokud na tom Apache máte i jiné aplikace, které jsou pro Apache odladěné. Z toho původního dotazu nebylo jasné, zda ten server nemá dělat jen reverzní proxy, a pak by na to existovaly vhodnější nástroje, než Apache. Už čistě jenom z toho důvodu, že Apache je univerzální webový server, a jeden z mnoha jeho modulů je reverzní proxy server – který tam je spíš z toho důvodu, že univerzálnost Apache umožňovala přidat tam i tohle. Jiné servery vznikly později a právě s tím záměrem zakončit na nich HTTP(S) spojení od klienta, vyčistit ho, případně rychle odbavit statické soubory – ale pokud klient požaduje něco, co od serveru vyžaduje skutečnou práci aplikace, přeposlat ten požadavek někam dál, kde se ta práce vykoná. Je to jiný charakter práce serveru, takže se pro to i hodí jiná aplikace.

[Milan Uhrák]

Díky za vysvětlení. Příští krok bude přesměrování portu v iptables .. tedy .. používám shorewall, kde se mi lépe chápe co píšu... M.