proto udp чи tcp-client: який із них чує ваш сервер?

Профіль, який працював минулого місяця, тепер завершується за тайм-аутом, і хтось пропонує замінити proto udp на proto tcp-client. Іноді це правильний крок, а іноді виходить клієнт, що підключається до порту, де нічого не слухає, бо сервер ніколи не налаштовувався на інший транспорт. Директива описує, як говорить ваш бік; вона не може створити слухача на іншому боці. Прочитайте профіль і сервер разом, перш ніж змінювати будь-що з них.

Прочитайте транспорт, який використовує вибране з'єднання

Профіль може містити кілька записів remote, і кожен може вказати власний транспорт. Клієнт обробляє їх по порядку, тому рядок, який ви бачите першим, не обов'язково застосовується.

Знайдіть запис, який справді намагаються використати, а потім прочитайте його транспорт. Порядок важливий, бо клієнт не переходить до наступного мовчки. Деякі збірки пробують наступний запис лише після тайм-ауту, тому робоча альтернатива внизу файлу досягається на кілька секунд пізніше, ніж ви очікуєте. Стежте в журналі, яка кінцева точка намагається використатися, а не припускайте, що переміг перший рядок.

Якщо у файлі є один рядок proto ближче до початку і кілька записів remote нижче, цей рядок є значенням за замовчуванням для будь-якого remote, який його не перевизначає. Локальна правка значення за замовчуванням нічого не робить для запису remote, який указує власний транспорт.

grep -nE '^(remote|proto)\b' client.ovpn

UDP і TCP — не налаштування швидкості

UDP надсилає датаграми, не будуючи впорядкований потік, тому власний трафік тунелю не загортається в другий надійний транспорт. TCP дає шлях через мережі, які відкидають або блокують UDP, ціною вкладеної повторної передачі, яка може зробити з'єднання з втратами гіршим на дотик.

Це компроміс щодо доступності, а не універсальний рейтинг. Правильний вибір — той, який допускає мережа перед клієнтом. Шлях, що відкидає UDP на порту VPN, ніколи не домовиться, хоч би як добре був написаний профіль. Перевірте шлях, потім виберіть транспорт.

Вибирати між ними лише за вимірюванням — помилка, бо відповідь залежить від того, що допускає мережа перед вами. Готель або корпоративний проксі може дозволяти лише вихідний TCP на 443 і нічого більше, тому постачальники пропонують такий варіант. Це залишається з'єднанням OpenVPN на цьому порту, а не сеансом HTTPS, хоч номер порту й знайомий.

Що насправді означає tcp-client

Директива на боці клієнта називає кінець, що ініціює TCP-з'єднання. Серверний бік використовує свою форму прослуховування, і копіювання слова клієнта в конфігурацію сервера створює слухача, який очікує виклику, а не той, що приймає.

Збіг означає, що обидва боки домовляються про транспорт, а не те, що вони використовують той самий рядок.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Запитайте сервер, що він слухає, перш ніж вважати профіль неправильним. Слухач UDP не з'являється у списку TCP-сокетів, і навпаки теж правда, тому дивіться подання, специфічне для протоколу, а не загальне.

Коли профіль імпортується, але ніколи не підключається

Імпортований профіль, який одразу завершується за тайм-аутом, зазвичай зазнає невдачі ще до будь-якої автентифікації. Пакет іде на порт без слухача, або мережа мовчки його відкидає.

Перевірте шлях найпростішим способом: підключіться до того самого хоста й порту з транспортом, який заявляє профіль, з тієї самої мережі, що й клієнт, який зазнає невдачі.

Якщо перевірка UDP нічого не отримує, а перевірка TCP підключається, сервер пропонує інший транспорт, і профіль просто застарів. Якщо не відповідає жодна, проблема вище вибору транспорту, і жодна правка профілю її не виправить. Розрізнення цих двох випадків займає хвилину і заощаджує годину налагодження сертифікатів, яке ніколи не було доречним.

Запишіть робочий транспорт

Коли комбінація запрацює, запишіть її разом із сервером, портом і протоколом та зазначте, з якої мережі її перевіряли.

Інакше наступна людина, що зіткнеться з тайм-аутом, повторить той самий експеримент у зворотному напрямку і, можливо, змінить сервер, який був гаразд.

Якщо постачальник публікує обидва варіанти, збережіть обидва файли й позначте їх за мережею, для якої вони підходять. Два чітко названі профілі запобігають випадковому змішуванню клієнтського транспорту із серверним слухачем, який ніколи для нього не налаштовувався.