Один 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 зручним, поки правило про джерело залишається рішенням, а не здогадом.