Падключыце тунель, адкрыйце тую ж закладку — і сайт з дазволеным доступам адказвае гэтак жа, як з офіса. Менавіта на гэтым маўкліва трымаюцца большасць планаў аддаленага доступу, і гэта праўдзіва толькі тады, калі тры розныя рэчы застаюцца праўдзівымі адначасова. Ні адна з іх не з’яўляецца функцыяй VPN-кліента, і ні адзін запіс DNS не можа забяспечыць хоць адну з іх. Калі закладка не працуе дома, браўзер выдае адну агульную памылку, незалежна ад таго, ці прычына ў адсутным маршруце, недазволеным адрасе выхаду ці проксі, які падмяніў крыніцу, пра якую паведамляе. Стаўленне да гэтых трох як да адной праблемы — гэта шлях, якім дробная праўка палітыкі ператвараецца ў тыдзень пашырэння белых спісаў.

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

Міф: падключэнне — гэта не маршрутызацыя

Тунель усталёўваецца, і кліент усталёўвае маршруты для некаторага набору прэфіксаў. Гэта ўсё, што робіць падключэнне. Ці пойдзе непаўрозаны запыт HTTPS праз тунель і з якога публічнага адраса ён выглядае, што прыйшоў, — гэта рашэнні, якія пазней прымаюць іншыя кампаненты: табліца маршрутызацыі выбірае шлях, а выхад выбірае крыніцу.

Менавіта таму офіс і кухонны стол разыходзяцца пры тым жа ноўтбуку, тым жа прафілі браўзера і той жа закладцы. У офісе запыт выходзіць праз агульнадаступны адрас, які падтрымліваецца і з якім пагадзіўся ўладальнік сайта. Праз поўны тунель ён можа выйсці праз VPN-выхад — іншы адрас і, пакуль нехта яго не дадасьць, недазволены. Праз раздвоены тунель ён можа ўвогуле не трапіць у тунель. Толькі два з гэтых трох шляхоў калі-небудзь былі часткай дамоўленасці з уладальнікам сайта, а трэці — не хіба, якую трэба залатаць дадатковым радком allow.

Тры станы запыту, два дазволеныя выхады

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

Request pathSource the site seesIntended decision
Office, no tunnelOffice public exitAdmit to the application login
Remote, approved full tunnelApproved VPN egressAdmit to the same login
Remote, ordinary connectionNeither approved addressDeny 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 зручным, пакуль правіла крыніцы застаецца рашэннем, а не здагадкай.

Падобныя артыкулы