Відмова Firebox за геолокацією: спершу знайдіть етап входу VPN

Хтось в іншій країні не може підключитися, і перший порив — подивитися на правило, яке надає доступ до внутрішніх ресурсів. Це правило виконується після допуску, тому воно не може бути тим, що відхиляє тунель. Блоківний етап десь на шляху входу, і Firebox має більше ніж один шлях входу залежно від служби VPN. Виконуйте перевірки по порядку і зупиняйтеся, щойно одна з них пояснить відмову.

Перевірка 1: назвіть вхідну службу

Для Mobile VPN з SSL, Access Portal і BOVPN поверх TLS вхідним входом є політика WatchGuard SSLVPN. Застосуйте передбачене обмеження саме там, на фактично налаштованій службі, а не виводьте його з правила доступу користувача, яке виконується пізніше.

IPsec іде іншим шляхом. Вбудована політика IPSec дозволяє зовнішній трафік IPsec до Firebox для відповідних служб branch і мобільного VPN, і вона має пріоритет над політикою IPSec, створеною вручну. Якщо ваш клієнт — IKEv2, ви на цьому другому шляху, і політика SSLVPN не має значення.

Помилитися тут — це найпоширеніший змарнований пообідок у цій сфері: редагувати політику, яка ніколи не бачить пакета, а потім зробити висновок, що обмеження не працює.

Перевірка 2: читайте відмову, а не теорію

Зробіть одну контрольовану дозволену спробу і зіставте чотири речі: публічну адресу джерела клієнта, службу входу, яку він зачепив, політику, що збіглася, і будь-яку причину Deny у журналі. Настанови WatchGuard щодо усунення несправностей IKEv2 зазначають, що геолокація та обробка пакетів за замовчуванням можуть відхилити трафік ще до допуску вбудованою політикою, а отже відмова, яку ви бачите, може називати етап, який ви не розглядали.

Класифікація країни йде за спостережуваним мережевим джерелом. Роумінг-користувач, вихідний NAT або інший схвалений шлях можуть змінити те, що бачить Firebox, тому підтверджуйте адресу, а не опис користувача про те, де він. Попросіть публічну адресу, яку бачить клієнт, і порівняйте її з джерелом у журналі Firebox. Коли вони різняться, класифікація йде шляхом, про який ніхто не згадав.

Перевірка 3: чи вбудована політика досі власник?

Якщо здається, що ручну політику IPSec ігнорують, перевірте, чи вбудована ще ввімкнена. Ручне правило, затінене вбудованим правилом вищого пріоритету, і ручне правило, яке є єдиним допуском, — це різні конфігурації з однаковим на вигляд інтерфейсом.

Вирішіть, яке з них має володіти шляхом. Якщо це ручна політика, вбудовану треба вимкнути для цього трафіку, і саме там починається наступна перевірка.

Перевірка 4: сплануйте заміну перед вимкненням

Вимкнення вбудованої політики IPSec прибирає її допуск для уражених служб VPN. Це включає тунелі branch, про які ви можете не думати, поки лагодите з'єднання одного мобільного користувача.

Спершу сплануйте повну заміну: які служби потребують допуску, які діапазони джерел вони отримають і як ви керуватимете пристроєм, якщо зміна піде не так. Тримайте відкритим незалежний шлях керування та відновлення, бо помилка тут може прибрати тунель, який ви використали б, щоб це виправити. Запишіть кроки відновлення в запис про зміну, зокрема як дістатися до пристрою, якщо шляху VPN немає. Потім перевірте поновлення, а не лише перше з'єднання.

Активна зв'язність і пізніше повторне узгодження можуть обидва залежати від допуску. Зміна, яка працює для перевіреної сесії й зазнає невдачі на наступній зміні ключа, — класичний результат заміни допуску без перевірки поновлення.

Перевірка 5: тримайте ідентичність окремо від розташування

Геолокація додає контекст до рішення про вхід. Вона не встановлює, хто користувач, і не повинна замінювати перевірки ідентичності шлюзу, авторизацію облікового запису чи MFA.

Якщо бізнес-вимога — лише схвалені користувачі зі схвалених місць, вам потрібні обидва засоби контролю. Правило розташування, яке допускає цілу країну, не замінює автентифікацію, а автентифікований користувач у заблокованій країні — це питання політики, а не помилка.

Перевірка 6: зафіксуйте це й перевірте обидва шляхи

Запишіть службу, політику входу, передбачений обсяг розташування, винятки та власника відновлення. Потім перевірте мобільний шлях і принаймні один шлях до сайту після зміни, щоб обмеження лишалося прив'язаним до служби, для якої його призначено.

Насамкінець перечитайте відмову, з якої ви почали. Якщо вона змінилася з відмови за розташуванням на збій автентифікації чи авторизації, проблему входу вирішено і тепер видно іншу. Настанови WatchGuard щодо відмов IKEv2 — це довідка для порядку етапів, описаного вище.