Чи можуть маршрути DHCP повести ваш трафік в обхід VPN-тунелю?

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

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

Два способи, якими мережа може на вас вплинути

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

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

expected:  app -> tunnel device -> encapsulation -> internet
observed:  app -> wlan0        -> plaintext     -> internet

Звідки маршрут може взятися ще до появи тунелю

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

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

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

Перевірте шлях, який ядро справді обирає

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

ip route get 203.0.113.10
ip route show table all | grep -E '^(default|203\.0\.113)'
ip rule show
resolvectl query example.com

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

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

Вирішіть, де має жити примус

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

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

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