Kördes OpenVPN up-skriptet för tidigt, eller var det aldrig klart?

up-skriptet körs, avslutas med noll, och uppgiften inuti når inte en privat tjänst som från en terminal fungerar perfekt två sekunder senare. Instinkten säger timing, och den vanliga reparationen är en paus, som döljer kapplöpningen utan att förstå den. Den mer användbara läsningen är att “up” namnger en hook, inte en garanti för beredskap. Den utlöses när tunnelenheten är konfigurerad, vilket är tidigare än rutter, DNS och absolut tidigare än någon applikation bakom tunneln.

Skaltestet lyckades eftersom det kördes efter att allt hade lugnat sig. Hooken kördes vid en bestämd tidpunkt.

Var up ligger i startordningen

OpenVPN konfigurerar tunnelenheten och kör sedan up-hooken. Ruttinstallation är ett senare steg, och det har sin egen hook, därför kan en ruttberoende uppgift placerad i up se en enhet utan användbar väg. Lägg ruttarbetet i route-up och timingproblemet försvinner oftast.

Handboken dokumenterar denna ordning och den miljö varje hook får. Den ordningen är hela förklaringen till den klassiska rapporten “fungerar från mitt skal”, och det är också därför samma skript kan passera på en maskin och misslyckas på en annan med ett långsammare ruttsteg. Ingen av resultaten säger något om skriptets kvalitet.

DNS och applikationsberedskap kommer ännu senare. Inte ens installerade rutter är bevis för att den avlägsna slutpunkten lyssnar, att ett namn löses upp, eller att det finns en skrivbordssession för en användaromfattande uppgift.

Vad hooken faktiskt ärver

En hook körs under OpenVPN-processens konto och miljö, vilket inte är samma sak som ditt interaktiva skal. Den kan sakna en användares sessionsbuss, en skrivbordsmiljö eller en autentiseringsuppgift som bara låses upp vid inloggning. Skriv ner vilka av dessa uppgiften faktiskt behöver.

Det spelar roll för uppgifter som ser ut som nätverk men beror på en användarkontext: montera en delning med en användaruppgift, ställa in en proxy per användare eller konfigurera en skrivare. En privilegierad tunnelhook är fel plats för dem, och ingen mängd väntan åtgärdar en saknad session.

När en uppgift misslyckas i en hook, registrera kontot, miljön och den första operationen som misslyckades. Det skiljer för tidig timing från ett behörighets- eller kontextproblem, och de två har helt olika reparationer. Att gissa mellan dem är hur en femminutersfix blir en hel eftermiddag.

Varför det att lägga till en paus inte är en beredskapskontroll

En paus fördröjer skriptet och förskjuter kapplöpningsfönstret. En snabb dag lyckas uppgiften; en långsam dag misslyckas den igen, och felet blir svårare att återskapa eftersom fördröjningen verkar fungera. En fördröjning som bara fungerar under lätt belastning är en slump, inte en reparation.

Om beroendet är en rutt, använd hooken som motsvarar ruttinstallation. Om beroendet är en tjänst bakom tunneln, använd en avgränsad kontroll som väntar på det specifika villkoret och misslyckas tydligt när det aldrig inträffar.

Håll felet explicit. En hook som avslutas med noll medan det faktiska arbetet misslyckades är värre än en hook som misslyckas, eftersom tjänstehanteraren registrerar en framgång och ingen tittar igen. En logglinje från skriptet självt är det billigaste sättet att hålla det ärligt.

Städning och återanslutning förtjänar samma omsorg

Ett skript som ändrar delat tillstånd behöver en matchande ångraväg. Rutter, resolverposter och brandväggsmarkeringar som en hook lägger till bör vara idempotenta och reversibla, annars staplar en återanslutning en andra kopia ovanpå den första.

Återanslutningar kan också köra hooks oftare än en full tjänstestart. Ett beständigt gränssnitt som återupprättar en session kan utlösa up- och route-up-cykeln igen, så ett skript som antar en körning per uppstart kommer till slut att bete sig fel. Räkna körningarna i loggen under en dag av fladdrande för att se hur ofta det faktiskt körs. Gör sedan skriptet säkert att köra så många gånger.

Testa livscykeln som misslyckades, inte ett senare kommando. Återskapa uppstarten eller återanslutningen, se hooken köras och bekräfta att uppgiften lyckades i det ögonblick den faktiskt körs. En framgång från ett interaktivt skal efteråt är bevis om beroendet, inte bevis för att startvägen fungerar.

Namnge händelsen varje uppgift beror på och koppla sedan uppgiften till den händelsen. Allt annat är en fördröjning som låtsas vara en kontroll.