Допълнителните Mac VPN маршрути се нуждаят от собственик, не от скрипт за вход
Маршрут, добавен веднъж при вход, не е политика за повторно свързване. Дайте на отдалечените префикси собственик и решете как се появяват, променят и изчезват с тази връзка.
Достигането на частен префикс през VPN е изискване с продължителност: то е в сила, докато тази връзка е използваема, и свършва, когато връзката свърши. Скрипт за вход не може да изрази това, защото входът и вдигането на тунела са различни моменти, а тунелът, който съществува при входа, може да не е този, който носи трафика минута по-късно. Първото решение не е коя команда да се изпълни, а кой компонент притежава префикса.
Префиксът се нуждае от собственик, не от момент
Започнете, като запишете изискването като изречение с подлог: достигнете 10.77.0.0/24 през офисния VPN, докато тази връзка е вдигната. Това изречение назовава префикса, връзката и условието и веднага изключва два популярни заместителя: кука при вход и име на интерфейс като ppp0 или utun2.
Имената на интерфейсите се задават по време на изпълнение и не са стабилни между повторните свързвания. Кука, която съвпада с името, видяно миналата седмица, или няма да се задейства, или ще се задейства срещу нечий чужд интерфейс. И двата изхода изглеждат като проблем с маршрутизацията, а не като остарялото допускане, което представляват. Същото възражение важи за всеки скрипт, вързан към име, което съществува само докато е вдигнат определен тунел.
Използвайте поддържан източник на намерение за маршрут
Шлюзът, управляван профил или документираният механизъм за маршрутизация на притежаващия клиент е мястото за това, когато този механизъм може да изрази изискването. Кой от тях важи зависи от протокола и доставчика и ключовете не се пренасят между тях, така че стойност, която настройва профил OpenVPN не ви казва нищо за родния клиент L2TP или IKEv2.
| Mechanism | Can carry extra prefixes | Who owns the lifetime |
|---|---|---|
| Gateway-pushed routes | Often, if the gateway is configured for it | The connection |
| Managed profile settings | Depends on the client and profile format | The profile |
| Provider tunnel settings | Yes, as included and excluded routes | The provider process |
| Manual command | Yes, once | Nobody |
За разработчиците на пакетни тунели настройките за тунел IPv4 на Apple изрично показват включени и изключени маршрути, а IPv6 има своя аналог. Това са API, които доставчикът използва, а не доказателство, че всеки роден VPN панел предлага на администратора произволен списък с маршрути. Ако текущата комбинация не може да изрази нужните префикси, следващата стъпка е поддържан път за конфигурация от оператора, а не друго приложение, инсталирано с надеждата, че ще се държи по-добре.
Животът включва почистване
Понякога външен помощник наистина е необходим и тогава „добави маршрута“ е най-малката част от работата му. Той трябва да знае на коя връзка служи и кой интерфейс използва тази връзка, да изчака съответното мрежово състояние да се установи, да остане идемпотентен при два последователни пуска, и да не почиства нищо, което сам не е инсталирал.
Последната клауза е тази, която боли. Помощник, който изтрива всеки маршрут, съответстващ на офисния префикс, рано или късно ще изтрие маршрут, който не е добавил. Полученият срив се стоварва върху VPN клиента, защото клиентът е частта, която потребителят вижда. Решаването какво притежава помощникът преди да го напишете е по-евтино от обяснението после защо локална подмрежа е спряла да отговаря.
Надпреварата при повторно свързване
Представете си бързо повторно свързване. Сесия A пада, сесия B се вдига и инсталира маршрута си, а после отложеното почистване на A най-накрая се изпълнява. Ако това почистване премахва маршрути по префикс, то отнема валидното състояние на B и връзката, която работеше преди секунда, сега маршрутизира в нищото.
Това е надпревара за собственост и добавянето на изчакване в скрипта само сменя коя страна я печели. Решението е почистването да зависи от идентичност: сравнете интерфейса и сесията, които помощникът е инсталирал, с тези, които все още са актуални, и премахвайте само при съвпадение.
Какво да тествате и какво маршрутът не може да направи
Приемането трябва да покрива четири прехода: първата връзка, повторно свързване към друг интерфейс, неуспешен опит за свързване и окончателното прекъсване. След всеки от тях прочетете маршрута, който системата действително е избрала за адрес от отсрещната страна, а не този, който сте очаквали.
route -n get 10.77.0.5
netstat -rn -f inetВключете и неудобните случаи в същия преглед: IPv6 там, където е необходим, локален префикс, който се застъпва с отдалечения, и маршрута до самия публичен VPN крайна точка, който трябва да продължи да работи, докато тунелът е вдигнат. След това запишете какво маршрутът не е. Той избира пакети; не дава разрешение от отсрещната страна и не създава обратен път, и те остават отделни изисквания с отделни собственици.
Резултатът, който искате, е префикс, който следва своя поддържан собственик на връзката през всеки преход, а не команда, която случайно е успяла веднъж на машината, където е написана.