Зошто 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 на тунелот ако пингот поминува, а големите преноси застануваат.

Пред да побарате помош, запишете три работи: адресата што сте ја обиделе и дали одговорила, транспортот и портот што сте ги користеле, и локалната подмрежа на мрежата што не успеа. Заедно тие го одвојуваат разрешувањето на имиња од филтрирањето на транспортот и од судирот на адреси, а тоа се причините што го издржуваат контактот со докази.