CIDR групи в Access Server: адреси учасників чи мережа ресурсів
CIDR групи може називати пул тунелю або цільову локальну мережу, і це ніколи не одне й те саме. Тримайте окремо розподіл, правила доступу й належність філій.
У групі Access Server два поля приймають CIDR і на перший погляд виглядають як один тип введення: одне описує адреси, які отримують учасники VPN, друге описує мережі, до яких ці учасники можуть дістатися. Заповнення не того поля приймається без помилки, і саме це робить помилку дорогою. Перше змінює план адресації тунелю, друге вирішує, які призначення дозволені, і жодне не передбачає іншого. Є й третій об єкт, який люди змішують із цими двома, підмережа за шлюзом філії, і вона не належить жодному полю.
Той самий синтаксис, інші питання
Запитайте, що називає значення. CIDR адрес учасників відповідає на питання, які внутрішні адреси отримують клієнти, що підключаються, і механізм розподілу витрачає його до того, як піде будь-який трафік. CIDR ресурсу відповідає, які призначення ця група може використовувати, і правила доступу витрачають його під час оцінки пакета. Одне це визначення пулу, друге це дозвіл.
Наслідки плутанини протилежні. Цільова локальна мережа, вставлена в поле пулу, може видавати адреси, які вже існують у цій мережі, і спричинити поведінку з дублюванням адрес, або зсунути пул так, що тихо зламаються всі правила брандмауера, написані під старий діапазон. Пул, вставлений у правило доступу, не дає нічого корисного, бо там не живе жодне призначення. Обидві помилки виглядають однаково: тунель піднятий, але щось не так.
Розподіл: адресний простір учасників
Пул не повинен перетинатися з жодною мережею, до якої може дістатися учасник, ні з іншим пулом VPN у розгортанні. Це обмеження проєктування, а не налаштування продукту: коли два майданчики використовують 10.90.40.0/24 для учасників, учасник одного майданчика не може маршрутизувати до іншого без трансляції, і жодне правило доступу це не виправить.
Режим розподілу теж важливий. Динамічний пул дає кожному учаснику наступну вільну адресу, а статичне призначення на користувача її закріплює. Статичне призначення потрібне, коли правила брандмауера або моніторинг посилаються на окремих учасників, і воно робить зміну плану адресації видимою: закріплена адреса все ще входить до нового пулу чи вже ні. Прочитайте адресу тунелю одного підключеного учасника до і після будь-якої зміни цього поля.
Дозвіл: мережі призначення живуть у правилах доступу
Досяжність виражається в правилах доступу, які називають групу або користувачів, цільову мережу чи сервіс і метод доступу. Саме остання частина це місце, де вмирає більшість недопрацьованих конфігурацій: правило може маршрутизувати трафік до призначення або виконувати NAT, і ці два вимагають від мережі різного. Маршрутизований шлях вимагає, щоб сторона призначення знала, як повернути трафік до пулу VPN, тоді як шлях NAT ховає учасників за адресою, якій призначення вже довіряє. Документація груп Access Server тримає мережу групи окремо від правил доступу групи, і підписи між випусками переміщалися.
Дозволене призначення все одно потребує робочого шляху. Правило дозволяє, маршрут доставляє, зворотний шлях відповідає, а сервіс на хості приймає. Чотири речі, чотири місця для перевірки, і лише перша живе в правилі доступу. Зелений дозвіл із мертвим traceroute зазвичай означає, що на шлюзі призначення немає зворотного маршруту, а не те, що правило неправильне.
Третій об єкт: підмережа філії за шлюзом
Оголосити, що конкретний клієнт володіє підмережею, це твердження про маршрутизацію майданчика, а не розподіл адрес і не дозвіл. У термінах Access Server це підтримувана конфігурація шлюзу для мережі, що підключається, і вона існує тому, що маршрутизатор філії може оголошувати мережу за собою. Учасники далі отримують адреси з пулу і далі потребують правила доступу, щоб користуватися цією мережею філії.
Тримати три речі окремо окупається під час перевірки. Підмережа філії, записана як адресний простір учасників групи, виглядає правильно на знімку екрана і ламає розподіл усім у групі. Та сама підмережа, записана лише в правилі доступу, дає доступ без твердження про належність, тож зворотному трафіку нікуди йти. Поставте кожен об єкт у свою колонку проєкту, і помилка стане неможливою.
Як зрозуміти, на що ви дивитеся
Читайте підпис разом із сусідами. Поле біля режиму розподілу, розміру пулу або винятку для користувача стосується розподілу. Поле біля вибору групи, сервісу чи порту і методу маршрутизації стосується дозволу. Випуски перейменовують речі, але сусіди залишаються приблизно на місці, тому текст старого знімка екрана це поганий навігаційний орієнтир.
Потім перевірте на одному учаснику, а не на всій групі: його чинну групу, призначену адресу тунелю і правило, що дозволяє потрібне призначення. Підтвердьте маршрут, NAT або маршрутизований шлях, зворотний трафік і дозвіл сервісу в цьому порядку і змінюйте лише те поле, яке відповідає доведеній розбіжності. Записи про розподіл і дозволи тримайте й далі окремо, щоб пізніша зміна пулу не читалася як зміна того, до чого група може дістатися.