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

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