Маскарадинг або маршрутизація за політикою: трафік LAN через VPN-шлюз

Розмістити всю локальну мережу за VPN-тунелем — проста частина; вирішити, як далекий бік бачить цих клієнтів, — ні. Маскарадинг переписує кожне джерело LAN на адресу тунелю шлюзу, тому далекий кінець відповідає одному партнеру. Маршрутизація за політикою зберігає початкові адреси й вимагає, щоб далекий бік знав, як до них дістатися. Жодне не є типовим; вибір випливає з того, кому належить далекий бік і чи важлива ідентичність кожного пристрою.

Два рішення обіцяють різне

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

Маршрутизація за політикою зберігає адресу кожного клієнта недоторканою. Далека мережа бачить справжнє джерело й може його зареєструвати, застосувати правило для кожного вузла або надіслати відповідь прямо на цю адресу. Ця видимість і є весь сенс, і вона несе зобов'язання: на далекому боці має бути маршрут для префікса LAN, що веде назад через тунель. Сплануйте цей маршрут до ввімкнення правила, бо тунель підніметься в будь-якому разі, а бракуватиме лише відповідей.

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

Маскарадинг: один партнер на далекому боці

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

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

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

Маршрутизація за політикою: збережіть джерело, додайте зворотний шлях

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

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

Далі далекий бік має спрямувати префікс LAN назад через тунель. Це налаштування на далекому маршрутизаторі, а не на цьому шлюзі. Шлюз також має приймати відповіді, що надходять на інший інтерфейс, ніж передбачала б основна таблиця; ослаблена фільтрація зворотного шляху (rp_filter зі значенням 2) — звичайне коригування, коли суворий режим відкидає ці пакети.

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

Вирішуйте за належністю та за тим, що записує далекий бік

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

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

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

Перевірте з одного клієнта, потім із другого клієнта

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

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

Запишіть обрану модель, перекладене або збережене джерело та власника зворотного маршруту в нотатках шлюзу. Інакше наступна людина, яка додає клієнта або тунель, буде вгадувати, а здогад — це шлях, яким робоча схема LAN-у-VPN стає частковою.