Рассказ основан на некоторых общедоступных знаниях и личном опыте. Рассчитан как на начинающих, так и на опытных разработчиков.

Рассказ о популярной универсальной архитектуре стека, в котором работает веб-приложение. Само приложение может быть написано на любом интерпретируемом языке с использованием любого фреймворка фреймворков. В данном случае это не важно, так как архитектура программной инфраструктуры — технологического стека, в котором оно работает, отличается мало.

Обсуждается путь запроса пользователя до и внутри сервера, его обработка и возврат ответа. Затрагиваются вопросы состояния приложения — работы с хранилищами, кэширования.

Затрагиваются вопросы масштабирования и отказоустойчивости. Речь идет о приложениях со средними и относительно большими нагрузками, где есть место универсальным решениям. Для систем, где нагрузки особо большие, существуют другие архитектуры и подходы, которые тут не упоминаются.

Смотрите в полноэкранном режиме.

StartSSL раздает валидные годовые SSL-сертификаты бесплатно. Другие компании берут за это деньги начиная примерно от $20 в год. StartSSL зарабатывает на сертификатах более высоких классов, включая сертификат с расширенной валидацией, а базовый сертификат делает бесплатно. Их идея заключается в том, что они не берут деньги за сервис, в котором не используется труд людей (базовая валидация домена производится автоматически).

1. О системе StartSSL и их сертификатах

Особенность функционирования сайта StartSSL заключается в том, что авторизация в панель управления производится через клиентский S/MIME сертификат. Это большая редкость в наши дни. Отсюда возникает непонимание процесса неподготовленными пользователями и тупняк на этапе освоения сервиса.

Суть заключается в том, что вместо логина и пароля вам выдается сертификат. Почти такой же сертификат, какой выдается для подтверждения подлинности сервера. Этот сертификат отправляет на сервер ваш браузер при авторизации (автоматически после вашего подтверждения). Браузер берет его из хранилища, куда сертификат должен быть импортирован до проведения авторизации. Если сертификата в хранилище не окажется, то при авторизации вы увидите браузерное сообщение об ошибке, на подобии «Не удаётся завершить защищённую транзакцию».

Чтобы получить бесплатный сертификат для вашего сайта, нужно зарегистрироваться в сервисе StartSSL и получить персональный сертификат, войти с его помощью в панель, после чего можно будет заказать и получить бесплатный SSL-сертификат для вашего сайта.

Персональный сертификат действует 1 год и его необходимо своевременно обновить в за месяц до конца срока действия, иначе вы потеряете доступ к панели.

Так же следует сразу отметить, что получить сертификат можно только для доменов из фиксированного списка зон. Это домены второго уровня во всех региональных и коммерческих зонах первого уровня, а так же отдельные зоны второго уровня (с доменами третьего уровня).

Кроме того, на домене должна работать почта. На один из ящиков из фиксированного списка (webmaster@домен, postmaster@домен, hostmaster@домен или адреса, указанные в Whois) придет письмо с кодом проверки.

2. Регистрация

Зайдите на сайт StarSSL и начните регистрацию (кликаем Sign-up). При этом нельзя использовать Google Chrome (можно Opera, Firefox, IE).

2.1. Заполните форму. Укажите свои реальные данные. Во-первых, этого требует соглашение, с которым вы соглашаетесь при регистрации. Во-вторых, эти данные проверяются вручную. В-третьих, указывать здесь фейковый данные смысла мало, т.к. кроме самого StartSSL их никто не увидит.

2.2. Укажите код подтверждения e-mail-а. Как правило, письмо с кодом приходит сразу или в течение минуты.

2.3. Дождитесь проверки указанных данных персоналом StartSSL. Да, они проверят то, что вы ввели в форме. Вручную. Если их ничего не смутит (а как правило ничего не смущает в реальных данных), вам придет ответ на e-mail, в котором будет указана ссылка на вторую активацию аккаунта (с кодом). Обратите внимание, что ссылка действует только в течение 24 часов.

Они могут задать дополнительные вопросы по e-mail для уточнения регистрационных данных. Отвечать на них имеет смысл, и опять-таки — честно.

