Документацията за разделен тунел изисква DNS правило до всеки маршрут
Маршрутът решава по адрес, резолверът решава по име. Документирайте и двата селектора за всеки поток, всеки с един тест, иначе бележката се проваля, когато DNS се измести.
Бележка за разделен тунел, която казва "офис трафикът минава през VPN", е документирала едно решение и е подразбрала три други. На ниво пакет таблицата за маршрутизация избира интерфейс по адрес на местоназначение; на ниво имена резолверът избира сървър по заявка, и двата избора се правят независимо. Затова правилно документиран префикс все още може да даде машина, която разрешава вътрешно име към публичен адрес, или не разрешава нищо, докато маршрутът изглежда безупречен.
Два селектора, един опит за връзка
Когато приложение се свързва с files.corp.example, се случват две търсения, преди да съществува пакет. Резолверът решава кой сървър получава заявката, използвайки домейни за търсене, домейни за маршрутизация по връзка или явно правило в профила. След това таблицата за маршрутизация решава накъде отива полученият адрес, използвайки най-дългото съвпадение на префикс с местоназначението.
Нищо не свързва тези две решения. Частна зона може да отговори с 10.20.4.11, докато таблицата за маршрутизация изпраща 10.20.0.0/16 в тунела, и връзката работи. Обърнете което и да е от двете и то се проваля по начин, който изглежда като другото: правилна DNS политика плюс липсващ маршрут дава разрешено име и изчакване, докато правилен маршрут плюс публичен резолвер дава адрес, който се маршрутизира чисто към грешното място.
DNS с разделен хоризонт прави това още по-осезаемо. Едно и също име може да върне частен адрес от вътрешния резолвер и публичен адрес от обърнатия към интернет, така че бележка, която записва само префикса, не може да предвиди кой адрес клиентът действително ще използва. Запишете пътя на резолвера или адресът е догадка.
Какво пропуска бележката само с маршрут
Запис само с маршрут е безполезен за най-честата повреда при разделен тунел: имената. Потребителят съобщава, че вътрешната мрежа не се зарежда, тунелът е вдигнат и префиксът е наличен. Който поеме заявката, няма запис кой резолвер е трябвало да отговори, няма начин да различи грешен суфикс за търсене от блокиран сървър и няма базова линия за сравнение.
Второто пропускане е списъкът с изключения. Дизайнът на разделен тунел се определя толкова от това какво остава извън тунела, колкото и от това какво влиза в него, а изключените диапазони обикновено се чупят първи, защото по-конкретен локален маршрут или филтър от страна на клиента може да отмени намерението, без да пипа профила.
Третото е далечната страна на тунела. Клиентският маршрут само поставя пакета на кабела; шлюзът все още трябва да го препраща и да има път обратно. Ръководството на strongSwan за препращане е напомняне, че правилата за препращане и защитна стена на шлюза са част от функцията, а не част от водопровода, който може да се приема за даденост.
Полетата, които правят бележката изпълнима
Един ред на поток, а потокът е местоназначение плюс име плюс собственик. Това са полетата, които оцеляват при сблъсък с реален инцидент:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Редът "къде живее" е този, който хората пропускат. Префикс, изтласкан от сървъра, маршрут, добавен от клиентски профил, и маршрут, набран в шел, се различават по това кой може да ги промени и дали оцеляват при повторно свързване. Без това поле следващият инженер не може да каже кой от трите гледа.
Един тест на правило, не един на тунел
Всеки ред се нуждае от две безвредни проверки: една, която упражнява маршрута, и една, която упражнява името. За маршрута поискайте нещо, което трябва да пресече тунела, и потвърдете пътя, а не достижимостта, например tracert -d 10.20.4.11 на Windows или ip route get 10.20.4.11 на Linux. За името заявете частното име и запишете кой сървър е отговорил, използвайки resolvectl query files.corp.example или dig files.corp.example срещу резолвера, който бележката посочва.
Добавете и отрицателно очакване: какво трябва да се случи, когато тунелът е спрян. Изключено приложение на устройство с Android или iOS с включено блокиране без VPN може да няма никаква връзка, а настолен клиент може да остави същото приложение работещо, докато тунелът се свързва отново. Записването на предвидения отговор превръща "VPN счупи приложението ми" в проверимо твърдение.
Пазете записа с конфигурацията
Съхранявайте бележката до профила, който описва, и я версионирайте с този профил. Документ в уики, който никой не обновява, е слух; таблица в същото хранилище като изтласканите маршрути и политиката на резолвера може да бъде прегледана в същата промяна.
Когато нещо се счупи, сравнете приложения маршрут и ефективния резолвер със записа, преди да добавите още едно изключение. Две от трите чести причини — старо правило за пространство от имена и помощен процес извън политиката на приложението — изглеждат точно като повреда на VPN и са невидими, ако бележката изброява само префикси.
Преди да обявите бележката за готова, потвърдете, че тя писмено отговаря на следното: кой префикс, за кое семейство адреси; кое частно пространство от имена, обслужвано от кой резолвер; кои имена умишлено остават публични; къде е конфигурирано всяко правило и кой го притежава; и единствената команда, която доказва маршрута, и тази, която доказва името. Ако нещо от това липсва, следващият инцидент ще бъде диагностициран от нулата.