Защо правилото ви за разделен тунел спря да съвпада с услуга

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

Какво фиксира правилото и какво връща DNS

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

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

Три начина, по които съвпадението се чупи

Очевидният случай е преместена услуга: операторът я преадресира, DNS го последва, а изключението не. Вторият е семейство адреси, което правилото никога не е покривало; това се случва, когато име започне да връща AAAA записи, които изключение само за v4 игнорира. Третият е разлика в резолвера: вътрешен и публичен изглед могат да върнат различни адреси за едно и също име, така че адресът, който приложението ви използва, не е този, с който сте тествали.

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

Прочетете дестинацията, която приложението наистина използва

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

Поправете механизма, не симптома

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

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

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

Проверете и двете половини на намерението

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

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