После подтверждения аккаунта персоналом вам прийдет второе письмо с кодом проверки. Переходите по ссылке из второго письма, указывайте второй код активации, попадете на страницу генерации ключа персонального сертификата:

Для генерации ключа выбираем 2048 бит (в выпадающем меню), так как меньшую битность StartSSL не поддерживает, а в большей едва ли есть смысл.

После нажатия «Continue» генерируется ключ заданной длины. Он сохраняется в браузере и отправляется на сервер. Там генерируется сертификат на основании этого ключа. После генерации сертификат передается (после нажатия «Install») вам — в браузере появляется окно, предлагающее его установить.

Устанавливаем обязательно.

2.4. На данный момент картина следующая: у вас есть подтвержденная учетная запись StartSSL и персональный сертификат, установленный в браузер, который заменяет для вас одновременно логин и пароль.

Этот сертификат необходимо «достать» из браузера и сохранить в надежном месте. В случае потери установленного сертификата (например, переустановка ОС или браузера) вы сможете его вновь импортировать. Кроме того, сертификат нужен для того, чтобы войти в панель с другого компьютера.

Конкретные действия для экспорта сертификата зависят от вашего браузера. Общее лишь то, что вы должны попасть в управление хранилищем сертификатов, найти там свой персональный сертификат StartSSL и экспортировать его в файл. В Opera это делается так:

Формат экспорта — с секретным ключем PKCS#12. Если такого формата нет и вы не знаете, какой формат экспорта лучше выбрать (при условии, что их несколько), экспортируйте во все :). Если вы экспортируете сертификат без ключа, смысла в этом не будет — он не будет работать.

Если вы потеряете сертификат, утратите доступ к панели. Это значит, что для получения новых сертификатов и продления старых (через выписку нового), необходимо будет заново регистрироваться.

3. Итак, ваша учетная запись подтверждена и у вас есть персональный сертификат для авторизации в панели StartSSL. Теперь самое время зайти в панель. Нажимаем на кнопку с ключами и попадаем на страницу авторизации (смотрите на первом изображении в статье). Нажимаем «Authenticate». Подтверждаем передачу серверу нашего персонального сертификата. Авторизация пройдена — вы в панели.

Если на этом этапе вы получаете ошибки, значит что-то не то с сертификатом. Если браузер при авторизации не выдавал вам предложения отправить сертификат на сервер, значит он не импортирован в хранилище (см. выше).

Самое тяжелое позади. Теперь необходимо заказать и получить сертификат для вашего сайта. Он будет выдан на год. Спустя 11 месяцев необходимо зайти на сайт и получить новый сертификат на тот же сайт (то же имя). Как таковой процедуры продления сертификатов нет ни для сайта, ни для персональных сертификатов. Об окончании срока действия сертификатов StartSSL несколько раз раз предупреждает по почте.

Панель StartSSL состоит из 3-х разделов (вкладки на изображении выше):

• Tool Box — инструментарий. Большая его часть бесполезна. Можно отметить только разделы для получения корневых и промежуточных сертификатов StartSSL и получения ранее созданных сертификатов.
• Certificates Wizard — мастер создания нового сертификата. С него начинается заказ нового сертификата для сайта или персонального сертификата. Для создания сертификата должен быть заранее подтвержден домен или адрес e-mail соответственно.
• Validations Wizard — это как раз и есть мастер проверки сайта и e-mail (а кроме того платных проверок личности и организации). С него нужно начинать получение сертификата для сайта. Каждая проверка действует 30 дней, так что при «продлении» сертификатов проверки необходимо повторять.

Итак, начинаем процесс получения сертификата для сайта.

3.1. Проверка (валидация) домена. Переходим в Validations Wizard, выбираем проверку домена (Domain Name Validation):

На следующем шаге укажите домен. После выбора домена необходимо выбрать из списка предложенных e-mail, на который придет письмо с кодом для проверки принадлежности домена. Письмо как правило приходит быстро, ввод кода подтверждения аналогичен, как при регистрации.

