Защо VPN с пълен тунел скрива маршрутизираните локални VLAN мрежи

Превключвателят „allow local network“ в един VPN клиент звучи така, сякаш покрива всичко в сградата. На практика той обикновено добавя няколко изключения за частни адреси към маршрута по подразбиране на тунела и спира дотам. Вашият VLAN за съхранение остава достъпен само ако маршрут за този конкретен префикс оцелее при идването на тунела, а при много клиенти това не се случва.

Това е въпрос на маршрутизиране, а не настройка на VPN, и това е добра новина: има конкретен отговор.

Какво всъщност покрива allow-local-network

Клиентите реализират тази опция по различен начин. Някои добавят маршрути за подмрежата, към която е свързана машината, други добавят диапазоните RFC 1918, а малцина изключват само шлюза по подразбиране. Никой от тях не знае, че офис рутерът ви обслужва също VLAN за съхранение, лабораторен сегмент или подмрежа за принтери, защото тези префикси не са на кабела, който клиентът вижда. Четете собствената документация на клиента за точното поведение, вместо да предполагате, че етикетът описва вашата топология.

Разликата е най-важна при дизайн с пълен тунел, където клиентът умишлено заменя маршрута по подразбиране, за да минава целият трафик през VPN. Това е целият смисъл на дизайна и именно това кара локалните маршрутизирани мрежи да изчезнат. Те никога не са били покрити от собствен маршрут; те се возеха на маршрута по подразбиране, който току-що беше заменен. Клиентът не може да маршрутизира това, за чието съществуване не знае, и научава само за префикси, прикачени към собствения му интерфейс. Всичко останало трябва да бъде описано от някого, който познава топологията.

Свързаните маршрути спират при първия рутер

Работна станция на 192.168.10.20/24 с шлюз 192.168.10.1 получава автоматично свързан маршрут за 192.168.10.0/24. VLAN мрежата за съхранение на 192.168.20.0/24 е друг префикс, достъпен само през този шлюз, и работната станция няма маршрут за нея извън маршрута по подразбиране. Преди тунелът да се вдигне, обикновеният маршрут по подразбиране случайно изпраща трафика за съхранение към 192.168.10.1 и всичко работи.

Когато VPN инсталира маршрут по подразбиране за пълен тунел, пакетите за 192.168.20.1 следват новия маршрут по подразбиране в тунела. Отдалеченият шлюз няма представа къде живее този префикс, затова ги изхвърля или ги препраща на безполезно място. Нищо не е било конфигурирано грешно на VLAN за съхранение; пътят му беше зает, и заемът беше поискан обратно.

Изкушението е да посегнете към широко изключение, например двойка маршрути /1 или втори маршрут по подразбиране. Устояйте. Колкото по-тясно е изключението, толкова по-лесно е да се обясни, провери и премахне, когато мрежата се промени.

Сложете изключението в таблицата, която печели

В една таблица за маршрутизиране /24 побеждава /0 или /1 чрез най-дълго съвпадение на префикс, така че конкретен маршрут до VLAN за съхранение през локалния шлюз е достатъчен, стига таблицата изобщо да бъде преглеждана. В Linux обичайната форма е кратка:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Маршрутизирането по политика усложнява тази гаранция. По-ранно правило може да изпрати трафика към таблица, чийто собствен маршрут по подразбиране сочи в тунела, и главната таблица, която държи вашия /24, тогава никога не се достига. Проверете правилата, преди да приемете, че маршрутът е меродавен, защото правилен на вид запис в грешната таблица обяснява отказ, който изглежда като счупен маршрут.

След това направете записа постоянен чрез поддържания от клиента механизъм или мрежовия мениджър, който притежава интерфейса. Маршрут, набран в подканата, изчезва при следващото повторно свързване, а маршрут, вързан към един Wi-Fi шлюз, не е преносим към следващата мрежа, която лаптопът посети.

Имената и политиката не следват маршрутите

Поправянето на маршрута връща пакетите, не имената. Ако локалните устройства се резолвват през наложен резолвер, който не знае нищо за тях, монтирането пак се проваля, дори адресът да е достъпен. Локалните имена се нуждаят от локална или разделена DNS схема и това е отделно решение от изключението за маршрута.

Политиката отново е отделна. Филтърът за локален достъп на VPN клиента може умишлено да забранява трафик към частни диапазони и маршрутът не отменя това правило. В недоверена мрежа частният адрес също не е доказателство, че дестинацията е вашият сървър за съхранение, затова изключението трябва да е толкова конкретно, колкото самия маршрут.

Договор, който можете да предадете

Готовият дизайн трябва да се чете като кратък списък: общият интернет трафик следва тунела, а тези именувани локални префикси запазват пътя си през локалния рутер. Запишете префиксите, следващия хоп и DNS суфикса, който върви с тях, и дръжте списъка достатъчно кратък, за да може някой да го провери, без да чете таблица за маршрутизиране.

Внимавайте за припокриване между локални и отдалечени диапазони. VLAN за съхранение, който споделя префикс с нещо зад VPN, ще се резолвне към по-конкретния маршрут, а полученото поведение е объркващо по начин, който изглежда периодичен. Преномерирането на едната страна обикновено е по-евтино от вечното отстраняване на неяснотата.

Тествайте договора два пъти: веднъж с вдигнат тунел и веднъж със свален. Ако локалният път работи само в едно от тези състояния, изключението още не е договор.