Зошто џокер знак во наредбата за маршрута на 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-датотеката, па тие случаи бараат поддржан механизам за поединечна апликација или друг дизајн. Направете попис на клиентите што се важни пред да ветите дека правилото на прелистувачот го покрива работниот тек.

Враќањето директно исто така не е излез. Ако политиката за рутирање на машината веќе испраќа сето во тунелот, барањето означено како директно останува внатре во него, затоа што изборот на прокси и табелата со маршрути се различни одлуки донесени на различни слоеви.

Решавањето имиња е трето посебно прашање. Изборот кои барања одат на прокси не кажува ништо за тоа кој решавач им одговара, а третирањето на двете како едно поставување создава истекувања што се невидливи додека некој не тестира однадвор. Одлучете каде се одговара на секое барање и запишете ја таа одлука до правилото за прокси. Решавачот што се менува затоа што тунелот се подигна тивко ќе го премести одговорот.

Тестирање на двата пата, не само на среќниот

Тестирајте име на домаќин што треба да се совпадне, име на домаќин што не треба, и врвот на доменот, бидејќи врвот е случајот што најчесто го пропушта правило само со наставка. Потоа потврдете кој пат навистина го поминал секое барање наместо да го заклучувате од тоа дали страницата се вчитала.

Конечно, тестирајте ја гранката за неуспех. Недостапното прокси треба да не успее на начин што однапред сте го одлучиле, наместо тивко да се врати на директна врска. Упатството за мрежни опции точно ги документира параметрите на маршрутата; доменската половина од овој дизајн живее целосно надвор од него.

Поврзани статии