3.2. После проверки принадлежности домена нужно заказать для него сертификат. Для этого перейдите в Certificates Wizard, выберите Web Server SSL/TSL Certificate. Далее выберите из списка один из предварительно проверенных доменов.

На следующем шаге есть два варианта:

• пропустить шаг и предоставить собственноручно сгенерированный CSR со своим приватным ключем,
• или заполнить форму и сгенерировать приватный ключ в браузере.

Первый вариант выбирают те, кто знает, что такое CSR и как его сделать. В любом случае обратите внимание на то, что размер ключа (Keysize) не должен быть менее 2048 бит.

Предположим, что выбран вариант с генерацией ключа. Тогда заполните форму и нажмите «Continue». После некоторой паузы вы получите свой ключ. Сохраните его, он пригодится позже.

На следующем шаге повторно выберите домен. Далее, укажите для него поддомен. Сертификат будет действителен для выбранного домена и указанного сабдомена (например, www).

На следующем шаге просто подтверждается заказ сертификата. После этого вы получите сам сертификат (PEM-encoded). Сохраните его.

Процесс получения сертификата на этом завершен. В результате у вас есть 2 файла: приватный ключ и сертификат. Их нужно указать в конфигах вашего веб-сервера. Приватный ключ необходимо предварительно расшифровать командой:

openssl rsa -in ssl.key -out ssl.key

О том, как настроить веб-сервер для использования полученного сертификата, как-нибудь в следующий раз. А вообще, по этой теме хватает информации в Интернете.

Так вот, по настройке работы данной пары в связке в Интернете есть море статей, в том числе на русском, и об этом писать смысла нет. А расскажу я вам лучше о тех нюансах, с которыми вчера столкнулся при настройке nginx на работу в нужном ладе, и заодно покажу и прокомментирую свою конфигурацию этого сервера.

Моя конфигурация

Для начала, что собственно требовалось сделать? Сервер настраивался для Хаброметра. Он должен был выдавать статику (лого и css) и динамику (собственно страницы сайта и png-хаброметры). При этом, надо было учесть, что хаброметр создается на лету в том случае, если не лежит в кэше (а кэш чистится каждые 2 часа при запросе новых данных). Страницы сайта также необходимо кэшировать. Вот такая была задача.

Реализацию решено было сделать следующим образом. nginx при обработке запроса должен следовать следующим правилам:

1. Если запрошена статика, то просто вернуть ее (вся статика в папочке stuff).
2. Если запрошена страница сайта, нужно проверить кэш; если в кэше файл не найден, передать запрос бэкэнду apache. Кэш страниц должен чиститься с заданной частотой (для разных страниц частота разная).
3. Если запрошен информер, то нужно проверить кэш на наличие файла. Если файла там нет, передать запрос бэкэнду.

Для кэширования хаброметров выбрана файловая система. Все сгенерированные информеры складываются в каталог /image_cache/ и он чистится каждые 2 часа при обновлении исходных данных. Рисуются информеры и кладутся в этот каталог PHP-скриптом при соответствующем запросе.

Для кэширования страниц сайта выбран memcache, т.к. с ним легко и удобно работать (как из nginx, так и из PHP) и он сам может чистить кэшированные странички через заданный интервал времени, что ФС делать не может без дополнительных скриптов. Да и работать memcache будет побыстрее, т.к. все добро складируется в оперативке.

Получилась следующая конфигурация сервера:

# cat /etc/nginx/nginx.conf

