pfSense, вихідний NAT: спершу прочитайте створені правила

Відкрийте Firewall, потім NAT, потім Outbound і прочитайте режим, перш ніж щось додавати. У режимі Automatic pfSense створює правила для інтерфейсів WAN і, серед них, для мереж VPN віддаленого доступу, тож пул, який ви збираєтеся додати, часто вже покритий. Відсутність рядка, написаного вручну, не доводить відсутність перекладу. Порядок нижче не дасть вам перевести весь міжмережевий екран у режим Manual заради одного пулу.

Режим визначає, хто підтримує переклад для кожної іншої мережі на пристрої, і це більше рішення, ніж один виняток для VPN.

Режим Automatic уже покриває пул VPN

Кожен режим має свого власника. Automatic створює правила для інтерфейсів WAN і включає мережі VPN віддаленого доступу до своїх джерел. Hybrid зберігає ці створені правила й дозволяє додавати поруч ручні. Manual перестає щось створювати, тож кожен переклад на міжмережевому екрані стає вашою відповідальністю, зокрема ті, яких ви не писали. Четверте налаштування повністю вимикає вихідний NAT. Рядок, що виглядає написаним вручну, нічого не доводить, доки ви не знаєте, який режим активний.

У режимах Automatic і Hybrid сторінка також показує створені правила. Прочитайте їх, перш ніж робити висновок, що пул VPN не має перекладу: шукайте мережу пулу в стовпці джерела, а інтерфейс WAN — у стовпці інтерфейсу.

Обирайте Hybrid лише для перевіреного винятку

Документований виняток усе ще можливий, коли політика виходу справді відрізняється. Уявіть сервер, який роздає 10.90.0.0/24, де міжмережевий екран має забезпечувати вихід в інтернет за IPv4, а маршрутизація вже обирає WAN. Очікуване перетворення — джерело 10.90.0.23 переписується на адресу WAN. Перевірте, чи вже робить це створене правило на тому виході; якщо ні, Hybrid зберігає автоматичне покриття й додає ваше перевірене правило.

Використовуйте як джерело реальний пул VPN або підтримувану для нього псевдонімну назву і ніколи не обирайте не пов'язану адресу лише тому, що імені екземпляра OpenVPN немає у списку вибору. Уникайте джерела any, яке також перекладає трафік, що створює сам міжмережевий екран.

Не переводьте весь міжмережевий екран у режим Manual через один пул. Це рішення перерозподіляє обслуговування для кожної внутрішньої мережі й кожної майбутньої зміни WAN.

NAT не обирає вихід

Маршрутизація обирає інтерфейс виходу; правило вихідного NAT лише описує, як джерело переписується після виходу пакета. Зіставлення для WAN не змушує пакет, який маршрутизація надіслала в інше місце, іти через WAN, тому додавання NAT не може виправити неправильний маршрут. Перегляньте також застосовні записи NAT 1:1 та винятки, бо порядок важливий і новий рядок не обов'язково перемагає. І сторінка вихідного NAT — не сторінка фільтрації.

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

Доведіть перетворення на новому з'єднанні

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

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