Защо заместващ знак (wildcard) в директива за маршрут на OpenVPN не може да работи

маршрутът инсталира префикси на адреси, така че шаблон за име на хост няма с какво да се съпоставя. Използвайте префикс за мрежи и прокси или PAC файл, когато домейните трябва да решават.

Намерението е разумно: да изпратите всичко за един корпоративен домейн през тунела и да оставите останалото. Редактираната директива инсталира маршрути, а маршрутът няма представа за име на хост, с което да се съпоставя. Всеки опит да се запише заместващ знак в него дава или грешка при синтактичния анализ, или, което е по-лошо, маршрут, който днес работи случайно, защото името се е разпознало до един адрес. Два различни механизма са помолени да вършат работата един на друг.

Какво инсталира маршрутът и какво никога не чете

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

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 файла, така че тези случаи се нуждаят от поддържан механизъм за отделно приложение или различен дизайн. Направете инвентаризация на клиентите, които имат значение, преди да обещаете, че правилото за браузъра покрива работния процес.

Връщането директно също не е авариен изход. Ако политиката за маршрутизиране на машината вече изпраща всичко в тунела, заявка, отбелязана като директна, остава в него, защото изборът на прокси и таблицата с маршрути са различни решения, взети на различни слоеве.

Разпознаването на имена е трети отделен въпрос. Изборът кои заявки да отидат към прокси не казва нищо за това кой резолвер им отговаря и третирането на двете като една настройка произвежда течове, които са невидими, докато някой не тества отвън. Решете къде се отговаря на всяка заявка и запишете това решение до правилото за проксито. Резолвер, който се променя, защото тунелът се е вдигнал, тихо ще премести отговора.

Тестване на двата пътя, не само на щастливия

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

Накрая тествайте клона за отказ. Прокси, което е недостъпно, трябва да се провали по начин, който сте решили предварително, вместо тихо да се върне към директна връзка. Справката за мрежовите опции документира параметрите на маршрута точно; домейнната половина на този дизайн живее изцяло извън нея.

Подобни статии