Hvorfor vpnc kobler fra etter 24 minutter, og hva du bør endre
Et vpnc-brudd etter 24 minutter er en timer, ikke en ustabil linje. Tre betingelser avgjør om løsningen er DPD, NAT-gjennomgang eller rekey-gruppen.
Tunnelen din dør med et gjentakende intervall, og det er en timer som melder om seg selv, ikke en dårlig kabel. Tjuefire minutter er 1440 sekunder, den typen runde verdi som en profil eller en policy ved hovedenden bærer. Deretter feiler den samme konfigurasjonen mot den samme konsentratoren hver gang mens alle andre nettverk fungerer, og ingen mengde lenketesting endrer det.
Tre betingelser avgjør hvilken timer som er din: om klienten gir opp en inaktiv økt, om rekey-utvekslingen avvises, og om en oversettende gateway har skrevet om innkapslingen.
Hvilken timer eier bruddet
Mål intervallet over minst tre gjenoppkoblinger før du rører en innstilling. En spredning på sekunder peker på lenketap eller trådløs roaming; en verdi som hver gang lander innen noen sekunder fra samme merke, peker på en policyverdi. Øktlengden forteller også hvem som avsluttet den, fordi en tidsavbrudd på klientsiden og en sletting på serversiden etterlater forskjellige siste linjer i feilsøkingsutdataene. Tre gjenoppkoblinger avdekker også om intervallet i det hele tatt driver, noe en enkelt måling ikke kan vise.
Skriv ned tallet ved siden av hovedenden du snakket med. Når intervallet er stabilt, består det gjenværende arbeidet i å velge mellom tre årsaker, og én endret innstilling per gjenoppkobling er det som holder dem atskillelige.
Sak én: klienten gir opp en inaktiv økt
vpnc kjører sin egen død-peer-sjekk, og den sjekken kan drepe en økt som konsentratoren fortsatt tror er levende, særlig når en oversettende gateway sitter mellom de to. Klientsideløsningen i dokumentasjonen er å slå av timeren lokalt og la hovedenden avgjøre når en peer er borte. Begge linjene nedenfor hører i vpnc-profilen eller på kommandolinjen, og begge er uavhengige av krypteringsinnstillingene.
DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp
Deaktivering av klient-DPD fjerner en falsk positiv og fjerner også din eneste lokale deteksjon, så bruk den alene og se om intervallet i det hele tatt endrer seg.
Sak to: rekey avvises
Hvis intervallet overlever DPD-endringen, blir rekey i fase 1 kandidaten. Eldre vpnc-bygg håndterte rekey mindre nøye enn dagens, og Diffie-Hellman-gruppen er den vanlige uenigheten. Å tvinge en gruppe som hovedenden allerede godtar, koster én linje og én gjenoppkobling, noe som gjør det til et billig eksperiment og ikke en policyendring.
IKE DH Group dh5
Gyldige gruppenavn er dh1, dh2 og dh5. En gruppe som konsentratoren avviser, gir en umiddelbar feil, og det er fortsatt informasjon: det forteller at hovedenden er kresen og at den opprinnelige gruppen trolig var riktig.
Sak tre: oversettelse skriver om innkapslingen
Bak en oversettende gateway er Ciscos UDP-innkapsling og den standardbaserte modusen ikke utskiftbare. Det gale valget gir ofte en tunnel som etableres, slipper trafikk gjennom og deretter utløper under last, noe som leses som et båndbreddeproblem og ikke er det. Endre bare modusen, koble deretter til på nytt og mål bruddet igjen. Prøv den andre modusen først etter at de to første sakene er utelukket.
Frontendene legger til sin egen forvirring her. NetworkManager tilbyr ikke en vpnc-tilkoblingstype før plugin-pakken er installert, og en manglende plugin vises som en gråtonet Legg til-knapp i stedet for en feil. KDEs frontend holder de samme verdiene i sin egen profil, så bekreft at daemonen leser det du redigerte.
En profil som kobler fint fra kommandolinjen men ikke fra skrivebordet, er et frontend-problem, ikke et timerproblem.
Bekreft utvekslingen som feiler før den tredje endringen
Kjør klienten med feilsøkingsutdata og les den siste utvekslingen før bruddet. En sletting av fase 1 rett før frakoblingen betyr at klienten gjorde rekey og ble avvist. En sletting av fase 2 på samme punkt betyr at tunnelen ble revet ned fra den andre siden, og at klientinnstillingene dine ikke er årsaken.
vpnc --debug 3 office
Sjekk også etter en andre nettverksdaemon når tunnelen overlever men trafikken stopper. To behandlere som skriver rutetabellen gir det samme symptomet fra skrivebordet og en helt annen logg.