VPN рутирање базирано на домен наспроти IP рути: што одговара?

IP рутата се совпаѓа со префикс на адреса, и јадрото ја применува без да поставува повеќе прашања. VPN правилото базирано на домен се совпаѓа со име, што значи дека нешто во стекот мора да одлучи кои адреси ги означува тоа име во моментов и да ја одржува таа одлука ажурна. Тоа се различни механизми со различни начини на откажување, а добавувачите го користат истиот збор за двете. Нивното споредување во списоци со функции ја промашува суштината; споредете ги по тоа што се случува кога одговорот се менува.

Корисната поделба е помеѓу правило што разрешува и правило што не разрешува.

Со што всушност се совпаѓа секое правило

Правилото за префикс се совпаѓа со одредишните адреси во табелата за рутирање. Ништо не се разрешува, ништо не истекува, и совпаѓањето е точно за секој пакет. Доменското правило се совпаѓа со барањето на апликацијата за име, кое RFC 1034 го дефинира како дрво од ознаки, а не како адреса. Некои производи го разрешуваат името еднаш и ги инсталираат добиените адреси како рути, што правилото го прави IP правило со прикачен тајмер за освежување.

Знајте кое од двете го имате пред да го дебагирате, зашто дефектот изгледа сосема поинаку во секој случај.

Каде живее доменското правило во стекот

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

Читајте го моделот на добавувачот, а не етикетата на поставката. Два клиенти со поле наречено Split Tunnel може да прават три различни работи.

Споредете што се крши

Три работи се кршат различно. Менување адреси: име на домаќин на CDN може да се разреши во различен сет адреси за неколку минути, па копираната листа брзо старее. Опфат на поддомени: правило за example.com може или не може да го покрива api.example.com, а документацијата обично е јасна за тоа кое важи. Неуспех при разрешување: кога разрешувачот откажува, клиентот што разрешува може да се врати на тунелирање на сообраќајот или на негово директно праќање.

Само второто е прашање на конфигурација. Другите две се прашања на дизајн за тоа колку производот е подготвен да претпоставува.

Кога префиксот е подобар одговор

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

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

Проверете со свежо барање

Тестирајте со студено барање по нормално повторно поврзување, зашто кеширана страница може никогаш да не го допре правилото. Разрешете го името, потоа проверете каде врската навистина отишла. dig +short app.example.com го дава тековниот сет адреси, а списокот со врски на клиентот ви кажува кој интерфејс го пренел текот.

Повторете по интервалот за освежување што производот го документира. Ако сетот адреси се помести, а правилото не го следи, сте го нашле вистинското однесување.

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