LAN рутер плюс VPN клиент: две устройства, две таблици за маршрутизация

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

Начертайте двата хопа, преди да пипате маршрут

Вземете илюстративна схема: LAN хостове на 192.168.50.0/24, обикновеният рутер на 192.168.50.1, отделен клиент на 192.168.50.15 и отдалечена LAN на 10.60.0.0/24, достъпна само през тунела, който този клиент поддържа. Нито един от частните диапазони не се припокрива с другия, а тунелът има свой собствен адресен план.

И двата частни диапазона имат значение, защото решават кое устройство може да отговори. Отдалечената страна ще види пакета да пристига от тунелния адрес на клиента и отговорът ѝ трябва да намери път обратно до 192.168.50.0/24. Ако е конфигурирана само изходящата посока, заявката може да работи, докато отговорът изчезва.

Стъпка 1: насочете рутера към клиента, а не към тунела

На LAN рутера добавете маршрут за дестинация, чийто следващ хоп е LAN адресът на клиента:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Този запис казва „достави го до машината, която може да тунелира“. Той не казва нищо за това как се изгражда тунелът и не замества собствения маршрут на клиента. На управляван рутер еквивалентът живее в страницата за статични маршрути на устройството; на Linux рутер той принадлежи в конфигурацията на интерфейса, който притежава LAN, а не в shell, който ще затворите.

Проверете отговора на втората команда. Ако тя посочва клиента като gateway, а LAN интерфейса като device, първият хоп е правилен и останалата работа е на другата машина.

Стъпка 2: дайте на клиента собствен маршрут от страната на тунела

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

Погледнете, преди да добавите нещо:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Липсващ маршрут за префикса във всяка таблица е находката, която търсите. Добавете го чрез собствената конфигурация на тунела, така че следващото повторно свързване да го инсталира отново; ръчната ip route add изчезва със сесията и връща повредата в най-неудобния момент. Следващият хоп е тунелният интерфейс или адресът, който VPN задава като свой партньор, в зависимост от клиента, и адресът на партньора трябва да идва от текущия профил, а не от стара бележка.

Примката, когато се появи, на практика не е безкрайна: TTL намалява при всяко преминаване и пакетът умира със съобщение за превишено време. Затова повтарящ се traceroute може да подскаже цикъл, докато клиент, който просто не препраща, изпуска същия пакет безшумно.

Стъпка 3: разрешете препращането и изберете обратния път

Получаването и препращането са различни разрешения. net.ipv4.ip_forward=1 на клиента позволява транзит на ниво ядро, но правило на защитната стена все още трябва да го разреши между LAN интерфейса и тунела. Правило, което разрешава достъп до собствената страница за управление на клиента, няма да разреши транзит към отдалечената LAN и разликата е лесна за пропускане, когато същият хост отговаря на ping локално.

Отдалечената страна има огледалния проблем. Тя трябва да знае, че 192.168.50.0/24 е достъпен през този удостоверен клиент. С OpenVPN това обикновено означава маршрут за всеки клиент, изтласкан от конфигурацията на сървъра, или файл за конкретен клиент на сървъра, който обявява LAN зад клиента. Без него отдалечената LAN или изпуска отговора, или го изпраща към своя шлюз по подразбиране, който е интернет.

Транслацията на източника е алтернативата, когато LAN префиксът не може да бъде обявен. Ограничено правило за masquerade на клиента пренаписва източника към тунелния адрес и отговорите след това се връщат естествено. То също скрива кой LAN хост е направил заявката и само по себе си не позволява на отдалечената страна да инициира връзки навътре. Изберете този компромис съзнателно, вместо да добавите всеобхватен masquerade и да откриете страничния ефект по-късно.

Стъпка 4: направете двете решения постоянни, след което тествайте реалния път

Всеки маршрут има собственик и собственикът е конфигурацията, която се пресъздава при зареждане или при повторно свързване. На рутера това може да е запис за статичен маршрут; на клиента това може да е VPN профилът, NetworkManager или systemd-networkd. Проверете, като свържете тунела отново и рестартирате клиента, след което прочетете таблицата отново, вместо да се доверявате на редакцията.

Пазете целия маршрут по подразбиране, който носи външната връзка на тунела. Замяната му, за да „опростите“ настройката, чупи шифрования път, преди какъвто и да е вътрешен трафик да го използва, а симптомът е тунел, който никога не се установява отново след промяната.

Тествайте от обикновен LAN хост, не от клиента, защото заявка, възникнала на клиента, никога не упражнява първия хоп на рутера. Изтеглете услуга, която съществува само в отдалечената LAN, и потвърдете тялото на отговора, след което проверете броячите или журналите на клиента, за да видите транзита. Вътрешен traceroute, който показва частни хопове, доказва препращане, а не шифроване: външният път е отделно наблюдение и само собствените броячи на тунелния интерфейс показват какво е излязло през него.