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 дрэнна паводзіць сябе на каналах са стратамі, а запасны варыянт патрабуе слухача, якім вы кіруеце. Выбірайце выпраўленне шляху, калі блакаванне стаіць на інфраструктуры, якой вы валодаеце, бо правіла міжсеткавага экрана таннейшае за другога слухача. У любым выпадку праходзьце ўзроўні па парадку: канал, знешні транспарт, пагадненне, унутраная маршрутызацыя. Этап, які не ўдаўся ў той сетцы, — гэта адзіны факт, які мае значэнне.

Запісвайце вынік па сетках, а не па карыстальніках. Наступная справаздача пра той жа збой тады пачынаецца з вядомага этапу, а не з тэорыі пра сертыфікаты. Гэты запіс таксама апраўдвае пастаяннага другога слухача, калі ён калі-небудзь спатрэбіцца.