По-просто ли е пълното тунелиране от дълъг списък за разделен тунел?

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

Започнете с преброяване на правилата, които поддържате

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

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

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

Проверете дали шлюзът може да носи настройката по подразбиране

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

ip -s link show dev tun0
conntrack -C
ss -s

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

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

Потвърдете, че локалните услуги и частният DNS още работят

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

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

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

Мигрирайте един профил и проверете границите

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

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

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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