Спрямуйте одну підмережу LAN через OpenVPN і збережіть маршрут за замовчуванням

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

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

Один маршрут за замовчуванням, два власники

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

У OpenVPN є перемикач саме для цього. route-noexec не дає клієнтові взагалі торкатися основної таблиці, а значення, які він інакше використав би, експортуються в скрипт route-up як route_vpn_gateway, dev та адреси інтерфейсу. Далі ви вирішуєте, яка таблиця отримає який маршрут, у коді, який можна прочитати пізніше.

Таблиця політик проти переписування основної

ApproachWhat it buysWhat it costs
Separate table plus source ruleLAN traffic and host traffic keep independent defaultsEvery lookup now depends on rule order
Editing the main table onlyFewer moving parts on a single-purpose hostOne mistake takes the gateway offline entirely
Two half-default routesWorks for a full-tunnel clientAmbiguous on a host that must answer on its LAN address

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

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Адреси тут — заповнювачі. Замініть префікс LAN, шлюз тунелю та ім’я пристрою зі свого розгортання, перш ніж щось запускати.

Правило має відповідати й хосту

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

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

ip route get 203.0.113.9 from 192.168.50.1

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

NAT або маршрут на дальньому боці

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

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

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

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

Зробіть так, щоб поділ пережив перепідключення

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

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

Схожі статті