Ang tunnel na umaakyat at pagkatapos ay nagre-restart tuwing kalahating minuto ay kadalasang hindi problema sa cipher o MTU. Isang identidad ito na ginagamit nang dalawang beses. Nakikita ng server ang pamilyar na common name, tinatanggap ang bagong session bilang pinakabago, at natutuklasan ng lumang device na napalitan na ito. Sa panig ng client, mukha itong timeout ng kawalan ng aktibidad at restart, kaya napakadalas magsimula ng imbestigasyon sa maling lugar.

Magsimula sa pagitan ng restart

Ang pagitan ay isang pahiwatig bago ang lahat. Ang pantay na ritmo na tumutugma sa ping-restart window ay tumuturo sa session na pinapalitan at hindi sa landas na nabibigo, dahil bihirang maging regular ang mga pagkabigo ng landas. Itala ang eksaktong agwat sa pagitan ng mga restart at ang linyang dahilan sa log ng client. Ang timeout na sinusundan ng restart ay nagsasalaysay ng ibang kuwento kaysa sa nabigong handshake.

Tingnan kung kailan nagsimula ang mga restart kaugnay ng pangalawang device. Ang bagong laptop, telepono, o profile na kinopya sa ekstrang makina ang karaniwang dahilan, at kadalasang tumutugma ang oras sa araw na may nag-set up nito.

Isulat ang pagitan at ang dahilan. Pareho silang ebidensya, at pareho silang murang kolektahin.

Basahin ang sinabi ng server tungkol sa pangalawang login

Sa server na kontrolado mo, binabanggit ng log ang common name at ipinapakita ang pangalawang koneksyong dumarating. Kung walang duplicate-cn, pinapalitan ng pagdating na iyon ang umiiral na session para sa parehong pangalan, at kadalasang sinasabi ito nang tuwiran ng mensahe. Sa duplicate-cn, magkasamang umiiral ang dalawang session at nagbabago ang sintomas: nananatiling online ang mga client ngunit nagbabahagi ng isang set ng setting bawat client at isang desisyon sa pagbawi. Basahin ang dalawang entry nang magkasama, dahil sa pagkakasunod-sunod lang nakikita ang pagpapalit.

Sa isang hosted na serbisyo, maaaring wala kang anumang server log. Ang pahiwatig ay ang oras: isang matatag na tunnel na bumabagsak tuwing may kumokonektang ibang makina, at wala sa log ng client maliban sa timeout.

Ihambing ang mga bloke ng certificate at key sa dalawang profile, hindi lang ang remote hostname. Ang mga kinopyang profile ay kadalasang nagkakaiba lang sa pangalan ng file.

Hatiin ang identidad sa panig ng server

Maglabas ng isang certificate bawat device sa pamamagitan ng CA na pumipirma para sa server na ito. Sa Easy-RSA, nangangahulugan iyon ng hiwalay na pangalan ng client para sa bawat device, at mula sa certificate na iyon at sa key nito bubuuin ang profile. Ang common name ang nagiging identidad ng device, at ito mismo ang kulang sa server. Pangalanan sila ayon sa device at hindi ayon sa tao, upang ang pagpapalit ay makabuo ng bagong pangalan.

Ang shared control-channel key ay ibang bagay. Pinoprotektahan ng tls-crypt o tls-auth ang control channel para sa bawat client at sinadya itong ibahagi. Hindi ito identidad ng client, at ang pagpapalit nito ay hindi mag-aayos ng dobleng certificate.

Panatilihin ang certificate, key at anumang configuration file bawat client sa ilalim ng parehong common name, kung hindi ay masisira ang mapping sa susunod na koneksyon. Ang hindi pagkakatugma doon ay lumilikha ng client na nagpapatunay at pagkatapos ay walang natatanggap.

Panatilihing pantay ang mga address at setting pagkatapos ng paghahati

Ang mga fixed address ay nagdadala ng pangalawang paraan ng pagbangga. Kung ibinibigay ito ng server sa pamamagitan ng ifconfig-pool-persist o file bawat client, ang mga record na iyon ay tumuturo pa rin sa lumang pangalan. Maaaring magkaroon ng parehong tunnel address ang dalawang device kahit pagkatapos mahati ang mga certificate, at iba ang hitsura ng pagkabigong iyon kaysa sa orihinal na loop.

I-update ang mapping kasabay ng certificate, pagkatapos ay ikonekta muli ang dalawang device at ihambing ang mga address na ibinigay. Ang dobleng address ay lumalabas bilang pahinto-hintong pagkawala at hindi bilang malinis na muling pagkonekta.

Ipadala ang mga setting na dapat magkaiba bawat device sa pamamagitan ng sariling file ng device na iyon, hindi sa shared template. Mas mahirap ding mapansin ang susunod na doble kapag may shared template.

Iretiro nang maayos ang lumang identidad

Bawiin ang certificate kapag itinapon o nawala ang hardware, sa halip na burahin ang profile mula sa lumang makina. Ang pagbawi ay gumagawa ng bagong CRL, at kailangan ng server ang file na iyon kung saan tumuturo ang crl-verify. Kapag naroon ang direktibang iyon, ang nawawala o hindi mababasang CRL ay nagiging dahilan upang tanggihan ng server ang bawat client, kaya subukan ang isang kilalang account pagkatapos ng bawat update.

Panatilihin ang isang imbentaryo na nag-uugnay sa bawat certificate sa isang tao o device, kasama ang mga petsa ng paglabas at pagbawi. Sinasagot ng imbentaryo iyon kung sino pa ang may access nang hindi binabasa ang mga pangalan ng file, at pinipigilan nito ang susunod na kinopyang profile na magsimula muli ng loop.

Kaugnay na mga artikulo