Маршрутизуйте трафік між приватними LAN, перш ніж додавати ще один NAT

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

Три умови, які визначають проєкт

Перша умова — адресний простір. Якщо обидві LAN використовують той самий блок RFC 1918, маршрутизація не може їх розрізнити, і трансляція стає неминучою, а не опційною. Друга — зворотний шлях: маршрут з A до B марний, якщо B також не знає, як дістатися до LAN вузла A, а асиметричне знання — найчастіша причина, чому маршрутизований проєкт мовчки відкидає відповіді.

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

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

Побудуйте план маршрутів на транзитній мережі

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

Екран A обслуговує 10.30.0.0/24, а екран B обслуговує 10.40.0.0/24, причому дві транзитні адреси розташовані в 192.0.2.0/24. Кожен хост LAN зберігає свій локальний екран як шлюз, тому єдиний новий стан — по одному маршруту з кожного боку. На екрані під керуванням Linux той самий план виглядає так, і пересилання має бути ввімкнене, інакше маршрут розв'яжеться, а пакет буде відкинуто.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Тримайте фільтрування окремо від трансляції

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

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

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Коли NAT — чесна відповідь

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

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

Коли сам транзит — хибне припущення

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

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