VPN маршрутизация по домейн срещу IP маршрути: кое подхожда?

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

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

С какво всъщност съвпада всяко правило

Правилото за префикс съвпада с адресите на местоназначение в таблицата за маршрутизация. Нищо не се разрешава, нищо не изтича и съвпадението е точно за всеки пакет. Правилото за домейн съвпада със заявката на приложение за име, което RFC 1034 определя като дърво от етикети, а не като адрес. Някои продукти разрешават името веднъж и инсталират получените адреси като маршрути, което прави правилото IP правило с прикачен таймер за обновяване.

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

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

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

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

Сравнете какво се чупи

Три неща се чупят по различен начин. Текучество на адреси: име на хост на CDN може да се разреши до различен набор от адреси за минути, затова копиран списък остарява бързо. Обхват на поддомейни: правило за example.com може да покрива или да не покрива api.example.com и документацията обикновено е ясна кой е случаят. Провал на разрешаването: когато резолверът се провали, клиент, който разрешава, може да премине към тунелиране на трафика или към директното му изпращане.

Само второто е въпрос на конфигурация. Другите две са въпроси на дизайн за това колко е готов продуктът да предполага.

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

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

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

Проверете със свежа заявка

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

Повторете след интервала на обновяване, който продуктът документира. Ако наборът от адреси се измести, а правилото не го следва, открили сте истинското поведение.

Дръжте политиката на резолвера отделно. Правилото за домейн се нуждае от правилни данни за имена, но само по себе си не решава кой резолвер отговаря на заявката.