Спрямуйте підмережу філії через інтернет-вихід SonicWall головного офісу

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

Почніть із селектора, а не з маршруту

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

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

Додайте політику філії, а потім захистіть її порядок

На SonicWall філії політика маршруту вибирає групу джерел, називає передбачувані призначення й задає інтерфейс тунелю як шлюз, і саме для цього існує підтримуваний дизайн інтерфейсу тунелю. Тримайте правила локальних і приватних призначень вище широкого інтернет-правила, бо перемагає перший збіг, а приватний префікс, проштовхнутий у тунель, доходить до головного офісу лише щоб бути відкинутим. Збережіть і власний маршрут міжмережевого екрана до його партнера VPN, інакше транспорт тунелю піде за політикою, від якої залежить. Ніщо з цього не змушує вас перетворювати кожен наявний тунель на основі політики; інтерфейс тунелю — один із кількох підтримуваних варіантів.

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

Завершіть шлях у головному офісі

Політика тунелю в головному офісі має приймати трафік, який тепер вибирає маршрут філії. Міжофісний селектор, обмежений приватною LAN головного офісу, не є дозволом нести довільні публічні призначення, тому політиці потрібні джерело філії та діапазон призначень, який ви справді маєте на увазі. Потім головний офіс пересилає цей вхідний трафік на свій інтернет-аплінк за власними правилами доступу, а приклад центрального виходу SonicWall включає трансляцію джерела для віддаленої мережі на центральному WAN. Без цієї трансляції віддалена сторона бачить приватну адресу філії й не має маршруту назад.

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

Вирішіть, що робить група, коли тунель падає

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

Узгодьте охоплення й пріоритет цього маршруту з установленим випуском і перевірте його, опустивши тунель, а не довіряючи мітці. Група, яка ніколи не повинна виходити локально, має відмовляти закрито, тоді як група, де доступність важливіша, може законно відкотитися; обидва — рішення, і жодне не повинно відбуватися за замовчуванням.

Перевірте з трьох клієнтів, потім чисто відкотіть

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

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

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

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