Ett litet program som ansluter en befintlig VPN behöver en kontrollenhet, inte en ny VPN-implementering. Den stödda motorn bör hantera förhandlingen och tunneltrafiken; ditt program bör uttrycka användarens begäran och förklara resultatet ärligt. På Linux ger NetworkManager D-Bus-gränssnittet den kontrollenheten en konkret modell att följa.

Fyra kontroller hindrar kontrollenheten från att blanda ihop en sparad profil, en aktiveringsbegäran och en fungerande session.

Kontroll ett: vilken identitet som väljs

Håll profilens UUID som den varaktiga identiteten och lös upp det via hanteraren när du behöver objektets sökväg. Ett visningsnamn kan delas av två profiler, och en bussökväg vid körning är inte en rimlig användarinställning att spara. Skriv ned valet i din egen konfiguration, inte i en kommentar om vilken post som var nummer två i listan.

Verifiera vad hanteraren returnerar innan du kallar det en träff. Ett UUID som inte längre finns ger ett uppslagsfel, och det är en annan kodväg än en profil som finns och vägrar aktiveras.

Kontroll två: vad aktiveringsanropet returnerar

Det dokumenterade aktiveringsanropet tar en objektsökväg för en befintlig anslutning, en enhetssökväg och ett specifikt objekt. Det returnerar en sökväg för en aktiv anslutning, och det svaret är ett handtag, inte ett resultat om beredskap. Sätt inte programmets beredskapsflagga från returvärdet; prenumerera i stället på den aktiva anslutningens tillstånd och orsak.

För en VPN väljer det specifika objektet den aktiva basanslutningen. Skickar du rotsökvägen lämnas enhetsvalet till NetworkManager, som väljer den som för närvarande är standard. Det är ett beslut om routningskontext och inte ett lösenordsfält, och det ändrar vilken enhet tunneln läggs på.

Kopiera inte ett generellt lägg-till-och-aktivera-exempel och förvänta dig att det skapar en VPN-profil. Den dokumenterade hjälparen utesluter VPN-anslutningar, så etablering eller import av profilen är ett separat, granskat steg. Det spelar roll eftersom etablering kräver auktorisering och granskning som en anslutningsknapp inte ger. Behandla import som en administrativ åtgärd med egen logglinje och egen godkännare.

Kontroll tre: hur tillståndet representeras

En aktiv anslutning går genom aktivering, aktiv, inaktivering och inaktiverad, och orsaksfältet säger varför. Att pressa allt detta till ett booleskt värde som heter loggedIn förlorar informationen som användaren behöver och den som supporten kommer att fråga efter. Visa åtminstone om anslutningen väntar, är upprättad eller är borta, och behåll orsakssträngen för felaktillfället.

Knyt asynkrona svar till begäran som producerade dem. En sen slutförande från ett äldre försök får inte skriva över en nyare användaråtgärd, och ett dubbelt tryck på Connect bör antingen ignoreras eller behandlas som avbryt-och-försök-igen med en synlig policy.

Kontroll fyra: vad som händer efter en omstart

När hanteraren startar om eller din kontrollenhet ansluter till bussen igen, bygg det observerade tillståndet på nytt från ägaren. Fortsätt inte visa en cachad session som aktiv bara för att en gammal objektsökväg finns kvar i minnet. Tillståndsändringssignalerna finns just för att en kontrollenhet ska kunna synkronisera om i stället för att gissa.

Välj vad det innebär att stänga kontrollenheten. Att låta en befintlig maskinägd anslutning vara uppe kan vara korrekt, och att riva ned en avsiktligt kortlivad session kan också vara korrekt. Att låta en befintlig maskinägd anslutning vara uppe kan vara korrekt; att riva ned en avsiktligt kortlivad session kan också vara korrekt. Skriv in det ägandekontraktet i gränssnittet i stället för att anta att processavslut utför nätverksåtgärden. Användare bör inte behöva gissa om stängning av fönstret släpper deras tunnel. Sätt svaret i gränssnittstexten, inte bara i en kodkommentar.

Behåll befogenhet och hemligheter hos deras ägare

Behörigheter kommer tillbaka som ja, auth eller nej, och gränssnittet bör spegla skillnaden mellan tillåtet, tillåtet efter autentisering och nekat. Att köra kontrollenheten som root implementerar ingen behörighetspolicy; det tar bort frågan.

Uppgifterna tillhör den stödda hemlighetsagenten eller klientintegrationen för den konfigurerade autentiseringsmetoden. Ett lösenord i källkoden, i ett argument eller i en logg är ett fynd, och lokal administrativ auktorisering är inte samma händelse som autentisering vid gatewayen.

Slutligen, rapportera anslutningstillståndet separat från uppgiften användaren vill utföra. En tunnel kan vara aktiv medan ett privat namn eller ett program fortfarande är otillgängligt, och det andra felet förtjänar sitt eget meddelande och sin egen status. En kontrollenhet som exakt säger vilket lager som misslyckades är mer användbar än en som säger att VPN:en är nere.

Relaterade artiklar