Via kliento raportas konektita dum la interfaco staras supre kaj la retumilo tempolimas, kaj neniu el tiuj tri asertoj estas malvera. Konektita priskribas tavolon, kiu havas nenion komunan kun la paĝo, kiun vi petis. Decidi, kiu tavolo raportas, postulas unu freŝan peton kaj unu rigardon al la nombrilo, kiu pruvus, ke trafiko moviĝis. Restartigo forĵetas tiun pruvon kaj rekonstruas la kondiĉojn, kiujn vi provis observi.

Tri malsamaj aferoj nomataj konektita

Plej malsupre konektita povas signifi, ke klienta procezo funkcias kaj tenas ingon al samtavolano. Super tio ĝi povas signifi, ke ekzistas interfaco kun adreso, kiun daŭra aparato aŭ reakira rutino povas krei sen viva seanco malantaŭ ĝi. Je la rega nivelo ĝi povas signifi, ke asocio estis intertraktita, kio diras nenion pri tio, ĉu unu paketo trapasis sub ĝi. Ĉiu el tiuj postvivas malsukcesojn, kiujn la aliaj ne postvivas, kaj kliento kutime montras la plej fortan, kiun ĝi povas aserti.

Verda ikono kaj morta tunelo do estas kongruaj, ne kontraŭdiraj; ili raportas pri malsamaj objektoj. Tio estas la tuta kialo, kial ĉi tiu fiasko daŭre estas misdiagnozita kiel klienta cimo.

Sendu unu sendanĝeran peton al celo, kiun vi vere bezonas, antaŭ ol tuŝi la demonon, kaj tenu la postulatan blokon de rekta trafiko en loko dum vi laboras. Restartigo forviŝas la ordon de eventoj kaj poste rekreis ilin sufiĉe proksime por kaŝi la kaŭzon, kaj tial la sama bileto revenas semajnon poste kun nenio nova en ĝi. Unu peto, unu legado de nombrilo kaj la ellasilo, kiu kaŭzis la fiaskon, estas la minimuma pruvo.

Kiu nombrilo pruvas, ke la pakaĵoj moviĝis

En IPsec la IKE-asocio kaj la CHILD-asocio estas apartaj objektoj, kaj nur la child portas la nombrilojn, kiuj respondas ĉi tiun demandon. Listigu la child, observu ĉu pakaĵoj kreskas en ambaŭ direktoj, kaj komparu tion kun tio, kion la aplikaĵo provas fari. Instalita asocio ĉe nulo estas malsama konstato ol tiu, kiu kreskas dum la aplikaĵo ankoraŭ fiaskas; la unua signifas, ke trafiko ne estas elektita, la dua, ke ĝi moviĝas kaj la eraro estas pli antaŭe. Legu la nombrilojn dufoje, kelkajn sekundojn aparte, ĉar unu specimeno ne povas montri tendencon.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Nulaj nombriloj montras al elekto: enkursigado, politiko, nomspaco, el kiu la pakaĵo eliris, aŭ interfaco, al kiu la kliento neniam ligiĝis. Kreskantaj nombriloj montras for de la tunelo, do daŭrigu per plusendo ĉe la malproksima flanko, nomsolvado, la revena vojo kaj la celloka servo, en tiu ordo. Protokolo sen aparta child-objekto elmetas la saman pruvon laŭ siaj propraj terminoj, do uzu tion, kion ĝi raportas pri samtavolana stato kaj paketa nombroj, anstataŭ prunti la vortprovizon de IPsec. La formo de la legado pli gravas ol la ilo, kiu produktis ĝin.

Kie la eraro sidas post kiam la nombriloj moviĝas

Pordego, kiu respondas ĉe sia propra administra adreso, pruvas, ke la pordego funkcias, ne ke io malantaŭ ĝi servas vian peton, do testu la malproksiman flankon anstataŭ la skatolon meze. Nomsolvado plej bone kaŝas fiaskojn, ĉar solvilo, al kiu oni ne povas atingi tra la tunelo, tempolimas same kiel morta konekto. Du serĉoj apartigas tiujn kazojn, kaj ambaŭ estas malmultekostaj. Demandu unue la solvilon, kiun la tunelo puŝas, poste demandu publikan solvilon pri la sama nomo.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Nomo, kiu solviĝas per la publika solvilo sed ne per la tunela solvilo, signifas, ke la DNS-vojo estas rompita, dum nomo, kiu solviĝas per ambaŭ kaj ankoraŭ tempolimas en la retumilo, montras al la revena vojo aŭ al la servo. Se la ping laŭ adreso sukcesas kaj la aplikaĵo ankoraŭ rifuzas, la reto liveris la peton kaj la servo rifuzis ĝin, kio estas tute posta stadio.

Notu la ellasilon, poste ŝanĝu unu aferon

Notu, kio antaŭis la fiaskon: periodo de senaktiveco, reta ŝanĝo, ŝlosila renovigo, rekomencita tekkomputilo aŭ restarigita sistemo. Tiuj produktas malsamajn mekanismojn, kaj nur la restarigita sistemo kutime riparas sin mem, kio estas ĝuste la kazo, kiu instruas al vi nenion. Restartigo forigas la ordon de eventoj kaj poste rekreas kondiĉojn sufiĉe proksimajn por kaŝi la kaŭzon. Skribu la ellasilon dum ĝi ankoraŭ estas ripetebla.

Poste faru unu subtenatan korekton kaj ripetu la originan peton kune kun la ellasilo, kiu kaŭzis la fiaskon. Senaktiveco estas la plej facile ripetebla ellasilo, do ĝi estas la plej rapida konfirmo, ke la riparo traktis la mekanismon anstataŭ la simptomon.

Kion vi volas raporti, estas pruvo, ke la trafiko, kiun vi intencis sendi, atingis la servon, kiun vi intencis atingi. Ikono, kiu verdiĝas, kaŝmemora paĝo, kiu ŝarĝiĝas, kaj nombrilo, kiu moviĝas, ĉiuj pruvas malpli ol unu finitan peton kontraŭ la celita celloko. Tenu la peton, la legadon de la nombrilo kaj la ellasilon kune, por ke la sekva persono povu distingi riparon de koincido.

Rilataj artikoloj