Яку адресу бачить хмарний міжмережевий екран, коли VPN увімкнено
Повний тунель змінює адресу джерела, яку бачить ваша база даних. Перемістіть список дозволених, приватний шлях або розділений тунель, а не облікові дані.
База даних, яка працює до підключення VPN і відмовляє після, рідко буває проблемою облікових даних. Хмарні міжмережеві екрани зіставляють адреси джерела, а повний тунель замінює саме ту адресу, з якою вони зіставляли. Різниця між тим, що, на вашу думку, надсилає ноутбук, і тим, що отримує сервер, і є вся помилка, і її можна виміряти за один крок.
Чим стає адреса джерела
У повному тунелі кожен пакет виходить через VPN-шлюз, тому сервер бачить вихідну адресу шлюзу, а не ваше домашнє підключення. Якщо на шляху стоїть прямий проксі, надходить його адреса. Обидва — законні джерела, і жоден не є адресою з вашого початкового правила.
Правила міжмережевого екрана Azure SQL на рівні сервера й на рівні бази даних зіставляють адресу клієнта, що досягає логічного сервера, а після повного тунелю це вихідна адреса. Група безпеки AWS, що дозволяє одну адресу, поводиться так само. Пакет відкидається до автентифікації, тому помилка, яку ви отримуєте, виглядає як збій мережі, а не як проблема з правами. Саме тому люди починають скидати паролі.
Де вирішується список дозволених
Читайте правило, що відповідає шляху, який не працює, а не те, яке ви пам’ятаєте як створене. Зверніть увагу на його межі, порт, протокол і на те, чи оцінюється воно до будь-якої перевірки особи.
Потім вирішіть, який рівень законно володіє цим рішенням. Правило адреси відповідає, звідки надходить трафік. Приватна кінцева точка відповідає, чи доступна служба взагалі приватним шляхом. Виняток для розділеного тунелю відповідає, які призначення обходять тунель. Вони не взаємозамінні, і кожне відмовляє по-своєму, коли тунель змінюється.
Три виправлення, три рівні
Кожен варіант нижче виправляє потік з власної причини, а неправильний вибір дає з’єднання, яке працює до наступної зміни шлюзу.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
Додавання вихідної адреси — найменша зміна й найкрихкіша, бо новий шлюз або інший регіон тихо її знецінюють. Задокументуйте адресу поряд з визначенням тунелю, щоб вони рухалися разом. Тимчасовий широкий діапазон — це діагностика, а не виправлення; залишати його на місці — шлях до того, що внутрішні служби виявляться відкритими.
Чому керована платформа не може приєднатися до тунелю
Платформи застосунків на кшталт Heroku, AppHarbor або CloudBees запускають ваш код у середовищі без пристрою tun або tap і без прав створити його. Їхня модель вхідного трафіку — HTTP, а не довільний сокет, що слухає. Пакет збирання, який постачає двійковий файл VPN, усе одно не має куди подіти інтерфейс. Робочі схеми — статична вихідна адреса, яку база даних може дозволити, продукт приватного з’єднання від платформи або проксі в DMZ, доступний через HTTPS.
Цей проксі — шлях доступу з власною автентифікацією та журналюванням. Він не робить платформу учасником вашого VPN, і такий опис породжує правила, які ніхто не може перевірити.
Перевірте з боку клієнта, що зазнав невдачі
Перепідключіться й повторіть точний шлях клієнта. Перевірте адресу джерела, яку записує служба, маршрут, який клієнт вибирає для імені бази даних, і результат фактичного запиту — саме в цьому порядку. Тест зі шлюзу доводить, що шлюз працює, а це ніколи не було сумнівом. Якщо з’єднання тепер автентифікується, а запит усе ще не працює, залишкова проблема — дозвіл у базі даних.
Переглядайте ці правила щоразу, коли тунель змінюється. Замінений шлюз або новий вихідний діапазон ламають шлях без жодних змін у конфігурації застосунку.