user www-data;
worker_processes 2;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  2048;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    add_header Habrometr "hacker_mode_enabled;)";

    server {
        listen       80;
        server_name  habrometr.server.valera.ws habrometr.ru www.habrometr.ru;
        access_log  /var/log/nginx/habrometr.access.log;
        location / {
            root   /home/habrometr/public_html;
            index  index.html index.htm;
            if (-f $document_root/image_cache${uri}) {
                rewrite ^.*$ /image_cache/$uri last;
                break;
            }

            set $memcached_key "habrometr$uri";
            memcached_pass localhost:11211;
            # если в memcached не найден ресурс, передаем запрос на апач
            error_page 404 502 504 = @backend;
            add_header Content-Type "text/html; charset=UTF-8";
            gzip on;
            gzip_proxied any;
            gzip_types application/octet-stream;
    }
    location @backend {
        set $proxy_uri http://habrometr.ru:99999$request_uri;
        proxy_pass $proxy_uri;
        proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X_Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout 20;
    }
    location /image_cache/ {
        root   /home/habrometr/public_html;
        expires modified +2h; # кэш истекает через 2 часа после модификации файла
    }
    location /stuff/ {
        root   /home/habrometr/public_html;
        expires 30d;
    }
    location ~ /\.ht {
        deny  all;
    }
}
Учитывая приведенный выше сценарий, вся конфигурация должна быть понятна. Замечу лишь, что http://habrometr.ru:99999 — это apache, которому будут перенаправляться запросы. Порт я, конечно, изменил, в реальности обычно используют 8080 или что-то типо того.
Фокусы
А теперь о том, что нетривиального в этой конфигурации (во всяком случае для новичка в этой области).
Версия
Во-первых, сервер у меня работает на Debian 4.0. Весь софт я естественно ставил из  стандартных репозиториев. Поставил оттуда и nginx. Установленный nginx оказался версии 0.4 при наличии последней версии 0.7 со значительным списком изменений.
Выяснилось, что версия 0.4 не умеет делать много из того, что было нужно. В частности:

флаг modified не сузествует для директивы expire, а мне это необходимо было для указания времени устаревания кэша информеров (2 часа после создания: expire modified +2h);
proxy_pass не умел использовать переменные, а мне требовалась эта возможность;
memcached не использовал переменную $memcached_key для определения ключа, т.е. нельзя было задать ключ нужного формата.

