Адзін URL для офіса і VPN? Чаму міф пра белы спіс не працуе
VPN-злучэнне не змяняе адрас, які бачыць сайт з дазволеным доступам. Праверце рэальны выхад, давераны проксі-скачок і шлях IPv6, перш чым дадаваць URL.
Падключыце тунель, адкрыйце тую ж закладку — і сайт з дазволеным доступам адказвае гэтак жа, як з офіса. Менавіта на гэтым маўкліва трымаюцца большасць планаў аддаленага доступу, і гэта праўдзіва толькі тады, калі тры розныя рэчы застаюцца праўдзівымі адначасова. Ні адна з іх не з’яўляецца функцыяй VPN-кліента, і ні адзін запіс DNS не можа забяспечыць хоць адну з іх. Калі закладка не працуе дома, браўзер выдае адну агульную памылку, незалежна ад таго, ці прычына ў адсутным маршруце, недазволеным адрасе выхаду ці проксі, які падмяніў крыніцу, пра якую паведамляе. Стаўленне да гэтых трох як да адной праблемы — гэта шлях, якім дробная праўка палітыкі ператвараецца ў тыдзень пашырэння белых спісаў.
Дызайн, які вытрымлівае сутыкненне з рэальнай офіснай сеткай, вузейшы за гэта дапушчэнне: яўная табліца рашэнняў з трох радкоў, адзін пункт прытрымлівання, які немагчыма абыйсці, і тэст адмовы, які нешта даказвае. Разбор дапушчэння ідзе першым, бо усё пасля яго залежыць ад разумення таго, які ўзровень няправільна падае крыніцу.
Міф: падключэнне — гэта не маршрутызацыя
Тунель усталёўваецца, і кліент усталёўвае маршруты для некаторага набору прэфіксаў. Гэта ўсё, што робіць падключэнне. Ці пойдзе непаўрозаны запыт HTTPS праз тунель і з якога публічнага адраса ён выглядае, што прыйшоў, — гэта рашэнні, якія пазней прымаюць іншыя кампаненты: табліца маршрутызацыі выбірае шлях, а выхад выбірае крыніцу.
Менавіта таму офіс і кухонны стол разыходзяцца пры тым жа ноўтбуку, тым жа прафілі браўзера і той жа закладцы. У офісе запыт выходзіць праз агульнадаступны адрас, які падтрымліваецца і з якім пагадзіўся ўладальнік сайта. Праз поўны тунель ён можа выйсці праз VPN-выхад — іншы адрас і, пакуль нехта яго не дадасьць, недазволены. Праз раздвоены тунель ён можа ўвогуле не трапіць у тунель. Толькі два з гэтых трох шляхоў калі-небудзь былі часткай дамоўленасці з уладальнікам сайта, а трэці — не хіба, якую трэба залатаць дадатковым радком allow.
Тры станы запыту, два дазволеныя выхады
Запішыце матрыцу да таго, як кранаць файрвол, бо табліца — гэта дызайн, а правіла — толькі адна яго рэалізацыя. Адрасы ніжэй — дыяпазоны дакументацыі; замяніце іх сваімі падтрымліванымі значэннямі і трымайце там, дзе ўладальнік сайта зможа іх праверыць.
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
Менавіта сярэдні радок звычайна ламае гэтыя планы. Важны адрас, які бачыць прылада прытрымлівання, а не прыватны адрас, які ноўтбук трымае ўнутры тунеля, і не яго адрас у лакальнай сеткы. Значэнне накшталт 10.8.0.6 для публічнага сайта нічога не значыць, як і 192.168.1.44. Адрас тунеля — гэта дэталь адрасацыі тунеля, а не пасведчанне, якое сайт можа праверыць.
Калі ваш VPN не можа забяспечыць стабільны, дакументаваны выхад, у матрыцы няма слушнага сярэдняга радка, і ніякая колькасць белых спісаў яго не прыдумае. Сумленныя варыянты ў такі момант — прыватны сайт, дасяжны праз яўныя прыватныя маршруты, або шлюз доступу з улікам ідэнтычнасці перад праграмай. Абодва маюць іншы кантракт, чым публічны белы спіс, і абодва прасцей патлумачыць аўдытару, чым спіс, які рос, пакуль выпадкова не пачаў працаваць.
Чытайце крыніцу там, дзе прымаецца рашэнне
Змясціце абмежаванне на прыладу, якая завяршае запыт, і пераканайцеся, што ніякі альтэрнатыўны шлях узнікнення яго не абыходзіць. Модуль доступу Nginx ацэньвае дырэктывы allow і deny па парадку, першае супадзенне перамагае, а правілы, успадкаваныя з вонкавага блока, працягваюць дзейнічаць унутры location. Вузкі allow побач з шырокім allow у тым жа месцы звычайна азначае, што вырашае шырокі. Прачытайце ўсю дзейную канфігурацыю для гэтага location, перш чым правіць хоць адзін яе радок.
server {
listen 443 ssl;
server_name intranet.example.com;
set_real_ip_from 10.20.0.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location /app/ {
allow 203.0.113.24; # office public exit
allow 198.51.100.77; # approved VPN egress
deny all;
proxy_pass http://app_backend;
}
}
За балансіроўшчыкам навантажэння або зваротным проксі гэтае правіла бачыць проксі, калі вы не скажаце яму інакш. Аднаўляйце адрас выклікальніка толькі праз падтрымліваемы механізм даверанага проксі, з яўным спісам адрасоў проксі. Загаловак запыту, які заяўляе дазволены адрас, не з’яўляецца доказам, што выклікальнік ім валодае, а на публічным слухачы неправераны перададзены загаловак ператварае белы спіс у ўпрыгожанне.
Затым праверце іншае сямейства адрасоў. Набор правілаў, які ахоплівае толькі IPv4, — няпоўнае рашэнне для імя хоста, якое таксама адказвае на AAAA, і кліент з працоўным IPv6 дасягне той жа праграмы шляхам, які вы ніколі не разглядалі.
Раздвоены тунель: запыт, які не ўваходзіць
Раздвоены тунель нясе толькі прэфіксы за свайго спіса. Унутраныя офісныя падсеткі звычайна трапляюць у гэты спіс; публічны вэб-сайт — не. Браўзер вырашае імя, параўноўвае выбраны адрас з табліцай маршрутызацыі і ўсё ж знаходзіць лакальны шлюз па змаўчанні перад сабой.
Такім чынам, запыт прыходзіць з хатняга злучэння карыстальніка, атрымлівае адмову, і справаздача сцвярджае, што VPN зламаны, хаця тунель робіць менавіта тое, для чаго быў наладжаны. Дзве праўкі законныя: накіраваць гэтую мэту праз тунель і дазвольце дазволенаму выхаду яе несці або прызнайце, што сайт дасягаецца наўпраст, і дайце аддаленым карыстальнікам іншы дазволены шлях, напрыклад шлюз доступу. Пашырэнне публічнага белага спіса сайта, пакуль ў яго выпадкова не трапіць хатні адрас, — ні тое ні другое, і яно здымае мяжу, якую дызайн павінен быў ахоўваць. Першыя дзве трымаюць матрыцу сумленнай; трэцяя маўкліва выдаляе з яе радок.
Дакажыце адмову, потым — аднаўленне
Тэстуйце запытам, які запускае сапраўднае рашэнне, з кліента, які стаіць на кожным радку табліцы. Праверка дасяжнасці нейкай непаўрозанай старонкі, што паказвае адрас, нічога не даказвае, бо гэтая мэта можа ісці іншым маршрутам, чым праграма.
curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'
Параўнайце запіс доступу на мяжы з тым, што прадказала табліца. Затым апусціце тунель і зрабіце новы запыт, які павінен быць адхілены; ужо загружаная старонка або ужо адкрытае злучэнне не правяраюць нічога. Калі адмова не з’яўляецца, пункт прытрымлівання не там, дзе вы думаеце.
Пакідайце аўтэнтыфікацыю праграмы пасля допуску ў сетку, бо офісны выхад і VPN-выхад кожны стаіць за многімі людзьмі і ні адзін не ідэнтыфікуе чалавека. Інструкцыя для карыстальнікаў застаецца кароткай: падніміце дазволены тунель, затым паўтарыце спробу. Менавіта гэта захоўвае адзін URL зручным, пакуль правіла крыніцы застаецца рашэннем, а не здагадкай.