Din .ovpn-fil kan kjøre kode, ikke bare rute trafikk

De fleste leser en .ovpn-fil slik de leser innstillingssiden til en ruter: adresser, ruter, en liste over chifre. Den delen som kjører kode, ligger nær bunnen, ved siden av direktiver som ser ut som rørleggerarbeid, og den kjører med hvilke privilegier klienten nå enn har. Det er gapet en slurvete eller ondsinnet profil utnytter, og det er også gapet som gjør en nyttig DNS-hjelper til et støtteproblem tre uker senere. Hendelsesdirektivet, sikkerhetsnivået og filens eierskap avgjør hva som kan skje; innholdet i skriptet avgjør hva som faktisk skjer. Les alle fire før du kobler til.

En profil som kjører en hjelper, er et program, ikke en innstillingsfil

Direktiver som route og dhcp-option beskriver tilstand klienten skal etablere, og klienten behandler dem som data. Et up-skript er annerledes: klienten starter det som en prosess og gir det et miljø fullt av tilkoblingsdetaljer, så alt forfatteren skrev, kjører med rettighetene til kontoen din. På en bærbar PC der brukeren er administrator, er det en bred dør for en fil som kom som vedlegg eller som limt inn tekst fra en forumtråd. Forskjellen er ikke stilistisk, det er forskjellen mellom konfigurasjon og kode.

Myten det er verdt å legge død, er at en profil bare kan omdirigere trafikk. En hjelper som kjører ip route add, og en som kjører curl mot en ekstern vert, er samme mekanisme, og profilen ser identisk ut utenfra. Ingenting i filens utseende forteller hvilken du har, og derfor må gjennomgangen nå helt inn til selve skriptet.

Hva som faktisk avgjør kjøringen, og hvordan de muliggjørende linjene ser ut

Tre ting styrer en hjelper: hendelsesdirektivet som navngir den, script-security-nivået som tillater den, og klientplattformens egen implementasjon. En profil kan be om en krok og likevel ikke se noe skje, fordi en mobilklient eller en nedskalert skrivebordsbygging kanskje ikke implementerer den hendelsen i det hele tatt. På samme måte sier en profil som ber om mer tillatelse enn funksjonen trenger, noe om opphavet sitt. Et tillatelsesnivå er en evne, ikke en godkjenning. De muliggjørende linjene ser slik ut, med en sti som står i stedet for din.

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

Nivå 0 avviser eksterne programmer, og nivå 1, standarden, tillater bare klientens innebygde kjørbare filer, så en krok trenger 2 eller høyere; nivå 3 finnes mest for gammel passordoverføring og bør unngås. En profil levert med en krok trenger både direktivet og det nivået, og derfor fortjener én linje nær bunnen av filen samme gransking som sertifikatblokken. OpenVPN-håndboken lister tillatelsesnivåene, og ordlyden er verdt å lese ved siden av det profilen faktisk ber om.

Eierskap, sti og hva hjelperen fores med

En profil du stoler på, men som peker på et skript en annen konto kan skrive om, er ikke en pålitelig ordning, fordi gjennomgangen fra i går ikke lenger beskriver det som kjører i dag. Sjekk eieren og modusen til hjelperen, og sjekk at den konfigurerte stien peker på filen du undersøkte, og ikke på et navn noe annet kan skygge for. Argumenter og miljø fortjener samme blikk: klienten gir tilkoblingsdetaljer til kroken, og en hjelper som logger hele miljøet sitt, skriver kanskje legitimasjon i en støttebillett. Foretrekk en dokumentert integrasjon fra operatøren eller plattformen fremfor et DNS-skript kopiert fra et urelatert innlegg, fordi to resolver-administratorer som krangler om samme fil, gir en feil som ser ut som en ødelagt VPN.

Når du rapporterer en krok som feiler, sladd miljøet før du limer det inn noe sted. Dumpen som hjelper deg å feilsøke, kan også bære tokenet som autentiserer deg.

Oppryddingsfeil dukker opp etter at tunnelen er borte

En up-hjelper legger til ruter og resolver-innstillinger, og down-hjelperen skal fjerne dem igjen. Når down-kroken mangler, feiler stille eller aldri kjører fordi klienten ble drept, overlever restene økten. Trafikken tar da en vei ingen planla, og navn slås opp gjennom en resolver som skulle vært fjernet, mens tunnelen selv ser sunn ut. Disse symptomene kommer etter frakoblingen, og derfor får nettverket skylden i stedet for profilen.

Test nedrivingen som et eget trinn: hent tunnelen opp, noter rutene og resolveren, slipp den ned, og bekreft deretter at begge er borte. En profil som kobler seg rent til, kan likevel etterlate tilstand, og en null-utgangskode fra hjelperen beviser ikke at resolveren havnet der du tror.

Å gjennomgå hjelperen og beholde en utvei

Les skriptet fra ende til annen og se etter tre ting: kommandoer som trenger privilegier, hardkodede stier som kanskje ikke finnes på systemet ditt, og ethvert nettverkskall det gjør. Se så hvordan det feiler, fordi en hjelper som svelger feil, gjør en konfigurasjonsfeil til et mysterium. Hvis du ikke kan si i én setning hva skriptet gjør og hvem som kan endre det, er du ikke klar til å aktivere det. En profil som ber om mer privilegium enn den setningen krever, er signalet om å stoppe.

Oppbevar den siste fungerende profilen og hjelperen den viste til, i beskyttet lagring med begge versjonene notert, slik at en tilbakerulling er en kopi og ikke en gjenoppbygging i det verste øyeblikket. Hvis hjelperen bare finnes for en distribusjon eller klientversjon som ikke lenger trenger den, pensjoner den i konfigurasjonen som eier innstillingen i stedet for å heve privilegier til feilene slutter. Det er utveien: færre bevegelige deler, ikke mer tillatelse.