В принципе, все эти проблемы можно было решить обходными извращенскими путями, но делать этого совсем не хотелось, по этому я просто поставил свежую версию nginx из сырцов. Благо, делается это очень просто.
Перед тем, как описать процесс установки, замечу, что по умолчанию при сборке из исходников все файлы nginx складывает в каталог /usr/local/nginx. Его, конечно, можно изменить (—prefix=). Но обратите внимание, что установленных из пакетов nginx раскидывает свои файлы по соответствующим каталогам системы (/etc, /var/log, /var/run и т.д.), что лично мне определенно нравится больше, чем /usr/local/nginx/*. По этому я откомпилировал nginx из сырцов с  настройками на системные каталоги, а потом вместо make install просто вручную заменил старый бинарный файл сервера в каталоге /usr/sbin на новый (/usr/sbin/nginx). Больше значимых файлов после сборки для сервера нет. Конфиг, естественно, остается тот же самый.
Итак, установка nginx на Debian etch из исходников поверх установленного пакета старой версии.
# wget http://sysoev.ru/nginx/nginx-0.7.31.tar.gz
# tar xzf nginx-0.7.31.tar.gz
# cd nginx-0.7.31
# apt-get install libpcre3 libpcre3-dev libpcrecpp0
# /etc/init.d/nginx stop;
# ./configure --sbin-path=/usr/local/sbin --with-http_ssl_module
--without-mail_pop3_module --without-mail_imap_module
--without-mail_smtp_module --prefix=/var/lib/nginx
--sbin-path=/usr/sbin --conf-path=/etc/nginx/
--error-log-path=/var/log/nginx --http-log-path=/var/log/nginx
--pid-path=/var/run --lock-path=/var/lock
# make
# cd objs
# cp -f ./nginx /usr/sbin
# /etc/init.d/nginx start;
После этого уже должен быть запущен и обслуживать запросы свежий сервер nginx, который умеет все нужные нам штуки.
Документы из memcached
Когда nginx отдает напрямую файлы, он передает заголовок Content-type в соответствии с типом данного файла. Когда nginx проксирует apache, Content-type приходит от apache. Но когда nginx забирает документа из memcached, то Content-type не устанавливается. А значит, используется дефалтный. А дефалтный у нас по конфигу   default_type  application/octet-stream;, и это правильно. В этом случае при отдаче документа из кэша будет неправильно передаваться тип и некоторые браузеры предложат сохранить бинарный файл, вместо того чтобы открыть HTML-страницу. Чтобы ситуацию исправить, в случае отдачи из memcached устанавливаем заголовки (и, кстати, сжатие тоже) дополнительно:
set $memcached_key "habrometr$uri";
memcached_pass localhost:11211;
error_page 404 502 504 = @backend;
add_header Content-Type "text/html; charset=UTF-8";
gzip on;
gzip_proxied any;
gzip_types application/octet-stream;
При этом из memcached мы получаем только HTML в UTF-8.
Мухи отдельно, котлеты отдельно.
В  качестве отдельной магии хотелось бы выделить сам способ выделения хаброметров по имени файла и обслуживания их по-особому. В секции location / выделяем эти файлы:
if (-f $document_root/image_cache${uri}) {
    rewrite ^.*$ /image_cache/$uri last;
    break;
}
Если файл находим в кэше, то просто возвращаем его пользователю, сообщая что файл можно закешировать до времени следующего обновления (модификация файла + 2 часа):
location /image_cache/ {
    root   /home/habrometr/public_html;
    expires modified +2h;
}
Обратите внимание на наличие флага last у rewrite и директивы break; за ней. Без использования этих двух директив мне не удалось заставить nginx 0.4 (на 0.7 я не проверял) сразу перейти в секцию location /image_cache/, т.е. после обнаружения файла он переходил к проскированию, что неверно.
]]>
					
					https://valera.ws/2009.01.26~nginx-magic/feed/
			2
		
		
			
		
		
		https://valera.ws/2008.11.25~internet-adslby-debian/
					https://valera.ws/2008.11.25~internet-adslby-debian/#respond
		
		
		Tue, 25 Nov 2008 07:25:41 +0000
				
		
		
		
		
		
		http://valera.ws/?p=201

					Читать далее Настройка интернета от ADSL.BY в Debian →]]>
										Краткая инструкция по настройке интернет-соединения с провайдером ADSL.BY по VPN в Debian Linux. За основу взята инструкция из блога ZvZ.

1) Для поднятия соединения необходимо установить пакеты PPTP и PPP.
# apt-get install pptp-linux


 # apt-get install ppp
Опционально можно установить пакет для мониторинга PPP-соединения:
# apt-get install pppstatus
2) Далее требуется поправить конфиг /etc/ppp/options. Если брать за основу дефалтный файл, надо закомментить лишние строки и добавить недостающие. Но проще удалить все и вставить следующие строки:
lock


 hide-password


 noauth


 nobsdcomp


 nodeflate
3) Необходимо создать файл ppp-соединения в каталоге /etc/ppp/peers. Имя файла может быть любое, но его придется указывать каждый раз при подъеме соединения. Например, /etc/ppp/peers/adsl.by
remotename adsl.by


 linkname adsl.by


 ipparam adsl.by


 name 22222pupkin


 pty «pptp 81.25.32.68 —nolaunchpppd»


 connect «ip route add `ip route get 81.25.32.68 | head -1`; exit 0»


 replacedefaultroute


 refuse-eap


 debug dump


 noauth


 defaultroute
В данном примере требуется заменить имя пользователя (22222pupkin), а при необходимости и IP шлюза.
3) В файл /etc/ppp/chap-secrets добавляем пароль от Интернета. Для параноиков обращаю внимание, что файл можно писать и читать только из-под root’а. Остальным пользователям заглянуть в него не удастся. В файл требуется добавить строку, в которой все значения разделены не пробелом, а табуляцией.
22222pupkin adsl.by пароль *
4) Если вы еще не указали DNS-сервера Инфонета при настройке сети, сделайте это. Это можно сделать через Network Manager, или вручную в файле /etc/resolv.conf
81.25.32.34


 81.25.32.9
5) Теперь пропишем роуты. Это можно делать каждый раз после загрузки, можно сделать скрипт (например у меня роуты прописываются после поднятия wi-fi-соединения скриптом), можно засунуть в «автозагрузку». Роут нужен следующий:
# route add -net 81.25.32.0 netmask 255.255.255.0 gw 192.168.0.1
192.168.0.1 — это адрес вашего модема.
Настройки готовы. Теперь можно пользоваться. Запуск  соединения (из-под  root’а):
# pon adsl.by
Останов всех ppp-соединений:
# pon -a
Останов только данного соединения:
# poff adsl.by
Просмотр статистики (если соответствующий ставили пакет в начале):
# pppstatus
(Чтобы выйти из просмотра статистики, наберите !q)
После команды pon adsl.by между вами и сервером поднимается соединение по протоколу PPP, поверх которого идет туннелирование PPTP. Соединению PPP соответствует появившийся сетевой адаптер ppp0. Если создать больше одного соединения, появятся адаптеры ppp1 и т.д. Именно на этот адаптер  прописывается default route автоматически (если ваши настройки соответствуют приведенным выше).
Удачи! ;)
]]>
					
					https://valera.ws/2008.11.25~internet-adslby-debian/feed/
			0
		
		
			
		
		
		https://valera.ws/2008.11.21~traffic-security/
					https://valera.ws/2008.11.21~traffic-security/#respond
		
		
		Thu, 20 Nov 2008 21:11:08 +0000
				
		
		
		
		
		
		
		http://valera.ws/?p=161

					Читать далее Безопасность (шифрование) трафика →]]>
										Параллельно с развитием технологий защиты интернет-трафика от несанкционированного доступа развиваются и технологии перехвата защищенного трафика. Перехватить и изучить незашифрованный трафик пользователя уже давно не составляет труда даже для рядового юзера. Практически каждому известно слово «сниффер». Теоретически, защищенные SSL/TSL-соединения перехватить обычными средствами невозможно. Но так ли это?


На самом деле — не совсем так. Да, зашифрованный трафик теоретически невозможно расшифровать, хотя опять таки теоретически при очень большой необходимости и желании, и такой трафик можно расшифровать, подобрав ключ. Однако для этого нужны такие затраты ресурсов, что актуальность взлома сохраняется только, наверное, на правительственном или военном уровне :)
При работе по защищенному соединению (самый просто пример — HTTPS) весь трафик между взаимодействующими точками в сети шифруется на стороне отправителя и дешифруется на стороне получателя. Шифруется трафик, идущий в обоих направлениях. Для того, чтобы его зашифровать и расшифровать нужна пара ключей (ассиметричное шифрование).  Публичный ключ служит для зашифрования и передается получателю данных, а приватный — для дешифрования, он остается у  отправителя. Таким образом, узлы, между которыми устанавливается SSL-соединение, обмениваются публичными ключами. Далее, для повышения производительности формируется единый ключ, который пересылается уже в зашифрованном виде и используется как для шифрации, так и для дешифрации на обеих сторонах (симметричное шифрование).
А как они это делают? Обычно — по тому же каналу, по которому далее будет идти защищенный трафик. Причем обмен ключами происходит в открытом режиме. В случае HTTPS ключ сервера связан с сертификатом, который пользователю предлагается просмотреть и принять. И вот этот сертификат как раз и может перехватить любой промежуточный сервер, на пути которого идет сертификат в открытом виде (прокси, роутер).
Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.
Если пользователь принимает сертификат-подделку, то трафик будет идти по следующей схеме:
клиент <= SSL-соединение => сервер-прослушка <= SSL-соединение => сервер назначения
Т.е. промежуточный сервер будет получать весь ваш «защищенный» трафик в открытом виде. Стоит также заметить, что передача сертификата происходит в начале каждой сессии HTTPS.
В случае защищенного SSH при первом соединении с сервером на клиенте сохраняется ключ сервера, а на сервере — ключ клиента. Эти ключи передаются между данными клиентом-сервером только один раз, при первом подключении. Если в этом случае SSH-трафик попытаются перехватить, то и клиент, и сервер откажут в соединении из-за несоответствия ключей. Так как ключи можно перенести между клиентом и сервером обходным путем (по защищенному каналу или на внешнем носителе), этот способ соединения является относительно безопасным. Его могут лишь заблокировать, заставив пользователя работать в открытую.
Стоит отметить, что уже давно продаются так называемые «решения по информационной безопасности предприятия», которые перехватывают весь трафик, проходящий через офисный прокси-сервер, и «читают» его. Программы ищут наличие определенных фраз или информации определенного вида в потоке данных от браузеров, почтовых программ, ftp-клиентов, мессенджеров сотрудников офиса. Причем, эти программы умеют различать и обрабатывать правильно самые разные виды информационного взаимодействия с серверами. В том числе, они проверяют и защищенный SSL-трафик путем подмены сертификатов. С разработкой одной из таких систем я сталкивался почти непосредственно.
Но пути спасения от тотальной слежки есть. Через установленное SSH-соединение можно направлять любой нужный трафик, который с SSH-сервера будет уже в открытом виде идти на конечную точку. Этот способ называется SSH-туннелинг (tunneling). Так можно обезопасить прохождение трафика по незащищенному каналу, но имеет смысл такой подход только при наличии доверенного сервера с поднятым и настроенным на туннелинг SSH-демоном. Причем организовать это достаточно просто. SSH-клиент подключается к серверу, настраивается на прослушку любого данного порта на локальной машине. Этот клиент будет предоставлять услугу SOCKS5-прокси, т.е. его использование можно настроить в любом браузере, почтовых программах, IM-ах и т.д. Через SSH-туннель пакеты попадают на сервер, а с него уходят на целевой сервер. Схема получается следующая:
[localhost: клиент <=> proxy] <== SSH-соединение ==> сервер <=> целевой сервер
Другой способ защиты трафика — VPN-канал. В использовании он проще и удобнее SSH-туннелинга, но в первичной установке и настройке сложнее. Основное удобство этого способа в том, что в программах не нужно прописывать прокси. А некоторый софт и вовсе прокси не поддерживает, следовательно только VPN и подойдет.
На практике есть два варианта работы. Первый — покупка VPN-акканута, который продается специально для этих целей (шифрование трафика по небезопасному каналу). В этом случае продаются обычно аккаунты, соединяться с которыми надо по протоколам PPTP (обычный VPN, который реализован, например, в Windows) или L2TP. Купить такой аккаунт можно, например,  на russianproxy.ru.
Второй вариант — покупка VDS-сервера (виртуальный выделенный сервер) с любым дистрибутивом линукса на борту и поднятие на нем VPN-сервера. Один из самых популярных российских провайдеров — firstvds.ru. Его главное преимущество — низкие цены (акцентирую внимание на то, что серверы в России; если подойдет американский сервер, есть, например, vpsland.com, только не забывайте про заокеанские пинги). На VDS ставят OpenVPN-сервер, а на компьютере поднимается OpenVPN-клиент. Для Windows есть даже гуишная версия клиента.
Если вы решите использовать вариант с OpenVPN, то есть простая пошаговая инструкция по поднятию сервера, как раз для firstVDS с Debian на борту. Установить клиента еще проще, особенно под Windows. Отметить стоит только один нюанс. Если весь трафик требуется пустить по созданному VPN-соединению, то требуется прописать default gateway на шлюз VPN (параметр redirect-gateway в конфиге клиента), а если только часть трафика (на определенные хосты), то можно прописать обычные статические маршруты на данные хосты (по IP; например, route add -p 81.25.32.25 10.7.0.1).
Для соединения OpenVPN обмен ключами происходит в ручном режиме, т.е. транспортировать их от сервера на клиент можно абсолютно безопасно.
Таким образом, SSH- и VPN-соединения могут практически полностью гарантировать безопасность вашего трафика при перемещении по незащищенному каналу. Единственная проблема, которая может возникнуть в этом случае, — это запрет на SSL-трафик на корпоративном файрволе. Если SSL-трафик разрешен хотябы на один любой порт (обычно дефолтный 443), то вы уже потенциально можете поднять и SSH-тонель, и VPN-соединение, настроив соответствующего демона на вашем VDS на этот порт.
]]>
					
					https://valera.ws/2008.11.21~traffic-security/feed/
			0