Een profiel dat jarenlang werkte, weigert plotseling te starten, en het bericht noemt een richtlijn die niemand zich herinnert te hebben toegevoegd: key-method. Het volgende zoekresultaat stelt voor om key-method 2 toe te voegen voor compatibiliteit, wat advies uit een ander tijdperk is. De parser die de regel verwierp is een huidige, en hij heeft helemaal geen zo’n optie. De regel verwijderen lost het starten op, en het verandert niets aan hoe de twee peers de sessie beschermen.

Precies die kloof tussen wat een profiel bevat en wat het protocol werkelijk doet is het hele onderwerp hier, en ze verklaart verschillende andere bewerkingen die mensen tegelijk doen. Ze verklaart ook waarom die bewerkingen meestal in één bundel komen.

Het symptoom is een parseerfout, geen handshake-fout

Opties worden gelezen voordat er een pakket wordt verzonden. Een profiel met een onbekende richtlijn faalt in die fase, dus het proces bereikt nooit het netwerk en produceert nooit een handshake-fout. De formulering noemt meestal de optie en het bestand, wat dit een van de gemakkelijkst toe te schrijven fouten maakt. Er zijn geen pakket, route of firewall bij betrokken.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

Als het bericht de richtlijn noemt, is de diagnose klaar: het bestand bevat iets wat deze build niet accepteert. Als het bericht in plaats daarvan een bestandspad noemt, is het probleem een ontbrekende include of sleutel, wat een ander deel van dezelfde startfase is.

Wat u niet moet concluderen, is dat de client of server een ouder protocolmodus nodig heeft. Een parseerfout is een vocabulaireprobleem tussen uw bestand en het binaire bestand, en het binaire bestand heeft in dit geval simpelweg een woord uit zijn vocabulaire laten vallen.

Richtlijn en transportformaat zijn twee verschillende dingen

De oude key-method-optie koos hoe de TLS-sleuteluitwisseling werd ingekaderd, en de moderne uitwisseling is de methode met meerdere pakketten die die optie vroeger aanvroeg. De optie verdween omdat ze niets meer koos; het formaat dat ze noemde werd het enige. De regel verwijderen laat de sessie dus dezelfde inkadering gebruiken als voorheen. Een tekstbewerking kan dat in geen enkele richting veranderen.

Daarom is het herinvoeren van een oud binair bestand om methode 2 te „herstellen“ de verkeerde reparatie. Het herstelt niets dan een oudere parser met oudere standaardwaarden, en het kost u de correcties die daarna kwamen. Dezelfde redenering geldt voor het verzwakken van een certificaatcontrole of een cijferlijst in de hoop dat de verbinding terugkomt.

Een nuttige controle is de versie en de geparseerde configuratie, niet de aanwezigheid van het woord in het bestand:

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Wat te verwijderen, en uit welk bestand

Bewerk het bestand dat het draaiende proces werkelijk leest, en alleen dat bestand. Op verpakte systemen is dat meestal het profiel in de client- of servermap die de unit noemt, niet een kopie in uw thuismap die u als referentie bewaart. Een gegenereerd profiel kan ook opnieuw uit een sjabloon worden gebouwd, dus een wijziging die alleen in de uitgerolde kopie is gemaakt, komt na de volgende provisioning-run terug.

Verwijder de verouderde regel en laat het eindpunt, de certificaten, het cijferbeleid en de instellingen van het controlekanaal met rust. Dat zijn ondersteunde opties die het proces nodig heeft, en ze zijn niet betrokken bij de parseerfout. Als hetzelfde profiel andere richtlijnen bevat die u niet herkent, controleer ze dan elk tegen de versie die u draait in plaats van er een groep van te verwijderen tot het proces start.

Start daarna de bedoelde instantie en lees de uitvoer bij het starten. Een schone start met de listener aanwezig is de bevestiging dat deze fase klaar is; een clienttest daarna beantwoordt een andere vraag.

Een geweigerd profiel en een geweigerde client lijken op elkaar

Twee storingen leveren vergelijkbare supportthreads op en vragen om verschillend bewijs. Een server die zijn eigen configuratie weigert, start nooit, dus geen enkele client kan ermee verbinden. Een server die goed start en één client weigert, draait, en zijn log bevat de reden: een certificaatprobleem, een geduwde optie die de client niet accepteert, een cijferverschil.

De verwijderde optie is geen diagnose voor het tweede geval, en ernaar grijpen verspilt hetzelfde uur twee keer. Als het clientlog de weigering van de server toont, lees die weigering; als het een lokale fout toont, is het clientprofiel het bestand om te onderzoeken. Naar een richtlijn grijpen die niet meer bestaat, vertraagt beide onderzoeken evenveel.

Compatibiliteitsvragen die de regel nooit beantwoordde

Profielen die met deze richtlijn rondgaan, dragen meestal een verhaal over een bepaald platform, en het verhaal overleeft de technische reden. Een mobiele of desktopclient heeft nog steeds een volledig ondersteund profiel nodig: een vertrouwde certificaatketen, een gegevenscijfer dat beide uiteinden accepteren, een controlekanaalmodus die beide uiteinden implementeren, en geen richtlijnen die de build van de client weigert. Niets daarvan wordt beslist door de aanwezigheid of afwezigheid van de oude key-method-regel.

Compressie is een aparte beleidsvraag met dezelfde vorm. Een key-method-regel verwijderen zegt niets over of een compressierichtlijn in uw uitrol wordt ondersteund of aanvaardbaar is, en de twee beslissingen moeten onafhankelijk worden genomen. Verschillende beveiligingsrelevante instellingen tegelijk verwijderen tot er iets verbindt, is hoe een werkend profiel een onverklaard profiel wordt.

Houd een korte notitie bij van wat u hebt verwijderd en waarom: de optie, de versie die haar verwierp, en de opdracht die de fout toonde. De volgende persoon die het profiel erft, heeft precies die drie feiten nodig, en ze nu opschrijven is goedkoper dan ze later reconstrueren.

Gerelateerde artikelen