Практичный порядок подготовки сервера для собственного прокси-IP: сначала проверить SSH-доступ, затем сменить порт и перейти на вход по ключу, выполнить базовое усиление защиты, установить прокси-сервис и открыть порт, после чего подключиться с клиента и проверить работу.
Когда облачный сервер покупают для использования в качестве прокси, проблема редко заключается в самой доступности сети. Гораздо чаще сложности возникают из-за неправильного порядка подготовки серверной части. Если делать всё по порядку, клиент обычно подключается с первого раза; если порядок нарушен, приходится снова и снова возвращаться в терминал и менять настройки.
Здесь рассматривается только серверная сторона: первый вход, ограничение доступа, запуск прокси-сервиса, открытие портов, подключение клиента и поуровневая диагностика, если соединение не устанавливается.
При первом входе сначала проверьте доступ
После создания экземпляра сначала войдите через веб-терминал в консоли провайдера и не полагайтесь сразу на локальные инструменты. На этом этапе нужно лишь убедиться, что сервер работает и сеть доступна.
После входа переключитесь на root, выполнив sudo -i и нажав Enter. Если приглашение изменилось с $ на #, повышение привилегий прошло успешно. Следующие действия выполняйте от этой учётной записи.
Сразу запишите четыре значения: публичный IP, имя пользователя для входа (в Linux по умолчанию root), пароль и порт SSH (по умолчанию 22). Именно эти четыре значения потребуются клиенту; если одного не хватает, подключение не состоится.
Смените стандартный порт, затем перейдите на вход по ключу
Порт 22 сканируют бесчисленное количество раз каждый день, а автоматические попытки входа — обычное явление. Смена порта сама по себе не делает сервер надёжнее, но отсеивает большую часть автоматизированного шума.
Изменения вносятся в /etc/ssh/sshd_config. Откройте файл через vi, нажмите i для перехода в режим редактирования, установите строки PermitRootLogin и PasswordAuthentication в yes, затем нажмите Esc и введите :wq, чтобы сохранить изменения и выйти. Если провайдер поддерживает вход по ключу, более надёжный вариант — добавить локальный открытый ключ в authorized_keys на сервере, а затем установить PasswordAuthentication в no, оставив только ключевую аутентификацию.
Не закрывайте текущий сеанс сразу после изменения конфигурации. Сначала откройте второе окно терминала, один раз войдите через новый порт и новым способом, убедитесь, что доступ работает, и только после этого закрывайте старое окно. Иначе ошибка в конфигурации может заблокировать доступ, и восстанавливать его придётся через консоль провайдера.
Порт SSH задаётся в строке Port. После изменения перезапустите службу SSH, чтобы настройки вступили в силу. В системах Debian и Ubuntu можно выполнить /etc/init.d/ssh restart.
Выполните базовое усиление защиты в первый же день
Помимо смены порта и использования ключей, в первый день стоит сделать ещё две небольшие вещи. Во-первых, задайте для root достаточно длинный случайный пароль с помощью passwd root и не используйте легко угадываемые сочетания. Во-вторых, отключите ненужные службы и порты. Чем меньше компонентов работает на машине, тем меньше поверхность атаки; системный брандмауэр должен разрешать только действительно необходимые порты.
Если сервер будет долго использоваться только из нескольких фиксированных исходных точек, ограничьте исходные адреса в группе безопасности этими точками. Это намного безопаснее, чем открывать доступ для всего интернета.
Установите прокси-сервис и настройте аутентификацию
После завершения первоначальной настройки сервера переходите к самому прокси.
Один вариант — напрямую использовать SSH-туннель. На сервер не нужно ничего дополнительно устанавливать: клиент использует встроенную системную службу SSH для пересылки трафика и те же учётные данные сервера. Это удобно, но производительность средняя, а при большом числе одновременных подключений возникают ограничения. Такой вариант подходит для временного использования или небольшого числа аккаунтов.
Другой вариант — установить на сервер отдельный прокси-сервис. Обычно для установки достаточно одной команды, после чего самостоятельно настраиваются способ аутентификации и порт прослушивания. Не забудьте включить автозапуск, иначе после перезагрузки сервера прокси перестанет работать.
Условно можно выделить три уровня аутентификации с возрастающей надёжностью: имя пользователя и пароль проще всего, но их утечка фактически отдаёт прокси постороннему; пароль плюс белый список исходных IP обычно достаточен для повседневной работы; аутентификация по ключу или сертификату наиболее надёжна, хотя требует больше настройки и оправдана для длительно работающих аккаунтов.
Откройте порт в двух разных местах
Именно здесь чаще всего возникают проблемы. Порт прослушивания прокси-сервиса нужно разрешить и в системном брандмауэре, и в группе безопасности провайдера. Эти два механизма независимы, поэтому открыть только один из них недостаточно.
Ещё одна настройка, о которой легко забыть, — адрес прослушивания сервиса. Некоторые сервисы по умолчанию привязываются только к 127.0.0.1. Если проверка на самом сервере проходит, а извне подключиться нельзя, причина часто именно в этом. Измените адрес прослушивания на внутренний адрес сервера или 0.0.0.0.
Подключитесь с локального клиента
Создайте новую среду в инструменте управления и выберите фактически используемый тип прокси. При SSH-туннеле адресом будет публичный IP сервера, портом — порт SSH, а именем пользователя и паролем — учётные данные сервера. После заполнения запустите проверку соединения.
Успешная проверка означает только, что сетевой путь работает. Откройте среду и проверьте ещё три вещи: выходной IP должен совпадать с публичным IP сервера; DNS тоже должен идти через прокси, потому что локальное разрешение DNS может раскрыть регион, не совпадающий с выходным IP; часовой пояс и язык должны соответствовать региону выхода. Только после прохождения всех трёх проверок среду можно считать готовой.
Когда аккаунтов станет больше, закрепите соответствие между каждой средой и её выходом, чтобы несколько аккаунтов не использовали одну среду. Инструменты вроде PurpleMark позволяют привязать отдельный выход к каждому аккаунту, что надёжнее ручного ведения таблицы соответствий.
Если соединение не устанавливается, проверяйте снаружи внутрь
Начните с внешнего уровня: открыт ли доступ в группе безопасности? Разрешён ли он в системном брандмауэре? Сначала подтвердите оба пункта и только потом двигайтесь дальше.
Затем проверьте сам сервис: работает ли процесс, особенно после перезагрузки сервера? Не привязан ли адрес прослушивания только к локальному интерфейсу?
Далее проверьте аутентификацию: не ошиблись ли в имени пользователя или пароле? Не слишком ли широкие права у файла ключа? SSHD напрямую отклоняет ключ, если права настроены неправильно. И только после этого проверяйте клиент: указан публичный IP или по ошибке внутренний IP? Эти адреса особенно легко перепутать.
При такой последовательности обычно за два-три прохода удаётся понять, на каком уровне находится проблема, вместо того чтобы снова и снова переустанавливать сервис.
Итог
Подготовка серверной стороны занимает меньше получаса, но именно она определяет, насколько беспроблемно машина будет работать в следующие месяцы. Ограничьте доступ, правильно откройте порты и чётко настройте аутентификацию; дальше останется только обычное обслуживание.
