Detekto de mortinta samtavolano en IKEv2 ne testas vian aplikaĵon

La vivectesto en IKEv2 demandas unu demandon: ĉu la alia samtavolano ankoraŭ respondas en la protektita rega rilato. Ĝi ne mezuras, ĉu interna aplikaĵo estas sana, ĉu vojo ekzistas malantaŭ la enirejo, aŭ ĉu retumi sentiĝas rapida. La testo povas sukcesi dum ĉio utila malantaŭ la tunelo malsukcesas.

Legu la du specojn de pruvoj aparte antaŭ ol ŝanĝi tempigilon.

Kion la vivectesto fakte demandas

Vivecinterŝanĝo sendiĝas ene de la establita IKE-sekurecasocio kaj atendas respondon ene de agordita fenestro. Sukceso signifas, ke la IKE-realigo de la samtavolano ankoraŭ estas tie kaj ankoraŭ pretas paroli. Ĝi diras nenion pri la infanaj sekurecasocioj, kiuj portas trafikon, nenion pri enkursigado preter la enirejo, kaj nenion pri la servo, por kiu vi malfermis la tunelon. Tiuj estas tri apartaj demandoj kun tri apartaj fiaskmanieroj.

Tiu distingo decidas, kien vi rigardas, kiam sesio silentas. Samtavolano, kiu daŭre respondas dum datenvojo estas rompita, indikas politikon, enkursigadon aŭ postan servon. Samtavolano, kiu ĉesas respondi, indikas atingeblon aŭ la propran staton de la malproksima fino.

Legu la sekurecajn asociojn antaŭ la retumilo

La rega stato kaj la datena stato listiĝas aparte tuj kiam vi demandas la demonon, kaj la nombriloj diras, ĉu io ajn estis provita. Infana asocio, kiu neniam instaliĝis, aspektas tute alie ol tiu, kiu instaliĝis kaj poste ĉesis pasigi pakaĵojn, kvankam ambaŭ produktas la saman plendon de uzanto.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Notu la statnomojn laŭvorte en la bileto, kune kun la nombriloj en la momento de la plendo. Priskribo kiel tunelo malsupren kaŝas, kiu el la du asocioj finiĝis, kaj tio kutime estas la sola fakto inda je havo.

Voja fiasko aspektas ĝuste kiel mortinta samtavolano

La enirejo povas respondi al reginterŝanĝoj dum privata servilo estas senreta, plusendita vojo mankas, aŭ interna nomresolvo tute fiaskas. De la kliento, ĉiu el tiuj aperas kiel sesio, kiu estas supre, kaj celo, kiu ne estas. Kontrolu la revenan vojon same zorgeme kiel la antaŭan, ĉar nesimetria enkursigado ĉe la malproksima flanko produktas silenton nur en unu direkto.

Testu la celatan aplikaĵon rekte kaj nomu la adreson, kiun ĝi provis, anstataŭ testi, ĉu la tunelo estas supre. Ping al la enirejo pruvas, ke la enirejo respondas; ĝi neniam pruvis, ke la aplikaĵo faris. Registru la ĝustan adreson, kiun la aplikaĵo provis. Tiu ĉeno mallarĝigas la serĉon poste, kaj ĝi estas la sola fakto, kiun la bileto kutime preterlasas.

Tenu tempigilojn ekster la diagnozo

Mallongigi detekan intervalon ne estas agadŝanĝo kaj ne aldonas kapablon. Ĉe pakaĵperdo ĝi ŝanĝas, kiom rapide fiasko rekoniĝas, kio povas igi simptomon aspekti alie sen plibonigi ion ajn. Registru unue la realan tempon de la fiasko, poste decidi, ĉu la toleremo malĝustas por la ligilo, kiun vi vere havas.

Refreŝigoj de NAT-mapado apartenas al la sama kategorio. Ili tenas tradukitan vojon uzebla, kaj ili ne estas pruvo, ke la malproksima aplikaĵo funkcias.

Kompleta riparpolitiko diras, kion la kliento devas fari, kiam samtavolano deklariĝas morta: restartigi, fermi aŭ teni, kaj kion alia trafiko rajtas fari dum tio okazas. Sen tio, la sama okazaĵo re-diagnoziĝas de nulo ĉiun kvaronon.