Защо профил на OpenVPN работи у дома, но се проваля в хотел

Офис Wi-Fi и хотелска стая могат да дадат на един и същ лаптоп две много различни мрежи, а профилът между тях няма представа за това. Това, което работи у дома, предполага позволяваща възходяща връзка, работещо разрешаване на имена и локална подмрежа, която не се застъпва с нищо, което тунелът носи. Всяко от тези допускания може да се провали независимо.

Полезният начин да отстраните това е да третирате мрежата като четири отделни факта и след това да ги проверите по ред. Гадането по профила първо обикновено води до промяна, която не поправя нищо и замъглява доказателствата.

Четири мрежови факта се променят между локациите

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

Вторият е разрешаването на имена. Портал, който прихваща DNS, отговаря на всяка заявка със своя адрес, така че името на хоста на VPN се разрешава до портала и клиентът се опитва да изгради тунел до уеб страница.

Третият е филтрирането на транспорта. Мрежите, които искат да разрешат само разглеждане, пропускат TCP 443 до произволни дестинации и изхвърлят почти всичко останало, включително UDP.

Четвъртият е адресирането. Локалната подмрежа може да се застъпва с мрежа зад тунела или възходящата връзка може да не предоставя никакъв използваем път за IPv4.

Разрешаване на имена и портал за вход

Заменете името на хоста в профила с числовия адрес на сървъра и опитайте отново. Ако IP се свързва, а името не, вината е в разрешаването на имена и самият профил е наред.

Отворете браузър и опитайте обикновена HTTP страница, преди да докоснете VPN. Пренасочване към страница за вход означава, че порталът още чака; завършете го, след което се свържете отново. Много хотели също прекратяват сесията след няколко часа, което изглежда като прекъсване посред ден, а не като проблем с влизането.

Ако числовият адрес също се провали, разрешаването на имена не е обяснението, затова преминете към транспорта. Запазете адреса, който тествахте, защото той казва на следващата проверка дали пакетите изобщо са напуснали машината.

Филтриране на транспорта: първо UDP, TCP 443 като резерва

Поток на OpenVPN през UDP 1194 не изглежда като нищо, което хотелска защитна стена разпознава, затова се изхвърля без грешка. Клиентът опитва отново, докато изтече времето му за изчакване, и потребителят вижда връзка, която никога не се установява, а не отказ. Защитните стени, които се държат така, рядко записват изхвърлянето някъде, където можете да го видите. Липсата на отказ сама по себе си е уликата.

TCP 443 е надеждната резерва, защото мрежата не може да го различи от обикновен HTTPS. Използвайте TCP профила на оператора, когато има такъв, тъй като сървърът също трябва да слуша на този транспорт и порт; промяната само на клиента води до различен вид провал. Ако няма TCP профил, попитайте оператора, вместо да измисляте такъв чрез редактиране на порта. Страната на сървъра трябва да се съгласи и несъответствието отново изглежда като проблем със защитната стена.

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

Сблъсъци на адреси и възходящи връзки без IPv4

Тунелът може да се установи и пак да не носи нищо. Когато локалната LAN и отдалечена мрежа споделят префикс като 192.168.1.0/24, клиентът приема отдалечения хост за директно свързан и изпраща пакета към локалната връзка вместо към тунела. Симптомът е успешна връзка с една недостъпна подмрежа, което лесно се разчита като проблем с маршрута от страна на сървъра.

Трайното решение е отдалечената LAN да се премести в необичаен частен диапазон. Изборът на диапазон, който никой не използва у дома, като 10.42.0.0/24, предотвратява проблема за всяка бъдеща локация, а не за една. Локалното заобиколно решение е да избягвате онзи хотел, гореща точка или рутер, което изобщо не е решение.

Мобилните възходящи връзки добавят две разновидности. NAT на ниво оператор означава, че входящите връзки не пристигат, което има значение, ако хоствате сървър, но не за изходящ клиент. APN, конфигуриран само с IPv6 и транслация NAT64, може да провали клиент, който настоява за реален път IPv4, и обичайното решение е протоколът на APN да се смени на IPv4 или двоен стек.

Симптоми след вдигане на тунела

Тунел, който се свързва и след това замлъква, обикновено е проблем с keepalive или MTU, а не блокиран порт. Връзка, която пада след фиксиран брой минути, сочи към таймер за keepalive или предоговаряне. Настройте клиента да проверява партньора си и да рестартира, когато отговорите спрат, и тествайте по-малък MTU на тунела, ако пингът минава, а големите трансфери застиват.

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