Мейманкана Wi-Fi'де OpenVPN туташпайбы? TCP 443'тү сынап көрүңүз

Кардарды ачып, Туташууну басыңыз жана андан кийинки диалогдун ордуна статус сабын окуңуз. Мейманкана, кампус же уюлдук тармактан кийин Туташууда же Серверди күтүүдө токтоп калган профиль адатта жолдун бир жеринде ташуусун жоготкон болот, кирүү маалыматтарын эмес. Кийинки пайдалуу кадам — серверге тийишпестен мурун ал тармак эмнени ташыйарын билүү. Ошол эле профиль башка жерде иштегенге чейин эч нерсени өзгөртпөңүз.

Алгач телефон хотспотунан сынап көрүңүз. Эгер туннель ошол жерде көтөрүлсө, сервер, сертификат жана эсеп баары жайында, ал эми калган жалгыз өзгөрмө — алдыңыздагы тармак.

Кардардан баштаңыз: статус сабын окуңуз

Статус сабы кайсы баскыч ишке ашпаганын айтат. Туташууда кармалып калган кардар дагы эле хостту чечип жатат же сырткы сокетти ачып жатат; Серверди күтүүгө жеткен кардардын жолу бар, бирок жообу жок; ал эми аутентификациядан кийин кулап калган кардардын таптакыр башка көйгөйү бар. Кардар журналы жана профилдин өзүнүн remote жана proto талаалары кардар эмне кылууга аракет кылып жатканын көрсөтөт, ал эми буйрук сабынын кардарында --verb 4 ушундай эле деталды басып чыгарады. Муну алдыңыздагы тармак менен салыштыруу гана 'VPN бөгөттөлгөн' дегенди конкреттүү ырастоого айландырат.

Андан кийин колуңуздагы куралдар менен тармакты текшериңиз. nc -vzu 203.0.113.10 1194 UDP дейтаграммасын жөнөтөт, curl -v telnet://203.0.113.10:443 TCP кол алышуусу бүтөбү же жокпу деп билдирет, ал эми HTTPS баракчасын жүктөгөн браузер сыртка чыгуучу 443 ошол бир хостко жетээрин гана далилдейт. Кичинекей текшерүүлөр VPN кардары жооп бере албаган нерсеге жооп берет: кайсы порт жана кайсы протокол бул тармактан такыр чыгат.

Тармактын үч жүрүм-туруму кардар тараптан окшош көрүнөт жана ар башка жооп талап кылат. Сыртка чыгуучу 443 ачык болушу мүмкүн, проксиге гана уруксат берилиши мүмкүн, же 443 эмнени ташып жатканын окуй албаган текшерүү кутусуна тунук түрдө жөнөтүлүшү мүмкүн. Биринчиси төмөнкү профиль өзгөртүүсү менен, экинчиси прокси жөндөөлөрү менен оңдолот, ал эми үчүнчүсү кол алышууну бүтүрүп, анан текшерүүчүгө агым жакпай калганда токтоп калышы мүмкүн. Үчөөнүн кайсынысына туш болгонуңузду билүү — он мүнөттүк өзгөртүү менен кардарларды кайра орнотууга кетүүчү жарым күндүн айырмасы.

Угуучу менен профилди чогуу көчүрүңүз

Сервер тарапта угуучуну тармак уруксат берген нерсеге коюңуз: сервер конфигурациясында port 443 жана proto tcp, анан кызматты кайра баштап, сокетти ss -lntp менен ырастаңыз. Кардар тарапта профиль макул болушу керек, анткени ташуу жана порт туннелден тышкары турат: .ovpn ичинде proto tcp жана port 443, же колдонмо жөндөөлөр экранындагы тиешелүү талаалар. Дагы эле UDP 1194'кө багытталган профиль мурункудай эле ишке ашпайт, жана оңдолуп койгон файрволду күнөөлөө азгырыгы пайда болот. Эгер ошол эле хост 443'тө HTTPS'ке да жооп берсе, эки угуучу бул даректи жана протоколду бөлүшө албайт; VPN'ге экинчи дарек бериңиз же алдына демультиплексор коюңуз.

Биринчи туташууну эки учунда tcpdump -ni any port 443 менен көзөмөлдөңүз. Кардардан чыгып, эч качан жетпеген пакеттер тармак баары бир чыпкалап жатканын же профилдеги дарек сиз ойлогон дарек эместигин билдирет. Жоопсуз жеткен пакеттер сизди сервер журналына кайтарат, ал жерде протокол шайкешсиздиги дароо ыргытылган пакет катары көрүнөт.

Тармактан прокси гана чыкканда

Айрым конок тармактары HTTP проксиден башка эч нерсеге уруксат бербейт, бул жабык порттон башка чектөө жана OpenVPN'ден көбүрөөк нерсени четтетет. PPTP, L2TP/IPsec же жалаң IPsec гана сүйлөгөн кардарлар андан өтүүгө жолу жок, анткени ал долбоорлор өздөрүнүн сырткы протоколу серверге түз жетет деп күтөт. OpenVPN муну кыла алат, кардар профилинде http-proxy proxy.example.net 8080 менен, прокси портуңузга CONNECT ыкмасына уруксат берсе. SOCKS прокси андан да жеңил, анткени ал ичинде эмне бар экенине карабастан агымды өткөрүп жөнөтөт.

Кардарда прокси колдоосу жок болсо, 443 үстүндөгү SSH туннели адатта калат. Ал экинчи катмарды кошот, ал эми тармактын операторунун бул тууралуу пикири болушу мүмкүн, ошондуктан ага архитектура эмес, бир сапар үчүн көпүрө катары мамиле кылыңыз.

Камдык жолду кармап калбастан мурун баасын эсептеңиз

TCP ичиндеги TCP'нин белгилүү баасы бар. Сырткы туташуу TCP, пайдалуу жүк да TCP болгондо, жоголгон сегмент эки катмарда тең кайра жөнөтүүнү пайда кылат, ал эми ички туташуу өзү көрө албаган жоготуудан чегинет. Серептөө муну көтөрөт; интерактивдүү сессиялар менен чалуулар муну сезет. TCP 443 угуучусун аны талап кылган тармактар үчүн камдык жол катары кармаңыз, ал эми UDP'ни дагы эле өткөрүп жаткан бардык нерсе үчүн демейки бойдон калтырыңыз.

Тандоону профилдин атына жана колдоо жазууларына жазыңыз: кайсы порт, кайсы протокол жана кайсы тармак ага себеп болду. Андан кийин тармактын администраторунан кийинки жабдуу жаңыртуусунан кийин да бул порт ачык калабы деп сураңыз, анткени үнсүз жок болуп кеткен камдык жол такыр жок болгондон жаман.