Аддзяліце ўваходы праз Wi-Fi-партал ад уваходаў у VPN
Дзве розныя сістэмы просяць у вас уваход: Wi-Fi пляцоўкі і ваш VPN-шлюз. На экране яны падобныя, але дазваляюць цалкам рознае. Пытайце ў кожным акне: хто сапраўды можа праверыць гэты сакрэт?
Дзве розныя сістэмы просяць вас увайсці, перш чым вы дабярэцеся да чаго-небудзь карыснага ў публічнай сетцы: Wi-Fi пляцоўкі і ваш VPN-шлюз. На экране яны выглядаюць аднолькава і дазваляюць зусім рознае. Партал вырашае, ці можа гэта прылада карыстацца мясцовай сеткай; VPN вырашае, ці можаце вы дасягнуць прыватнай сеткі ў іншым месцы. Я трымаю іх асобна, задаючы ў кожным акне адно пытанне: хто сапраўды можа праверыць гэты сакрэт? Далей ідзе спіс праверкі, які я праходжу ў гатэлях, аэрапортах і на канферэнцыях, уключаючы моманты, калі я спыняю набор.
Супaстаўце кожны ўваход з службай, якая яго правярае
Адно гатэльнае злучэнне можа ўключаць чатыры асобныя праверкі, і толькі некаторыя просяць у вас уводу. Спачатку ўпарадкуйце іх, бо экран рэдка паведамляе, да якога этапу ён належыць.
| Stage | Who checks it | What you give it | What it proves |
|---|---|---|---|
| Wi-Fi association | The access point | WPA2 passphrase or 802.1X credentials | That the device may join this SSID |
| Portal authorization | The venue or its portal provider | Room number, booking name, voucher, email or access code | That a guest may use local access |
| VPN authentication | Your gateway or identity provider | Client certificate, password, one-time code or SSO approval | That the user or device may enter the private network |
| Application login | Each internal service | That service's own account | That you may use that service |
Сеткі 802.1X, распаўсюджаныя ў офісах і ўніверсітэтах, размываюць першыя два радкі. Там уваход у Wi-Fi сам па сабе з'яўляецца праверкай асобы супраць сервера RADIUS, і кліент можа прад'явіць маршрутную асобу, пакуль сапраўдны ўліковы запіс падарожнічае ўнутры зашыфраванага абмену. Нават тады праверка датычыцца далучэння да сеткі; яна не дазваляе тунель, і VPN-шлюз не прымае яе як доказ чаго-небудзь.
Парадак важнейшы за назвы. Парталы перахопу існуюць таму, што доступ можна даць пасля далучэння, і менавіта таму пляцоўка можа перадаць старонку спецыялізаванаму пастаўшчыку. RFC 8952 ад IETF разглядае партал як асобны кампанент, таму незнаёмы дамен — гэта прычына праверыць, а не доказ махлярства само па сабе. Параўнайце дамен з пісьмовымі інструкцыямі пляцоўкі, а палі — з табліцай.
Праверце, пра што парталу дазволена пытаць
Палі партала датычаць права, а не асобы: нумар пакоя, прозвішча браніравання, код ваўчара, код, надрукаваны на абгортцы ключа, электронная пошта для часовага пропуску, згода з умовамі. Пляцоўка ўжо ведае, хто забраніраваў пакой, таму можа супаставіць гэтыя факты, не даведаўшыся нічога, што дазволіла б ёй дзейнічаць ад вашага імя ў іншым месцы.
Усё, што выходзіць за гэты спіс, вартае паўзы. Старонка хотспота не можа праверыць ваш пароль дамена, як і не можа праверыць ваш аднаразовы код VPN, код аднаўлення або прыватны ключ, і ў яе няма прычын іх хацець. Адзінае законнае выключэнне — сетка, якую кіруе арганізацыя: гасцявы SSID офіса або Wi-Fi канферэнцыі могуць перадаць вас пастаўшчыку асобы, якога вы ўжо выкарыстоўваеце для працы. Яго ўсё яшчэ можна адрозніць: хост уваходу — ваш штодзённы, экран згоды называе вашага тэнанта, а працэс адкрываецца ў бачнай укладцы браўзера.
Маркетынгавая пошта — асобна: падарожны псеўданім задавальняе поле, не выдаючы вашу працоўную асобу.
Праверце, што VPN-кліент хоча ўласныя даныя для ўваходу
Кліент запытвае менавіта тое, на што наладжаны яго профіль, таму чаканае акно — уласцівасць профілю, а не сеткі, у якой вы апынуліся. Профілі з сертыфікатам звычайна паказваюць выбар профілю, а потым злучаюцца моўчкі. Профілі з імем і паролем запытваюць абодва, часта з аднаразовым кодам. Профілі SSO адкрываюць ваш браўзер да пастаўшчыка асобы і вяртаюцца з токенам. WireGuard зноў іншы: ён аўтэнтыфікуе прылады публічным ключом і не мае ўваходу карыстальніка, таму акно з імем і паролем WireGuard не апісвае WireGuard.
Прачытайце профіль перад паездкай. У OpenVPN auth-user-pass паведамляе, што чакаецца запыт пароля, а cert, key або pkcs12 значыць, што працу павінен рабіць сертыфікат. Калі профіль, які звычайна злучаецца без запыту, раптам просіць пароль, падазрайце профіль, які не змог загрузіць сертыфікат або перайшоў на іншы метад. Запыт — гэта не запрашэнне ўводзіць працоўны пароль у любое акно, якое з'явілася.
Ніводзін законны VPN-кліент не просіць нумар пакоя, ваўчар партала або парольную фразу Wi-Fi як уваход для аўтэнтыфікацыі. Калі гэта адбываецца, альбо кліент не той, за каго сябе выдае, альбо партал перахопу перахоплівае трафік да ўтварэння тунелю, і вы чытаеце старонку HTML, аформленую як уваход.
Спыніцеся на гэтых пяці ўмовах
Гэта моманты, у якіх я спыняюся, а не працягваю з праўдападобным абыходам. Кожны танна праверыць і дорага памыліцца.
- На партале або на старонцы SSO з'яўляецца папярэджанне аб сертыфікаце або TLS. Не пераходзьце праз яго, каб дабрацца да сеткі.
- Старонка просіць сакрэт, які можа праверыць толькі VPN-шлюз або пастаўшчык асобы: пароль дамена, аднаразовы код, код аднаўлення, прыватны ключ.
- Дамен не адпавядае надрукаваным інструкцыям пляцоўкі або хосту ўваходу, які ваша арганізацыя дакументуе для сваіх службаў.
- Вас просяць усталяваць каранёвы сертыфікат, профіль канфігурацыі або дапаможную праграму, якая не паходзіць з вашага кіравання прыладамі.
- Прыходзіць адабрэнне MFA, якое вы не пачыналі, або VPN-кліент просіць даныя гатэля.
Запасны шлях — не іншы пароль. Выкарыстайце кропку доступу тэлефона, спытайце на рэсэпшэне дакладную назву сеткі і спосаб доступу і паведаміце пра старонку таму, хто кіруе сеткай, або вашай ІТ-службе. Нішто з гэтага не патрабуе правяраць даныя для ўваходу на старонцы, якую вы не можаце атрыбутаваць.
Аднясіце збой да правільнага этапу
Пасля таго як абодва этапы пройдзены, збоі ўсё яшчэ здараюцца, і памылка звычайна называе этап, калі чытаць па парадку: далучэнне, прызначэнне адраса, аўтарызацыя партала, усталяванне тунелю, потым унутраны рэсурс. Змена пароля VPN праз сканчэнне кода партала марнуе час і пакідае сапраўдную праблему на месцы.
Некалькі праверкаў раздзяляюць этапы. Пасля ўваходу ў партал запытайце звычайную публічную старонку HTTPS. Калі замест яе вяртаецца партал, аўтарызацыя ніколі не завяршылася на гэтым узроўні. Калі VPN-кліент паведамляе, што не можа дасягнуць шлюза, праблема ніжэй за тунель: сесія партала, развязанне імёнаў або сетка, якая блакуе порт. Калі тунель узнімаецца, а адно ўнутранае імя хоста не працуе, развязанне імёнаў або палітыка ўнутры прыватнай сеткі — лепшы падазроны.
Сесіі партала таксама сканчаюцца незалежна ад тунелю. Калі пляцоўка адклікае доступ, усталяванае злучэнне VPN падае, хоць яго даныя для ўваходу ніколі не былі няправільнымі. Паўторна аўтарызуйце партал, потым перападключыце VPN і дайце яму перагаварыць нанова. Ратацыя пароля VPN тады нічога не выпраўляе і можа замкнуць вас знутры.
Дайце кожны сакрэт толькі той сістэме, якая можа яго праверыць, і лічыце запыт, які не адпавядае табліцы, знакам стоп, а не крокам, які трэба абысці. Калі абодва этапы пройдзены, а тунель усё яшчэ адмаўляе, зафіксуйце дакладную памылку кліента, перш чым змяняць любыя даныя для ўваходу.