Två enheter, ett OpenVPN-certifikat: återanslutningsloopen
En tunnel som startar om varje halvminut är oftast två enheter med samma klientcertifikat. Gå igenom loggen, delningen och avvecklingssteget.
En tunnel som kommer upp och sedan startar om varje halvminut är oftast inte ett cipher- eller MTU-problem. Det är en identitet som används två gånger. Servern ser ett bekant common name, tar den nya sessionen som den nyaste, och den äldre enheten upptäcker att den har ersatts. Från klientsidan ser det ut som en inaktivitets-timeout och en omstart, och därför börjar undersökningen så ofta på fel ställe.
Börja med omstartsintervallet
Intervallet är en ledtråd före allt annat. En jämn takt som matchar ping-restart-fönstret pekar på en session som ersätts snarare än en väg som fallerar, eftersom vägfel sällan är så regelbundna. Notera det exakta avståndet mellan omstarterna och orsaksraden i klientloggen. En timeout följd av en omstart berättar en annan historia än ett misslyckat handskakning.
Kontrollera när omstarterna började i förhållande till en andra enhet. En ny bärbar dator, en telefon eller en profil kopierad till en reservmaskin är de vanliga utlösarna, och tidpunkten stämmer oftast med dagen då någon ställde in den.
Skriv ner intervallet och orsaken. Båda är bevis, och båda är billiga att samla in.
Läs vad servern sa om den andra inloggningen
På en server du kontrollerar namnger loggen common name och visar en andra anslutning som kommer in. Utan duplicate-cn ersätter den ankomsten den befintliga sessionen för samma namn, och meddelandet säger oftast det rakt ut. Med duplicate-cn lever båda sessionerna sida vid sida och symptomet ändras: klienterna ligger kvar men delar en uppsättning inställningar per klient och ett återkallningsbeslut. Läs de två posterna tillsammans, eftersom ersättningen bara syns i sekvens.
På en hostad tjänst har du kanske ingen serverlogg alls. Ledtråden är då tidpunkten: en stabil tunnel som faller varje gång en annan maskin ansluter, och inget i klientloggen utöver timeouten.
Jämför certifikat- och nyckelblocken i båda profilerna, inte bara det externa värdnamnet. Kopierade profiler skiljer sig oftast bara i filnamnet.
Dela identiteten på serversidan
Utfärda ett certifikat per enhet via den CA som signerar för den här servern. Med Easy-RSA betyder det ett eget klientnamn för varje enhet, och profilen byggs sedan från det certifikatet och dess nyckel. Common name blir enhetens identitet, och det är precis vad servern saknade. Namnge dem efter enheten i stället för personen, så att ett byte ger ett nytt namn.
Den delade styrkanalnyckeln är en annan sak. tls-crypt eller tls-auth skyddar styrkanalen för varje klient och är avsedd att delas. Den är inte en klientidentitet, och att byta den rättar inte ett dubblerat certifikat.
Håll certifikatet, nyckeln och varje klientkonfigurationsfil under samma common name, annars bryts mappningen vid nästa anslutning. En bristande överensstämmelse där ger en klient som autentiserar och sedan inte tar emot något.
Håll adresser och inställningar i linje efter delningen
Fasta adresser inför ett andra sätt att kollidera. Om servern tilldelar dem via ifconfig-pool-persist eller en fil per klient pekar de posterna fortfarande på det gamla namnet. Två enheter kan hamna med samma tunneladress även efter att certifikaten har delats, och det felet ser annorlunda ut än den ursprungliga loopen.
Uppdatera mappningen samtidigt som certifikatet, anslut sedan båda enheterna igen och jämför adresserna de fick. En dubblerad adress visar sig som periodiskt bortfall i stället för en ren återanslutning.
Skicka inställningar som ska skilja sig per enhet genom den enhetens egen fil, inte genom en delad mall. En delad mall gör också nästa dubblett svårare att upptäcka.
Avveckla den gamla identiteten ordentligt
Återkalla certifikatet när hårdvaran avvecklas eller saknas, i stället för att radera profilen från den gamla maskinen. Återkallelsen skapar en ny CRL, och servern behöver den filen där crl-verify pekar. Med det direktivet på plats gör en saknad eller oläsbar CRL att servern avvisar varje klient, så testa ett känt konto efter varje uppdatering.
Håll ett register som knyter varje certifikat till en person eller enhet, med utfärdande- och återkallelsedatum. Det registret svarar på vem som fortfarande har åtkomst utan att läsa filnamn, och det hindrar nästa kopierade profil från att starta loopen igen.