Свързване на малък контролер с VPN в NetworkManager

Малка програма, която свързва съществуващ VPN, се нуждае от контролер, а не от нова реализация на VPN. Поддържаният двигател трябва да поеме договарянето и трафика на тунела; вашата програма трябва да изразява заявката на потребителя и да обяснява резултата честно. В Linux интерфейсът NetworkManager D-Bus дава на този контролер конкретен модел, на който да следва.

Четири проверки пазят контролера да не бърка запазен профил, заявка за активиране и работеща сесия.

Проверка първа: коя идентичност се избира

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

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

Проверка втора: какво връща извикването за активиране

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

За VPN конкретният обект избира активното базово свързване. Предаването на кореновия път оставя избора на устройство на NetworkManager, който избира това, което понастоящем е по подразбиране. Това е решение за контекста на маршрутизиране, а не поле за парола, и то променя върху кое устройство е положен тунелът.

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

Проверка трета: как е представено състоянието

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

Свързвайте асинхронните отговори със заявката, която ги е породила. Късно завършване от по-стар опит не бива да презаписва по-ново потребителско действие, а повторно натискане на Connect трябва или да се игнорира, или да се третира като отказ и повторен опит с видима политика.

Проверка четвърта: какво става след рестарт

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

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

Пазете правомощията и тайните при техните собственици

Разрешенията се връщат като да, auth или не, и интерфейсът трябва да отразява разликата между разрешено, разрешено след автентикация и отказано. Стартирането на контролера като root не прилага политика за разрешения; то премахва въпроса.

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

Накрая, съобщавайте състоянието на свързването отделно от задачата, която потребителят иска да изпълни. Тунелът може да е активен, докато частно име или приложение остават недостъпни, и този втори отказ заслужава собствено съобщение и собствен статус. Контролер, който казва точно кой слой е отказал, е по-полезен от такъв, който казва, че VPN не работи.