Din .ovpn-fil kan udføre kode, ikke bare dirigere trafik

De fleste læser en .ovpn-fil, som de læser en routers indstillingsside: adresser, ruter, en liste over cifre. Den del, der udfører kode, ligger nær bunden, ved siden af direktiver, der ligner VVS-arbejde, og den kører med hvilke privilegier klienten nu engang har. Det er det hul, en sjusket eller ondsindet profil udnytter, og det er også det hul, der gør en hjælpsom DNS-hjælper til et supportproblem tre uger senere. Begivenhedsdirektivet, sikkerhedsniveauet og filens ejerskab afgør, hvad der kan ske; scriptets indhold afgør, hvad der faktisk sker. Læs alle fire, før du forbinder.

En profil, der kører en hjælper, er et program, ikke en indstillingsfil

Direktiver som route og dhcp-option beskriver tilstand, som klienten skal etablere, og klienten behandler dem som data. Et up-script er anderledes: klienten starter det som en proces og giver det et miljø fuld af forbindelsesdetaljer, så hvad end forfatteren skrev, kører med din kontos rettigheder. På en bærbar computer, hvor brugeren er administrator, er det en bred dør for en fil, der ankom som bilag eller som indsat tekst fra en forumtråd. Forskellen er ikke stilistisk, det er forskellen mellem konfiguration og kode.

Myten, der er værd at pensionere, er, at en profil kun kan omdirigere trafik. En hjælper, der kører ip route add, og en, der kører curl mod en fjern vært, er den samme mekanisme, og profilen ser identisk ud udefra. Intet i filens udseende fortæller, hvilken du har, og derfor skal gennemgangen nå helt ind til selve scriptet.

Hvad der faktisk afgør udførelsen, og hvordan de muliggørende linjer ser ud

Tre ting styrer en hjælper: begivenhedsdirektivet, der navngiver den, script-security-niveauet, der tillader den, og klientplatformens egen implementering. En profil kan anmode om en krog og alligevel ikke se noget ske, fordi en mobil klient eller et reduceret skrivebordsbyggeri måske slet ikke implementerer den begivenhed. Ligesom en profil, der beder om mere tilladelse, end dens funktion kræver, fortæller dig noget om sin oprindelse. Et tilladelsesniveau er en evne, ikke en godkendelse. De muliggørende linjer ser sådan ud, med en sti, der står i stedet for din.

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

Niveau 0 afviser eksterne programmer, og niveau 1, standarden, tillader kun klientens indbyggede eksekverbare filer, så en krog kræver 2 eller højere; niveau 3 findes mest til gammel adgangskodeoverførsel og bør undgås. En profil, der leveres med en krog, kræver både direktivet og det niveau, og derfor fortjener én linje nær bunden af filen samme granskning som certifikatblokken. OpenVPN-manualen lister tilladelsesniveauerne, og dens ordlyd er værd at læse ved siden af, hvad profilen faktisk beder om.

Ejerskab, sti og hvad hjælperen fodres med

En profil, du stoler på, som peger på et script, en anden konto kan genskrive, er ikke en troværdig ordning, fordi den gennemgang, du lavede i går, ikke længere beskriver, hvad der kører i dag. Kontroller hjælperens ejer og tilstand, og kontroller, at den konfigurerede sti peger på den fil, du undersøgte, og ikke på et navn, noget andet kan skygge for. Argumenter og miljø fortjener samme blik: klienten giver forbindelsesdetaljer til krogen, og en hjælper, der logger hele sit miljø, skriver måske legitimationsoplysninger i en supportbillet. Foretræk en dokumenteret integration fra operatøren eller platformen frem for et DNS-script kopieret fra et uvedkommende indlæg, fordi to resolver-managere, der slås om samme fil, giver en fejl, der ligner en ødelagt VPN.

Når du rapporterer en krog, der fejler, skal du sløre miljøet, før du indsætter det nogen steder. Det dump, der hjælper dig med at fejlfinde, kan også bære det token, der autentificerer dig.

Oprydningsfejl dukker op, efter tunnelen er væk

En up-hjælper tilføjer ruter og resolverindstillinger, og down-hjælperen skal fjerne dem igen. Når down-krogen mangler, fejler i det stille eller aldrig kører, fordi klienten blev dræbt, overlever resterne sessionen. Trafikken tager så en vej, ingen planlagde, og navne slås op gennem en resolver, der skulle have været fjernet, mens selve tunnelen ser sund ud. De symptomer kommer efter afbrydelsen, og derfor får netværket skylden i stedet for profilen.

Test nedrivningen som et selvstændigt trin: rejs tunnelen, noter ruterne og resolveren, luk den, og bekræft så, at begge er væk. En profil, der forbinder rent, kan stadig efterlade tilstand, og en nul-exitkode fra hjælperen beviser ikke, at resolveren endte, hvor du tror.

Gennemgang af hjælperen og at beholde en udvej

Læs scriptet fra ende til anden, og led efter tre ting: kommandoer, der kræver privilegier, hårdkodede stier, der måske ikke findes på dit system, og ethvert netværkskald, det laver. Se så, hvordan det fejler, fordi en hjælper, der sluger fejl, gør en konfigurationsfejl til et mysterium. Hvis du ikke kan sige i én sætning, hvad scriptet gør, og hvem der kan ændre det, er du ikke klar til at aktivere det. En profil, der beder om mere privilegium, end den sætning kræver, er signalet til at stoppe.

Opbevar den sidste fungerende profil og den hjælper, den henviste til, i beskyttet lager med begge versioner noteret, så en tilbagerulning er en kopi og ikke en genopbygning på det værst tænkelige tidspunkt. Hvis hjælperen kun findes for en distribution eller klientversion, der ikke længere har brug for den, skal du pensionere den i den konfiguration, der ejer indstillingen, i stedet for at hæve privilegier, indtil fejlene stopper. Det er udvejen: færre bevægelige dele, ikke mere tilladelse.