Varför vpnc kopplar ned efter 24 minuter och vad du bör ändra
Ett vpnc-avbrott efter 24 minuter är en timer, inte en instabil länk. Tre villkor avgör om lösningen är DPD, NAT-genomgång eller rekey-gruppen.
Din tunnel dör med ett återkommande intervall, och det är en timer som anmäler sig själv, inte en dålig kabel. Tjugofyra minuter är 1440 sekunder, den sorts runda värde som en profil eller en policy vid huvudänden bär. Sedan misslyckas samma konfiguration mot samma koncentrator varje gång medan alla andra nätverk fungerar, och ingen mängd länktest ändrar det.
Tre villkor avgör vilken timer som är din: om klienten ger upp en inaktiv session, om rekey-utbytet avvisas, och om en översättande gateway har skrivit om inkapslingen.
Vilken timer äger avbrottet
Mät intervallet över minst tre återanslutningar innan du rör en inställning. En spridning på sekunder pekar på länkförlust eller trådlös roaming; ett värde som varje gång landar inom några sekunder från samma märke pekar på ett policyvärde. Sessionslängden berättar också vem som avslutade den, eftersom en timeout på klientsidan och en borttagning på serversidan lämnar olika sista rader i felsökningsutdata. Tre återanslutningar avslöjar också om intervallet driver alls, vilket en enda mätning inte kan visa.
Skriv ned talet bredvid den huvudände du talade med. När intervallet är stabilt består det återstående arbetet i att välja mellan tre orsaker, och en ändrad inställning per återanslutning är det som håller dem åtskiljbara.
Fall ett: klienten ger upp en inaktiv session
vpnc kör sin egen död-peer-kontroll, och den kontrollen kan döda en session som koncentratorn fortfarande tror är levande, särskilt när en översättande gateway sitter mellan de två. Klientsidans lösning i dokumentationen är att stänga av timern lokalt och låta huvudänden avgöra när en peer är borta. Båda raderna nedan hör hemma i vpnc-profilen eller på kommandoraden, och båda är oberoende av krypteringsinställningarna.
DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp
Att inaktivera klient-DPD tar bort ett falsklarm och tar också bort din enda lokala detektering, så använd det ensamt och se om intervallet ändras alls.
Fall två: rekey avvisas
Om intervallet överlever DPD-ändringen blir rekey i fas 1 kandidaten. Äldre vpnc-byggen hanterade rekey mindre noggrant än nuvarande, och Diffie-Hellman-gruppen är den vanliga oenigheten. Att tvinga en grupp som huvudänden redan accepterar kostar en rad och en återanslutning, vilket gör det till ett billigt experiment och inte en policyändring.
IKE DH Group dh5
Giltiga gruppnamn är dh1, dh2 och dh5. En grupp som koncentratorn avvisar ger ett omedelbart fel, och det är fortfarande information: det säger att huvudänden är kräsen och att den ursprungliga gruppen troligen var rätt.
Fall tre: översättning skriver om inkapslingen
Bakom en översättande gateway är Ciscos UDP-inkapsling och det standardbaserade läget inte utbytbara. Det felaktiga valet ger ofta en tunnel som upprättas, släpper igenom trafik och sedan löper ut under belastning, vilket läses som ett bandbreddsproblem och inte är det. Ändra bara läget, återanslut sedan och mät avbrottet igen. Prova det andra läget först efter att de två första fallen uteslutits.
Frontends tillför sin egen förvirring här. NetworkManager erbjuder inte en vpnc-anslutningstyp förrän plugin-paketet är installerat, och en saknad plugin visas som en gråtonad Lägg till-knapp i stället för ett fel. KDE:s frontend håller samma värden i en egen profil, så bekräfta att daemonen läser det du redigerade.
En profil som ansluter bra från kommandoraden men inte från skrivbordet är ett frontend-problem, inte ett timerproblem.
Verifiera utbytet som misslyckas före den tredje ändringen
Kör klienten med felsökningsutdata och läs det sista utbytet före avbrottet. En borttagning av fas 1 omedelbart före frånkopplingen betyder att klienten gjorde rekey och avvisades. En borttagning av fas 2 på samma punkt betyder att tunneln revs ned från andra sidan, och att dina klientinställningar inte är orsaken.
vpnc --debug 3 office
Kontrollera också en andra nätverksdaemon när tunneln överlever men trafiken stannar. Två hanterare som skriver routingtabellen ger samma symptom från skrivbordet och en helt annan logg.