vpn.persistent продължава да опитва, но не ви държи свързани

NetworkManager предоставя едно свойство, vpn.persistent, и хората го питат да отговори на четири различни въпроса едновременно. Документацията му е внимателна: устойчивостта се прилага, когато VPN услугата я поддържа и профилът я разрешава, след което връзката се очаква да преживее промени на връзката и прекъсвания до изрично изключване. Същата документация показва също, че свойството по подразбиране е false, което не е това, което повечето планове за възстановяване предполагат. Четете го като искане за опит, а не като обещание за резултат.

Какво всъщност обещава настройката

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

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

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

Четири въпроса, слети в един

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

Възстановяването пита какво се случва, когато връзката се промени или изчезне, а това е тесният въпрос, който vpn.persistent адресира. Живучестта пита дали клиентът може да разбере, че отсрещната страна е спряла да отговаря, и вместо това на него отговаря поведението keepalive или рестартиране на OpenVPN; двата механизма често се описват с една и съща дума и се реализират на различни места. Тествайте ги отделно, с различни инструменти, иначе ще припишете едно поведение на другото.

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

Контролен списък, който ги разделя

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

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

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

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

Удостоверяването е част от възстановяването

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

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

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

Устойчивостта не е kill switch

Свойството се опитва да запази или възстанови VPN връзката. То не решава какво могат да правят приложенията, докато VPN-ът е спрян, и само по себе си не блокира нищо.

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

Запишете и двете половини в бележките за възстановяване: какво е опитал VPN-ът и какъв трафик на приложения е бил разрешен, докато опитът е течал.