OpenVPN-pakket: HMAC-authenticatie mislukt – welke laag?

Twee fouten worden met hetzelfde vocabulaire gemeld en hebben bijna niets gemeen. De ene is een pakket waarvan de authenticatie-tag niet is geverifieerd; de andere is een persoon wiens inloggegevens zijn geweigerd. De eerste als de tweede behandelen stuurt u op zoek naar een wachtwoord dat nooit het probleem was.

Het bericht noemt een laag, en het nuttige werk is beslissen welke, voordat u materiaal vervangt. De kandidaten naast elkaar vergelijken is de snelste manier om het verschil te zien.

Twee fouten die één woord delen

Een pakket-authenticatiefout ontstaat tijdens het verwerken van verkeer: een tag of digest op een ontvangen pakket kwam niet overeen met wat de ontvanger had berekend. Een accountweigering gebeurt nadat een login-uitwisseling is geparseerd, en die noemt een gebruiker in plaats van een pakket. Een derde bericht, over het niet kunnen vinden van een HMAC in een inkomend pakket, is weer anders, want daar kwam het pakket helemaal zonder het verwachte authenticatie-element aan. Het volledige logprefix vertelt u welke van de drie u hebt, en het prefix is meestal het eerste dat wordt verwijderd wanneer een fout in een ticket wordt geplakt.

Het onderscheid verandert de reparatie. De ene vraagt om overeenkomende kanaalinstellingen, de andere om accountstatus, en de derde om een profiel dat niet past bij de listener die het heeft bereikt.

Vergelijk wat het draaiende proces werkelijk heeft geladen

Een correct bestand op schijf bewijst niets over een proces dat begon voordat het werd bewerkt. Controleer het geselecteerde profiel, het eindpunt dat het heeft benaderd, en of de dienst sinds de wijziging opnieuw is geladen. Bevestig ook dat het eindpunt bij het profiel hoort, want een andere instantie of een andere dienst kan luisteren waar het oude bestand iets anders verwacht.

Een ondersteund profiel opnieuw exporteren uit dezelfde bron is een goedkope vergelijking, omdat het de afwijking wegneemt tussen wat u denkt dat geconfigureerd is en wat de client werkelijk verstuurt. Nieuwe sleutelmateriaal genereren is een veel grotere stap, en het helpt alleen als beide kanten het samen overnemen. Eén kant lokaal vervangen maakt precies de mismatch opnieuw die u probeerde te verwijderen.

Vergelijk het controlekanaal met het datakanaal

Twee mechanismen authenticeren verschillende delen van een verbinding en worden apart geconfigureerd, zoals de 2.6-optiereferentie beschrijft. tls-auth voegt een HMAC toe aan pakketten van het controlekanaal en neemt een richtingsargument dat bij de twee peers tegengesteld moet zijn, terwijl tls-crypt het controlekanaal in plaats daarvan met een gedeelde sleutel beschermt. Geen van beide is de eigen integriteitscontrole van het datakanaal. Bij een AEAD-datacijfer is die controle in het cijfer ingebouwd, dus de aparte auth digest wordt niet gebruikt zoals bij een niet-AEAD-cijfer.

Wat betekent dat een auth regel die uit een werkende niet-AEAD-implementatie is gekopieerd, irrelevant kan zijn in een AEAD-implementatie, en een AEAD-implementatie kan nog steeds mislukken op het controlekanaal als de tls-auth sleutel of de richting ervan onjuist is. Vergelijk elke instelling met de peer in plaats van met een onthouden configuratie.

Vergelijk de oplossing met de eigenschap die u opgeeft

Pakketauthenticatie uitschakelen maakt de waarschuwing stil en verwijdert de controle die de mismatch vond, wat niet hetzelfde is als het profiel repareren. Vraag welke eigenschap u opgeeft en of het ontwerp zonder die eigenschap nog staat.

Lees de eerste relevante gebeurtenis aan beide kanten voordat u iets wijzigt, en wijzig daarna alleen de mismatch die het noemt.

Als de volgende poging doorstroomt naar een certificaat- of login-fout, is dat vooruitgang en geen terugval: de pakketlaag is het nu eens en de verbinding is verder gegaan. Noteer de instellingen die de wijziging veroorzaakten, zodat de volgende persoon een uitleg erft in plaats van een raadsel.