Huvudlös OpenVPN: övervakad session eller hanterad tjänst

Att köra OpenVPN över SSH startar det på fjärrmaskinen, i den maskinens exekveringskontext. Det gör det till en ändring av fjärrnätet snarare än ett fjärrknapptryck. De två förnuftiga lägena är en övervakad förgrundssession och en egen tjänst, och de har olika förberedelser, olika inloggningsuppgifter och olika felbeteende.

Två lägen, en profil

Båda lägena använder samma profil och båda ändrar routingen på värden. Det som skiljer är vem som är närvarande när det startar, och vad som händer efter att sessionen tar slut.

Förgrundsläget är för en övervakad anslutning där någon är närvarande. Tjänsteläget är för en anslutning som ska komma upp utan att någon är inloggad. Att blanda dem, genom att låta en förgrundsprocess köra och samtidigt aktivera en tjänst på samma profil, är den vanligaste självförvållade skadan här.

Vad förgrundssessionen egentligen är

En OpenVPN-förgrundsprocess ska fortsätta köra medan tunneln är uppe. Initialization Sequence Completed betyder att initieringen är klar, inte att du ska vänta på att en prompt kommer tillbaka. Ett skrivbords-GUI gömmer det långvariga arbetet bakom ett fönster, och det är just därför folk förväntar sig att SSH-kommandot ska bete sig på samma sätt. Det gör det inte.

Kontrollera programmets åtkomst separat. En upptagen terminal och en loggrada bevisar varken framgång eller misslyckande.

Vad en obemannad tjänst behöver

En tjänst startar med sitt eget konto, sin egen arbetskatalog och sina egna filsystembegränsningar, och alla dessa skiljer sig från ditt skal. Använd explicita sökvägar och lämpligt ägande i stället för att lita på var du råkade stå. Ge enheten en omstartspolicy som du faktiskt vill ha, eftersom en anslutningsloop utan backoff fyller en logg och irriterar motparten. Verifiera sedan att den kommer upp efter en omstart och inte efter din nästa inloggning.

Interaktiv MFA bryter det obemannade fallet enligt design. Om profilen kräver en kod som skrivs av en person är det inte en obemannad tjänst, och en lagrad engångskod är inte en design för inloggningsuppgifter. Bestäm det medvetet i stället för att upptäcka det vid uppstart.

Inloggningsuppgifter är fyra olika indata

OpenVPN har en manual som skiljer konsolindata, inloggningsuppgiftsfiler, lösenfraser för privata nycklar och administrationsstyrd interaktion. Ett användarnamn och lösenord är en sak, och en krypterad nyckels lösenfras är en annan. Ett administrationsgränssnitt som levererar inloggningsuppgifter på begäran är en tredje. Välj den mekanism som passar din autentiseringsdesign i stället för att kedja allt i en fil eftersom det råkade fungera en gång.

Skydda profilerna och loggarna som bär identitet eller privat material. Tjänstekontot läser dem, och det gör också alla med rätt gruppmedlemskap.

En ägare, och en väg tillbaka

Bevara din SSH-administrationsväg innan du aktiverar en bred tunnelrutt. En fulltunnelkonfiguration med en slutpunkt som dör kan lämna maskinen oåtkomlig, och reparationen kräver då en konsol som du inte ordnat. En godkänd out-of-band-konsol eller en medveten policy för administrationsretur är försäkringen.

Välj en enda konfigurationsägare för den dagliga driften. En automatisk tjänst och en förgrundsprocess som konkurrerar om samma gränssnitt, rutter och resolverstatus ger fel som ser ut som ett leverantörsproblem. Stoppa en övervakad körning med sin normala avbrytning, och en hanterad via sin manager i stället för att döda varje process som heter openvpn.

Skillnaden som är värd att skriva ned är enkel: en övervakad körning får bero på din session, och en obemannad tjänst får inte.