Един URL за офис и VPN? Защо митът за списъка с разрешени не издържа

Свържете тунела, отворете същия показалец и сайтът от списъка с разрешени отговаря точно както от офиса. Това е предположението, на което повечето планове за отдалечен достъп тихо разчитат, и то е вярно само докато три отделни неща остават верни едновременно. Никое от тях не е функция на VPN клиента и нито един DNS запис може да осигури което и да е от тях. Когато показалецът се провали у дома, браузърът ви дава една обща грешка, независимо дали причината е липсващ маршрут, неодобрен изходен адрес или прокси, заменило източника, който съобщава. Да се отнасяме към тези три като към един проблем е начинът, по който малка поправка в политиката се превръща в седмица разширяване на списъци с разрешени.

Дизайнът, който оцелява при среща с истинска офис мрежа, е по-тесен от предположението: явна таблица на решенията с три реда, една точка за налагане, която не може да бъде заобиколена, и тест за отказ, който доказва нещо. Разглобяването на предположението идва първо, защото всичко след него зависи от знанието кой слой представя източника погрешно.

Митът: свързването не е маршрутизация

Тунелът се установява и клиентът инсталира маршрути за някакъв набор от префикси. Това е цялото действие на свързването. Дали несвързана HTTPS заявка ще мине през тунела и от кой публичен адрес изглежда, че идва, когато пристигне, са решения, взети по-късно от други компоненти: таблицата за маршрутизация избира пътя, а изходът избира източника.

Затова офисът и кухненската маса се разминават с един и същ лаптоп, един и същ профил на браузъра и един и същ показалец. В офиса заявката излиза през поддържан публичен адрес, с който операторът на сайта се е съгласил. През пълен тунел тя може да излезе през VPN изхода, който е различен адрес и, докато някой не го добави, неодобрен. През разделен тунел тя може изобщо да не влезе в тунела. Само два от тези три пътя някога са били част от договорката със собственика на сайта, а третият не е дефект, който да се закърпи с допълнителен ред allow.

Три състояния на заявката, два одобрени изхода

Запишете матрицата, преди да пипате защитна стена, защото таблицата е дизайнът, а правилото е само едно негово изпълнение. Адресите по-долу са документационни диапазони; заменете ги със свои поддържани стойности и ги пазете някъде, където собственикът на сайта може да ги одитира.

Средният ред е мястото, където повечето от тези планове се чупят. Значение има адресът, който вижда устройството за налагане, а не частният адрес, който лаптопът държи вътре в тунела, и не неговият LAN адрес. Стойност като 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 удобен, докато правилото за източника остава решение, а не догадка.