Практичний порядок підготовки сервера для власного проксі-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? Ці адреси особливо легко переплутати.
За такого порядку зазвичай за два-три проходи вдається визначити, на якому рівні проблема, замість багаторазового перевстановлення сервісу.
Підсумок
Підготовка серверної сторони займає менше пів години, але саме вона визначає, наскільки просто машина обслуговуватиметься в наступні місяці. Обмежте доступ, правильно відкрийте порти та чітко налаштуйте автентифікацію; далі залишиться лише звичайне обслуговування.
