Мигриране на уебсайтове към HTTPS с Nginx, Varnish и Apache, Всичко за WordPress

Мрежата преминава към използване на HTTPS криптиране по подразбиране. Този преход беше подкрепен от Google, който обяви, че HTTPS ще бъде един от факторите за класиране при търсене. Въпреки това мигрирането на вашия сайт към HTTPS е чудесно и по много други причини.

В тази статия ние се абстрахираме от причините за прехода към HTTPS и разглеждаме техническата страна на този процес. Ние ще мигрираме нашия сайт към HTTPS, като се възползваме от Varnish Cache.

Какъв е проблемът с Varnish и HTTPS?

Има доста лесен начин за справяне с този проблем и той е да се въведе допълнителен слой, разположен между входящите SSL заявки и Varnish, слой, който ще обработва защитената връзка и SSL сертификатите, и след това да прехвърли заявката обратно към Varnish. За да реализираме този слой, ще използваме Nginx. Може би знаете, че Nginx е алтернатива на Apache. Въпреки това, Nginx може да се използва и като прокси за обработка и препращане на заявки към други услуги. Именно в този смисъл ще го използваме в тази статия. С други думи, ще създадем сървърен "сандвич", в центъра на който ще се намира нашата вкусна "баничка" - Varnish кеша.

Какво имаме и какво искаме да направим

Ще предположа, че сте в същата ситуация като мен – имате сървър, виртуален или специализиран, работещ с множество уебсайтове. Някои от тези сайтове ще искате да мигрирате изцяло към HTTPS, докато други може да останат HTTP засега.

Във вашата текуща конфигурация всяка заявка на порт 80 може да бъде обработена от Varnish. ТогаваVarnish решава, въз основа на правила, добавени към Varnish Configuration Language (VCL), дали да предложи кеширано копие на страницата или да предаде заявката обратно на Apache за създаване на нова страница. След като заявката достигне до Apache, уеб сървърът може да изисква някаква информация от базата данни (или може да извърши друга обработка, преди да създаде страницата).

До края на това ръководство ще имаме следното:

Nginx ще стартира на порт 443. Той ще обработва входящи HTTPS заявки и ще ги предава на Varnish.
Varnish ще работи на порт 80. Той ще обработва входящи HTTP заявки, включително тези, получени от Nginx, обслужващи страници от кеша или достъп до Apache.
Apache ще стартира на порт 8080. Той ще направи това, което Apache трябва да направи: ще покаже вашия уебсайт или приложение.

В такава ситуация Nginx става прокси. Той не извършва никаква обработка на вашия сайт, не изпълнява PHP, не взаимодейства с базата данни. Всичко, което Nginx прави, е просто да приема HTTPS заявки и да ги сервира на Varnish. След това Varnish решава дали да върне кешираното копие или да поиска от Apache да предостави най-новата версия на съдържанието. Всичко се случва въз основа на правилата на Varnish, които вече имате.

Моята тестова среда

Ще работя с Vagrant, използвайки Ubuntu Trusty. Както бе споменато по-горе, моят Apache е свързан към порт 8080, а Varnish 4 е свързан към порт 80.

Можете да изтеглите моята тестова среда от GitHub. Инструкциите за инсталиране са във файла readme.

Имам два конфигурирани сайта. Ако посетя тези сайтове в браузър, Varnish ще обработи заявката на порт 80 или чрез обслужване на файла от кеша, или чрез извикване на Apache.

В моментаполезно е да проверим кои портове използваме. Свържете се чрез SSH към Vagrant:

След това стартирайте netstat:

Ще получим списък с портове, както и информация кои процеси ги използват. Трябва да имате предвид, че Varnish работи на порт 80, а Apache работи на 8080.

Можете също да проверите дали Varnish работи нормално и извлича страници от кеша:

Ако презаредите страницата в браузъра си, ще можете да видите статистика за достъп до кеша.

Ако използвате моя GitHub VCL, можете да видите, че съм добавил някакъв код към конфигурацията на Varnish, който изпраща HIT или MISS хедър към браузъра. Това означава, че можете да видите кой хедър е изпратен. Трябва да видите X-Cache: HIT, ако страницата идва от Varnish кеша, и X-Cache: MISS, ако страницата идва от Apache.

Инсталиране на Nginx

Сега ще инсталираме Nginx. В система Ubuntu това е много лесно да се направи:

Документацията на Nginx съдържа информация за инсталирането на Nginx на различни системи, както и пакети за системи, които не са част от тяхната система за управление на пакети. Не забравяйте, че ние използваме само Nginx като прокси, т.е. не е нужно да се занимаваме с конфигуриране на PHP или MySQL поддръжка. Nginx няма да стартира по подразбиране, защото порт 80 вече се използва от Varnish. Ако правите това на сървър на живо, тогава можете лесно да завършите тази стъпка, без да се притеснявате за здравето на вашите работещи сайтове.

Създаване или инсталиране на SSL сертификат

Следващата стъпка е да инсталирате SSL сертификат. Тъй като работим локално, можем да създадем самоподписан сертификат, за да тестваме SSL връзката.

За да създадете самоподписан сертификат затестване, изберете или създайте директория, в която ще се намира. Създадох директория nginx в /etc/ssl. След това изпълнете следната команда, за да генерирате ключа и сертификата.

Когато издадете тази команда, ще ви бъдат зададени поредица от въпроси. Можете да пишете всякакви глупости като отговори; обаче, когато бъдете попитани за „Общо име“, използвайте домейна, който обикновено въвеждате в URL лентата, за да получите достъп до вашия сайт във Vagrant. В моя случай това е smashing_ssl_one.tutorials.eoms:

Ако сега погледнете папката, която сте създали, трябва да видите два файла вътре, един с разширение .key и един с разширение .crt.

