Din .ovpn-fil kan köra kod, inte bara dirigera trafik

De flesta läser en .ovpn-fil som de läser en routers inställningssida: adresser, rutter, en lista över chiffer. Den del som kör kod sitter nära botten, bredvid direktiv som ser ut som rörarbete, och den körs med vilka privilegier klienten än har. Det är gapet som en slarvig eller illasinnad profil utnyttjar, och det är också gapet som förvandlar en hjälpsam DNS-hjälpare till ett supportproblem tre veckor senare. Händelsedirektivet, säkerhetsnivån och filens ägarskap avgör vad som kan hända; skriptets innehåll avgör vad som faktiskt händer. Läs alla fyra innan du ansluter.

En profil som kör en hjälpare är ett program, inte en inställningsfil

Direktiv som route och dhcp-option beskriver tillstånd som klienten ska upprätta, och klienten behandlar dem som data. Ett up-skript är annorlunda: klienten startar det som en process och ger det en miljö full av anslutningsdetaljer, så allt författaren skrev körs med ditt kontos rättigheter. På en bärbar dator där användaren är administratör är det en bred dörr för en fil som kom som bilaga eller inklistrad text från en forumtråd. Skillnaden är inte stilistisk, det är skillnaden mellan konfiguration och kod.

Myten som är värd att pensionera är att en profil bara kan omdirigera trafik. En hjälpare som kör ip route add och en som kör curl mot en fjärrvärd är samma mekanism, och profilen ser identisk ut utifrån. Inget i filens utseende säger vilken du har, därför måste granskningen nå ända in till själva skriptet.

Vad som faktiskt avgör körningen, och hur de möjliggörande raderna ser ut

Tre saker styr en hjälpare: händelsedirektivet som namnger den, script-security-nivån som tillåter den och klientplattformens egen implementering. En profil kan begära en krok och ändå inte se något hända, eftersom en mobilklient eller ett nedskalat skrivbordsbygge kanske inte implementerar den händelsen alls. På samma sätt säger en profil som begär mer tillstånd än funktionen behöver något om sitt ursprung. En tillståndsnivå är en förmåga, inte ett godkännande. De möjliggörande raderna ser ut så här, med en sökväg som står i stället för din.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

Nivå 0 avvisar externa program och nivå 1, standarden, tillåter bara klientens inbyggda körbara filer, så en krok behöver 2 eller högre; nivå 3 finns mest för att föra vidare gamla lösenord och bör undvikas. En profil som levereras med en krok behöver både direktivet och den nivån, därför förtjänar en rad nära botten av filen samma granskning som certifikatblocket. OpenVPN-handboken listar tillståndsnivåerna, och dess ordalydelse är värd att läsa vid sidan av vad profilen faktiskt begär.

Ägarskap, sökväg och vad hjälparen matas med

En profil du litar på men som pekar på ett skript som ett annat konto kan skriva om är ingen pålitlig ordning, eftersom gårdagens granskning inte längre beskriver vad som körs i dag. Kontrollera hjälparens ägare och läge, och kontrollera att den konfigurerade sökvägen leder till filen du undersökte och inte till ett namn som något annat kan skugga. Argument och miljö förtjänar samma blick: klienten ger anslutningsdetaljer till kroken, och en hjälpare som loggar hela sin miljö skriver kanske inloggningsuppgifter i ett supportärende. Föredra en dokumenterad integration från operatören eller plattformen framför ett DNS-skript kopierat från ett orelaterat inlägg, eftersom två resolver-administratörer som bråkar om samma fil ger ett fel som ser ut som en trasig VPN.

När du rapporterar en krok som misslyckas, redigera miljön innan du klistrar in den någonstans. Den dump som hjälper dig felsöka kan också bära den token som autentiserar dig.

Städningsfel dyker upp efter att tunneln är borta

En up-hjälpare lägger till rutter och resolverinställningar, och down-hjälparen ska ta bort dem igen. När down-kroken saknas, misslyckas tyst eller aldrig körs för att klienten dödades, överlever resterna sessionen. Trafiken tar då en väg som ingen planerade och namn löses via en resolver som borde ha tagits bort, medan tunneln själv ser frisk ut. De symptomen kommer efter frånkopplingen, därför får nätverket skulden i stället för profilen.

Testa nedmonteringen som ett eget steg: res tunneln, notera rutter och resolver, släpp den, och bekräfta sedan att båda är borta. En profil som ansluter rent kan ändå lämna tillstånd efter sig, och en noll-exitkod från hjälparen bevisar inte att resolvern hamnade där du tror.

Att granska hjälparen och behålla en utväg

Läs skriptet från början till slut och leta efter tre saker: kommandon som kräver privilegier, hårdkodade sökvägar som kanske inte finns på ditt system, och alla nätverksanrop det gör. Titta sedan på hur det misslyckas, för en hjälpare som sväljer fel förvandlar ett konfigurationsfel till ett mysterium. Om du inte kan säga i en mening vad skriptet gör och vem som kan ändra det, är du inte redo att aktivera det. En profil som begär mer privilegium än den meningen kräver är signalen att stanna.

Förvara den senast fungerande profilen och hjälparen den hänvisade till i skyddad lagring, med båda versionerna noterade, så att en återställning är en kopia och inte en återuppbyggnad i värsta möjliga ögonblick. Om hjälparen bara finns för en distribution eller klientversion som inte längre behöver den, pensionera den i konfigurationen som äger inställningen i stället för att höja privilegierna tills felen upphör. Det är utvägen: färre rörliga delar, inte mer tillstånd.