Bekijk Volledige Versie : Varnish en SSL met DirectAdmin NGINX/Apache
mgielissen
01/05/17, 00:27
Om Varnish te testen in Directadmin (met NGINX als reverse proxy voor Apache) heb ik heb deze howto gevolgd: https://help.poralix.com/articles/nginx-varnish-apache-on-directadmin.
Voor http sites werkt dit, NGINX stuurt het verkeer van poort 80 naar Varnish op 6081. Varnish stuurt het weer door naar Apache op 8080.
Echter, voor https stuurt NGINX poort 443 (ssl) alles door naar Apache op 8081 (ssl). Kan Varnish op een of andere manier ook het ssl verkeer cachen? :huh:
Echter, voor https stuurt NGINX poort 443 (ssl) alles door naar Apache op 8081 (ssl). Kan Varnish op een of andere manier ook het ssl verkeer cachen? :huh:
Ik denk dat ik :
/usr/local/directadmin/data/templates/custom/nginx_server.conf
/usr/local/directadmin/data/templates/custom/nginx_server_sub.conf
even moet zien om te bepalen wat er aangepast moet worden. Voor een varnishloze setup is het logisch om SSL verkeer naar SSL te forwarden (DA heeft immers ook de mogelijkheid om op ssl een compleet andere site te hebben als op non-ssl (/private_html)
Varnish kan niks met SSL verkeer, dat zou je moeten offloaden en door varnish heen moeten leiden.
mgielissen
01/05/17, 08:47
Zou de Unixy plugin dit kunnen?
Aangezien steeds meer websites SSL gebruiken (vooral met LetsEncrypt) lijkt het mij een must om ook SSL te gaan cachen. Vooral omdat bijv Chrome in september meldingen gaat geven bij contactformulieren.
SSL heeft weinig tot niks te maken met cache, het geeft alleen de type verbinding aan die de client met de server maakt. Je kan prima NGINX de SSL laten afhandelen en vervolgens over http een request doen naar varnish
mgielissen
01/05/17, 09:01
Klopt, maar binnen DA wordt het SSL verkeer van NGINX naar Apache naar poort 8081 geforward die ook SSL gebruikt.
Dan doe je alles op de server zonder SSL. NGINX is het laatste systeem dat SSL ziet en Varnish en Apache doen geen SSL. Dat is wel hoe wij het hebben ingericht, veel zit dan in de cache van de iets drukkere sites. Het enigste is dat je geen verschillende sites meer weer kunt geven eigenlijk. Verder gaat alles goed.
stefantriep
01/05/17, 10:13
Dan doe je alles op de server zonder SSL. NGINX is het laatste systeem dat SSL ziet en Varnish en Apache doen geen SSL. Dat is wel hoe wij het hebben ingericht, veel zit dan in de cache van de iets drukkere sites. Het enigste is dat je geen verschillende sites meer weer kunt geven eigenlijk. Verder gaat alles goed.
Mark, kunnen klanten hun Wordpress, Drupla, Joomla of andere CMS site wel dan gewoon op https zetten in de backend of blijft dat gewoon op http? Aangezien site onderdelen bij blijven op http dan niet automatisch over https gaan of moet de Nginx die rewriten?
virtuality
01/05/17, 13:25
De backend kan op http blijven door de SSL offloading naar Nginx. De uitdaging is dan even dat een SSL invoeren via DA ook niet meer werkt omdat die het niet in NGINX configureert.
Zou de Unixy plugin dit kunnen?
Beetje offtopic maar om anderen te waarschuwen: plugin is sterk verouderd en m.i. ook niet netjes geprogrammeerd. Support erop is echt waardeloos en van documentatie hebben ze ook nog nooit gehoord.
De backend kan op http blijven door de SSL offloading naar Nginx. De uitdaging is dan even dat een SSL invoeren via DA ook niet meer werkt omdat die het niet in NGINX configureert.
Dat gebruikten wij voor de tijd ook al niet. Voor ons is dit dus geen verschil of nadeel.
Mark, kunnen klanten hun Wordpress, Drupla, Joomla of andere CMS site wel dan gewoon op https zetten in de backend of blijft dat gewoon op http? Aangezien site onderdelen bij blijven op http dan niet automatisch over https gaan of moet de Nginx die rewriten?
Wordpress en consorten zien enkel de http variant. Tenzij ze kijken naar de voor onze omgeving juiste headers. Het omzetten naar https doen we dan ook in een .htaccess middels deze headers en in de links overal https verwerken is ook geen probleem.
virtuality
02/05/17, 17:52
Als je liever zou hebben dat DA en daarmee ook Wordpress wel door heeft dat er HTTPS is kun je er ook voor kiezen om SSL offloading te doen met re-encryptie richting Apache. Dan kun je wel cachen doordat je het verkeer eerst decrypt en dan re-encrypt je het weer naar de host. Wel een stukje ingewikkelder en neemt het performance voordeel van offloading weg maar het is een optie.
Beetje offtopic maar om anderen te waarschuwen: plugin is sterk verouderd en m.i. ook niet netjes geprogrammeerd. Support erop is echt waardeloos en van documentatie hebben ze ook nog nooit gehoord.
Zelf een tijdje terug support voor SSL ingebouwd en volgens mij kwam dit in de nieuwe release. De support is absoluut niet goed en voor mij ook een reden om het niet te gebruiken maar complex is het niet.