За работещ сървър трябва, разбира се, да поръчате сертификат от сертифициращ орган. В този случай ще получите готов файл с ключ и сертификат - не е необходимо да ги създавате ръчно. Ще трябва да ги хоствате на вашия сървър, преди да продължите със следващата стъпка.

Препоръчвам да закупите SSL сертификати за уебсайтове (Comodo, Symantec и др.) от доверена компания на LeaderTelecom. ЛидерТелеком е стратегически партньор на Comodo. Цените на сертификатите са по-ниски от тези на официалните регистрационни центрове, а поддръжката е достъпна на български език. Ще бъде лесно да разрешите всички проблеми, ако възникнат.

Настройка на SSL за сайтове в Nginx

След като имате своя собствено подписан или закупен SSL сертификат в папка на сървъра, можете да започнете да настройвате вашите сайтове в Nginx.

Първо премахнете конфигурационния файл по подразбиране от /etc/nginx/sites-enabled. Можете да изтриете файла по подразбиране или да го преместите в друга папка.

Трябва само да конфигурираме сайтовете, които ще се обслужват през SSL; всички други сайтове ще продължат да се обслужват чрез Varnish, работещ на порт 80.В моя случай ще конфигурирам smashing_ssl_one.tutorials.eoms. Където и да видите този домейн следващия път, ще трябва да го замените с ваш собствен домейн (локален или онлайн). Изключение: ако използвате моята работна маса, която беше свързана по-горе.

В директорията /etc/nginx/sites-available/ създайте конфигурационния файл your_domain.com.conf. Добавете следното към този файл:

Първият ред казва на сървъра, че "слушаме" на порт 443. Това е стандартният порт за HTTPS връзки, точно както порт 80 за HTTP. След това задаваме името на сървъра.

Активираме SSL и добавяме сертификата с ключа, който създадохме или инсталирахме, като посочихме пълния път.

В секцията за местоположение използваме proxy_pass, за да предадем заявката към порт 80, където Varnish я чака. След това задаваме заглавките, които ще бъдат предадени.

След като добавим този файл, ние създаваме символна връзка към файла, променяйки достъпни сайтове на активирани сайтове. Ако някога искате да деактивирате сайт, можете просто да премахнете символичната връзка. Следната команда ще създаде символна връзка:

Сега рестартираме Nginx:

Ако срещнете nginx да рестартира изхода на nginx след [fail], тогава проблемът най-вероятно е скрит в печатна грешка в конфигурационния файл. Обичайният ми проблем е, че или забравям да разделя ключовете и стойностите с двоеточие, или забравям точката и запетая в края на реда.

Ако Nginx стартира успешно, ще видите [OK]. Сега, ако проверите кой процес се изпълнява на всеки порт, трябва да видите, че Nginx работи на 443, Varnish работи на 80 и Apache работи на 8080.

Сега ще трябва да посетим сайта, използвайки протокола https://. Ако използвате самоподписан сертификат, тогава трябва да получитеследващо предупреждение - вашият браузър ще ви каже, че сертификатът е издаден от неизвестен сертифициращ орган.

Пренасочване към SSL с Varnish

Според моя опит може да искате да направите някои подобрения.

Ако вашият сайт работи на HTTP и искате да го стартирате на HTTPS, тогава ще трябва да зададете пренасочване за всички HTTP заявки. Можете да направите това с лак. Varnish в момента работи на порт 80, обработвайки всички не-SSL заявки. Искаме Varnish да улови заявката към нашия сайт и да я пренасочи през HTTPS.

След това в подблока vcl_recv добавете следното:

Можете да видите пълния VCL, включително целия предоставен код, в GitHub.

Сравнявам домейна с шаблона и след това го пренасочвам към HTTPS с код 301 (преместен за постоянно). Така че сега всичко трябва да бъде мигрирано към SSL релси. Рестартирайте Varnish и опитайте да отидете до HTTP версията на сайта, като проверите дали пренасочването работи.

Ако получавате твърде много посещения на Apache (MISS), тогава трябва да проверите обработката на бисквитките на Varnish. Varnish не кешира съдържание с бисквитки, тъй като предполага, че това е персонализирано съдържание. Неща като бисквитките на Google Анализ обаче не трябва да карат вашето съдържание да не се кешира. Обработвам някои популярни бисквитки в моя VCL, но можете също да прочетете следната публикация от Mattias Geniar за това какви бисквитки се предават на бекенда.

Тестване на SSL

Сигурно сте чували за различни уязвимости в OpenSSL. Ако искате да превключите всичките си сайтове на HTTPS, уверете се, че сте защитени от всички тези проблеми.

След като имате работещ уебсайт с SSL,ще трябва да го тествате с SSL Server Test от Qualys SSL Labs. Добавете името на вашия домейн и изчакайте тестовете да се изпълнят. Тестът ще ви покаже най-популярните проблеми с конфигурацията на SSL - вашата цел е да преминете тестовете с оценка A.

Първият път, когато тествах с Vagrant - Ubuntu Trusty, Nginx, Varnish и Apache - получих оценка B, защото сървърът беше уязвим на Logjam атаки. Защитата срещу подобни атаки е описана подробно в статията: „Weak Diffie-Hellman and the Logjam Attack“.

Връщаме се на нашия сървър, отиваме (cd) в директорията, където се съхранява SSL сертификатът, и след това правим следното:

Това ще създаде файл dhparams.pem.

Вече можете да добавите кода, представен в секцията Nginx на статията Weak Diffie-Hellman и Logjam Attack към вашата конфигурация на Nginx.

Рестартирайте Nginx и тествайте отново сайта. След като постигнете оценка A, можете периодично да провеждате тестове, за да проверите дали спазвате всички правила.