OpenVPN работи у дома, но не в една мрежа: UDP или TCP?

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

Кой етап е отказал показва кое сравнение има значение

Дневникът на клиента вече записва докъде сте стигнали. Ред, който казва, че договарянето на TLS ключ не се е случило в рамките на изчакването, означава, че първият пакет е излязъл и нищо използваемо не се е върнало, което сочи към пътя. Отхвърлянето на сертификат изглежда съвсем различно: пристига отговор, после конкретна грешка при проверка назовава причината. Отбележете последния ред преди цикъла за повторение, защото това е стойността, която сравнявате между мрежите.

Снимайте, докато повтаряте, а не след това. На клиента tcpdump -ni any udp port 1194 показва дали изобщо се връща някакъв отговор. Повторете го на WAN интерфейса на сървър, който контролирате, което разкрива дали тези пакети изобщо стигат до далечната страна.

Едностранният трафик е най-полезният резултат, наличен тук, защото превръща нередовното оплакване в посока за разследване. Пазете файловете със снимки, защото следващият доклад за същия проблем се затваря по-лесно с доказателство, отколкото с описание.

UDP филтриране срещу затворен порт

Много мрежи за достъп смятат продължителния UDP за подозрителен и някои ISP са съгласни с тях. Затвореният порт дава същото мълчание от страна на клиента. Разликата е в избирателността: филтърът е склонен да подбира кои дестинации или портове изхвърля, докато затвореният порт отказва всичко, насочено към този един порт.

Профил по TCP на порт 443 е обичайното решение, защото наподобява обикновен HTTPS поток и минава през повечето captive портали и филтри за изход. Трябва да са изпълнени две условия. Сървърът трябва да слуша с proto tcp-server и клиентът трябва да съответства с proto tcp-client, а операторът трябва да публикува тази алтернативна крайна точка. Пренаписването на работещ UDP профил, за да претендира TCP 443, не стига доникъде, когато никой не слуша от другата страна.

Затвореният порт е проблем с конфигурацията, а не с цензурата. Сървър зад домашен рутер се нуждае от пренасочване на UDP порта и защитната стена на рутера трябва да го разреши. Когато портът никога не е бил разрешен, всеки клиент се проваля при договарянето независимо от данните за достъп и отказът следва сървъра, а не мрежата.

По-старите протоколи се сравняват зле по тази ос. PPTP изисква TCP 1723 плюс GRE, а GRE е IP протокол 47, а не порт, така че никое обикновено пренасочване на порт не го изразява.

Когато комутаторът е този, който изхвърля пакети

Управляван комутатор може да изхвърли тунела нарочно. Някои модели HPE и Aruba показват в раздела за разширена сигурност контрол за защита от UDP флуд, понякога обозначен Prevent UDP Blat Attack. Щом този контрол е активен, сървър зад комутатора не отговаря с нищо и всеки клиент изтича по изчакване по същия начин. Изчистването му и запазването на текущата конфигурация е цялата поправка, но само след като установите, че комутаторът наистина е по пътя.

Обратните доказателства са това, което отделя отпадането при комутатора от блокиране от доставчик. Прочетете броячите на интерфейса и дневника за защита от флуд, преди да отворите билет при ISP. Потребителските рутери със защита от DoS или флуд се провалят по същия начин, както и всяко междинно устройство с кратко изчакване за бездействие на UDP. Ръкостискане, което никога не завършва, сочи към отпадане, докато тунел, който умира след минути тишина, сочи към изчакването.

Запишете всяко устройство между клиента и сървъра, преди да променяте профил. Поправка, приложена на грешния слой, изглежда вярна до следващата мрежа. Този списък също казва на следващия инженер къде да гледа, без да повтаря цялото разследване.

Припокриване на адреси, което изглежда като отказ на DNS

Мрежа за достъп, номерирана в 10.0.0.0/8, може да се припокрие с пула на тунела и резолверът обикновено живее в този пул. Когато лаптоп получи адрес като 10.184.178.50 с маска /8 по Wi-Fi, всяка дестинация 10.x е локална по определение. Пакетите за 10.4.0.1 тогава отиват в LAN, тунелът остава вдигнат и разрешаването на имена се проваля.

ip addr разкрива припокриването с един поглед, а ip route get 10.4.0.1 показва къде пакетът наистина ще бъде доставен. Тъй като видимият симптом е отказ на резолвера, този случай често преживява няколко кръга промени по DNS.

Преномерирайте пула или дръжте тази мрежа за достъп извън обхвата. Никаква настройка от страна на клиента не се възстановява от припокриване.

Избор между резервен TCP и поправка на пътя

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

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