TLS-time-out van zestig seconden: welke kant stopte er werkelijk?

De client geeft na zestig seconden op met een bericht over sleutelonderhandeling, en de laptop heeft geen mening over waarom. Die zin beschrijft het geduld van de client, niet het gedrag van de server. Drie heel verschillende situaties veroorzaken hem: het pakket bereikte nooit de juiste dienst, de dienst gooide het weg voordat er iets werd gelogd, of de dienst wees het af en zei dat ergens waar de client het niet kan zien. Het correleren van één poging aan beide kanten is wat ze onderscheidt.

Geef één poging een identiteit die u kunt opzoeken

Noteer de begintijd met de tijdzone, de profielnaam, de bestemming die de client werkelijk heeft opgelost, de poort, en of de verbinding UDP of TCP is. Als het profiel meerdere externe vermeldingen bevat, noteer welke die poging koos, want een nieuwe poging kan naar de volgende vermelding zijn gegaan zonder het bestand te wijzigen dat u leest.

Neem het eindpunt uit het actieve logboek, niet uit de download die u zich herinnert. Een profiel dat naar een privéadres wijst is volstrekt geldig en volstrekt onbruikbaar vanaf een netwerk dat daar niet naartoe kan routeren, en dat geval ziet er identiek uit als een server die plat ligt.

Vraag de beheerder dan om hetzelfde venster op de bedoelde instantie. Klokafwijking komt vaak genoeg voor dat een verschil van een paar minuten een overeenkomstige gebeurtenis afwezig kan laten lijken, dus noteer de afwijking in plaats van te concluderen dat er geen gebeurtenis was.

Vier waarnemingen, vier verschillende vervolgstappen

Wat de server vastlegt bepaalt de tak. Het ontbreken van enige poging wijst op adressering, transport of het pad naar de dienst. Binnenkomende pakketten die vóór een gewone uitwisseling verdwijnen wijzen op de eisen van het besturingskanaal van de werkelijke dienst. Een benoemde afwijzing wijst op het object dat zij noemt. Antwoorden die de server verlaten maar de client nooit bereiken wijzen op het retourpad.

Een leeg applicatielogboek is zwakker bewijs dan het lijkt. Logging begint op een bepaald punt in de uitwisseling, en pakketten die daarvoor worden weggegooid laten geen spoor achter in het bestand dat u leest. Waar dat is toegestaan, kan de beheerder dienst- en netwerkwaarnemingen gebruiken om te zien of er überhaupt iets aankwam.

Houd de vier uitkomsten gescheiden in uw notities. De verleiding is ze samen te voegen tot „de server reageert niet”, en dat is precies de zin die mensen aanzet om de versleuteling te wijzigen wanneer het echte probleem een firewallregel is. Een notitie die alleen het woord time-out vastlegt, heeft het onderscheid weggegooid waarvoor u net betaalde.

Herstel de fase die het bewijs noemt

Een voltooide TCP-verbinding bewijst alleen dat iets een socket heeft aangenomen. Het bewijst niet dat de luisteraar de OpenVPN-dienst is die u hebt ingesteld, en een webserver op dezelfde hostnaam antwoordt een browser perfect terwijl hij voor de tunnel irrelevant is.

Als de server een verlopen intrekkingslijst meldt, is dat een veel specifieker feit dan de uiteindelijke time-out van de client, en de oplossing hoort bij de certificaatautoriteit en niet bij het netwerk. Als de twee kanten het oneens zijn over de bescherming van het besturingskanaal of over gedeeld materiaal, verandert het resetten van een wachtwoord niets, omdat het wegwerpen gebeurt voordat enige referentie wordt onderzocht.

Verander één ding dat het bewijs werkelijk ondersteunt, en herhaal daarna hetzelfde profiel tegen hetzelfde eindpunt. Bewaar de eerste nieuwe gebeurtenis als de verbinding verder komt, want die gebeurtenis is de volgende fase van het onderzoek, geen nieuw probleem.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Wat het verlengen van het venster werkelijk verandert

Zestig seconden is het handshakevenster van de client, en de clientreferentie van de gemeenschap documenteert de optie die het aanpast. Het verhogen ervan laat de client langer wachten voordat hij opgeeft. Het laat een afwezige dienst niet verschijnen en het maakt een geweigerd pakket niet aanvaardbaar.

Een langer venster heeft een legitiem gebruik op een trage verbinding of een zwaar belaste server, en het is de moeite waard om het te proberen zodra u bewijs hebt dat de uitwisseling langzaam vordert in plaats van helemaal niet plaatsvindt. Het eerst proberen stelt alleen dezelfde diagnose nog een minuut uit en maakt de tijdlijn moeilijker leesbaar. Als de tijdlijn een uitwisseling toont die vordert en dan stokt, is het venster een symptoom van belasting en niet van bereikbaarheid.