Klientkrok eller serverkrok? Var ett OpenVPN-skript körs

Uppgiften är tydlig: när en bärbar dator ansluter ska något på den bärbara ändras. Konfigurationen som redigeras tillhör servern, och det är där antagandet brister. En sökväg i en serverfil namnger en fil på den servern, och ingen mängd push ändrar vilken process som kör den. Att välja mellan de två krokarna handlar mest om att avgöra vilken maskin som äger arbetet och att acceptera gränserna som följer.

Två maskiner, två frågor att besvara först

Fråga var tillståndsändringen måste ske, fråga sedan vilken händelse som motsvarar den. Om ändringen är en behörighet per användare eller ett konfigurationsbeslut per klient hör den hemma där användarkatalogen är känd: servern. Om ändringen är en rutt, en resolverinställning eller en lokal hjälpare på en ändpunkt, hör den hemma på ändpunkten, och bara ändpunkten kan göra det.

Att besvara de två frågorna i omvänd ordning är hur folk till slut försöker knuffa en batchfil till en Windows-bärbar. Servern vet vem som anslöt; den bärbara vet hur dess egen nätverksstack ser ut. Ingen av dem har den andras information, och försöket misslyckas oftast tyst i stället för med ett tydligt fel.

Före båda är en tredje fråga värd att ställa: erbjuder plattformen ens kroken du vill ha? En apparat som genererar sin egen konfiguration erbjuder kanske inte samma händelsenamn, och en skrivbordsklient som importerar en .ovpn-fil är inte nödvändigtvis samma klient som filen skrevs för. Att bekräfta plattformen först sparar dig från att designa kring en krok som inte finns där. Det berättar också vilken dokumentation som faktiskt gäller för maskinen framför dig.

Serveralternativet: en händelse per anslutning

Ett client-connect-skript körs i serverns processkontext när en autentiserad klient ansluter, och det tar emot dokumenterade anslutningsdetaljer som common name och den tilldelade adressen. Det är rätt plats att skriva ett konfigurationsfragment per klient, genomdriva ett policybeslut eller registrera tillstånd som servern äger.

Den skillnad folk missar är skillnaden mellan den kroken och en server-up-krok. Up-kroken utlöses när servern öppnar sin tunnelenhet, vilket på en server med flera klienter sker en gång vid daemonstart. Det är inte en händelse per inloggning, och kod som placeras där körs när tjänsten startar i stället för när användare ansluter.

På en apparat med webbgränssnitt använder du den stödda tilläggsmekanismen i stället för att redigera genererade daemonfiler. Genererade filer skrivs om vid nästa sparning, och omskrivningen tar tyst bort din ändring vid sämsta möjliga tillfälle. Behåll en kopia av tilläggstexten utanför apparaten så att en firmwareuppdatering inte också tappar avsikten.

Klientalternativet: arbete som måste köras lokalt

En communityklient kan köra ett lokalt skript när tunnelenheten kommer upp och igen när rutter installeras. Det är två olika ögonblick, och att välja fel ger det klassiska racet där en hjälpare startar innan rutten den är beroende av finns.

Hjälparen måste finnas på den klienten, vara läsbar och körbar för kontot som kör klienten, och tillåtas av en uttrycklig script-security-inställning. Ett skript som fungerar när du startar klienten som administratör säger ingenting om en tjänst före inloggning eller om en annan användares session.

Namngivning spelar också roll. Up-kroken motsvarar skapandet av enheten och route-up installationen av rutter, men en uppgift som kräver att ett privat nätverk är nåbart bör verifiera nåbarheten i stället för att anta att enhetens skapande innebär att varje rutt, resolverpost och applikation är redo.

Varför pushning av körbar kod inte finns på menyn

Pushade alternativ är medvetet begränsade, och alternativ som kör skript hör till de kategorier som servern inte får skicka ned. Den begränsningen finns för att alternativet skulle låta en komprometterad eller felkonfigurerad server köra godtyckliga kommandon på varje klient som någonsin ansluter.

Att aktivera skriptkörning lokalt ändrar inte det. Din script-security-inställning tillåter lokala skript som du själv valde; den ger inte servern rätt att leverera nya.

Om målet bara är att installera VPN-rutter, använd den stödda ruttkonfigurationen i stället för att hitta på ett upplägg för fjärrkörning. Om målet verkligen kräver lokal kod, distribuera den via organisationens verktyg för ändpunktshantering och granska den som all annan programvara som körs med användarens privilegier.

Vad du bör verifiera innan du litar på någon av krokarna

Skriv ned fyra saker för varje krok: maskinen, händelsenamnet, kontot den körs som, och tillståndsändringen den ska åstadkomma. Testa sedan anslutningen, en återanslutning och städvägen, eftersom en krok som läcker tillstånd vid återanslutning är sämre än en som aldrig kördes.

Testa under kontot som faktiskt ska köra den, i det ögonblick den faktiskt körs. Handboken openvpn(8) dokumenterar båda krokfamiljerna och push-begränsningarna; plattformen du driftsätter på dokumenterar om den överhuvudtaget exponerar dem. Ett skript som lyckas i en interaktiv administratörsterminal är en hypotes, inte en verifiering.