Welke openvpn-binair draait er? Controleer het startpad

Een oude workaround verplaatste het OpenVPN-uitvoerbare bestand naar een andere plek en liet een shell-wrapper achter op het oorspronkelijke pad. Maanden later komt er een upgrade, en het terugdraaien van de workaround wordt een raadspel over welk bestand nu echt de client is. De opdrachtnaam, het in de service geconfigureerde uitvoerbare bestand en de eigen bestandslijst van het pakket kunnen allemaal naar verschillende objecten wijzen, en één ervan repareren zonder de andere levert een host op die er gerepareerd uitziet en zich slechter gedraagt.

Begin bij het pad dat de service start

Een terminal en een systemd-unit lossen uitvoerbare bestanden niet hetzelfde op. De shell zoekt in een PATH; de unit noemt een pad, en drop-in-overschrijvingen kunnen dat vervangen zonder het bestand aan te raken dat je leest. Dat verschil verklaart het grootste deel van de verwarring in deze taak. Het bepaalt ook op welk bestand je reparatie zich moet richten.

Vraag de unit wat hij uitvoert, inclusief de drop-ins die dat wijzigen, en lees de resulterende ExecStart-regel in plaats van het fragment dat je voor gezaghebbend houdt. Volg daarna dat pad via elke symbolische koppeling naar het uiteindelijke bestand. Een wrapper die eindigt met exec naar een verborgen map is een gangbare constructie uit deze oude oplossingen.

Schrijf het opgeloste pad op voordat je iets verandert.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Vergelijk de opdrachtnaam met het servicepad

De twee antwoorden verschillen vaak, en dat verschil is niet automatisch een fout. Een NetworkManager-plugin kan zijn eigen pad starten, en een container kan er nog een mounten.

Wat telt is weten welke eigenaar het proces start dat verkeer bedient. Als de unit /usr/local/sbin/openvpn-wrapper draait terwijl je shell /usr/sbin/openvpn oplost, verandert het repareren van het tweede bestand niets aan de service.

Vraag welk pakket elke kandidaat bezit en beslis dan of het bestand door het pakket wordt beheerd of lokaal is geplaatst. Een bestand zonder bezittend pakket is een bestand dat iemand er bewust heeft neergezet, en het verdient een naam, een eigenaar en een reden voordat het wordt verwijderd. De omgekeerde fout komt ook vaak voor: een pakketbestand overschrijven met een oude bewaarde binaire versie omdat een forumbericht dezelfde map gebruikte.

Laat de pakketdatabase over pakketbestanden spreken

Als de software uit een Debian-pakket komt, kan de pakketdatabase je vertellen of de bestanden nog overeenkomen met wat er is geïnstalleerd. Dat is een nauwe integriteitsvraag, geen veiligheidsoordeel, en het verschil is belangrijk wanneer je besluit wat je repareert. Een afwijking betekent dat het bestand na de installatie is gewijzigd, wat je oude workaround of een legitieme lokale aanpassing kan zijn. De uitvoer beslist niet welke, dus lees het als een aanwijzing en niet als een conclusie.

Voer de verificatie uit en lees de uitvoer in plaats van een leeg resultaat als bewijs van iets te beschouwen.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

De dpkg-handleiding documenteert dat de verificatie geïnstalleerde bestanden vergelijkt met lokaal vastgelegde metadata, met opgeslagen controlesommen waar die bestaan. Het merkt een gewijzigd pakketbestand op, en het kan je niet vertellen of in plaats daarvan een ander binair bestand wordt gestart.

Leg de toestand vast voordat je repareert

Verzamel het opgeloste startpad, de pakketrelatie van het bestand, de locatie van de wrapper en het wijzigingsrecord dat hem heeft ingevoerd. Kopieer de wrapper naar een beschermde plek als hij integratiewerk bevat dat later nodig is.

Plak de inhoud van de wrapper niet in een supportthread voordat je hem hebt gelezen, want deze scripts dragen soms inloggegevens of gateway-details.

Leg vast welke profielen de service gebruikt en wie er verbonden is terwijl je werkt, want het herstarten van de tunnel kan de sessie onderbreken waarmee je de host beheert.

Verifieer de start en ruim daarna de wrapper op

Start na de reparatie de service en bevestig dat het proces het bedoelde pad draait. Een met de hand uitgevoerde versiequery bewijst dat het bestand werkt; het bewijst niet dat de unit het gebruikt.

Verbind daarna opnieuw een client en controleer of het profiel nog authenticeert, want een binaire verwisseling die de oorspronkelijke opties negeert, zal mislukken op een manier die op een certificaatprobleem lijkt.

Ruim de verdrongen wrapper op via hetzelfde wijzigingsrecord dat hem heeft ingevoerd. De afgeronde reparatie vermeldt welk uitvoerbaar bestand draait, waarom en welk bestand is verwijderd; een bestandsnaam herstellen en hopen is niet hetzelfde.