Чому шаблон (wildcard) у директиві route OpenVPN не може працювати

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

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

Що встановлює маршрут і чого він ніколи не читає

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

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

Отже, маршрут, побудований з імені, — це знімок, а не правило. Він охоплює те, в що це ім'я розв'язалося в момент запуску тунелю, і це саме та поведінка, якої ви не хочете для мінливої родини хостів. Запис, який переїде завтра, залишає маршрут, що вказує на вчора.

Коли призначення справді є префіксом

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

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Обидва записи називають адреси й маски, і обидва переживають зміни DNS, бо ніщо в них не залежить від імені. У цьому вся перевага: маршрут — це твердження про топологію, а не про пошук, що стався одного разу.

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

Коли одиниця роботи — ім'я хоста

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

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

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

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

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

Чого не покриває опція проксі

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

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

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

Перевіряти обидва шляхи, а не лише вдалий

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

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

Схожі статті