Zakaj je lahko VPN videti povezan, ko nič ne deluje
Povezano lahko opisuje proces, vmesnik ali asociacijo namesto uporabne poti. Pošljite eno novo zahtevo in preberite, kaj dokazuje, da se je promet premaknil.
Vaš odjemalec poroča povezano, medtem ko je vmesnik gor in brskalnik poteče, in nobena od teh treh trditev ni napačna. Povezano opisuje plast, ki nima nič skupnega s stranjo, ki ste jo zahtevali. Da ugotovite, katera plast poroča, potrebujete eno novo zahtevo in en pogled na števec, ki bi dokazal, da se je promet premaknil. Ponovni zagon zavrže ta dokaz in znova zgradi pogoje, ki ste jih poskušali opazovati.
Tri različne stvari, imenovane povezano
Na dnu lahko povezano pomeni, da proces odjemalca teče in drži vtičnico proti partnerju. Višje lahko pomeni, da obstaja vmesnik z naslovom, ki ga trajna naprava ali rutina za obnovitev lahko ustvari brez žive seje za njim. Na ravni nadzora lahko pomeni, da je bila asociacija dogovorjena, kar ne pove nič o tem, ali je pod njo šel en sam paket. Vsaka od njih preživi okvare, ki jih druge ne preživijo, in odjemalec običajno prikaže najmočnejšo, ki jo lahko zahteva.
Zelena ikona in mrtev tunel sta zato združljiva in ne nasprotujoča; poročata o različnih objektih. To je ves razlog, da je ta okvara vedno znova napačno diagnosticirana kot napaka odjemalca.
Pošljite eno neškodljivo zahtevo na cilj, ki ga resnično potrebujete, preden se dotaknete demona, in med delom pustite zahtevani blok neposrednega prometa na mestu. Ponovni zagon izbriše vrstni red dogodkov in jih nato znova ustvari dovolj blizu, da skrije vzrok, zato se ista zahteva vrne teden kasneje brez česa novega. Ena zahteva, en odčitek števca in sprožilec, ki je povzročil okvaro, so najmanjši dokaz.
Kateri števec dokazuje, da so se paketi premaknili
V IPsec sta asociacija IKE in asociacija CHILD ločena objekta in samo child nosi števce, ki odgovarjajo na to vprašanje. Izpišite child, opazujte, ali paketi rastejo v obe smeri, in primerjajte s tem, kar poskuša storiti aplikacija. Nameščena asociacija na ničli je drugačna ugotovitev kot tista, ki raste, medtem ko aplikacija še vedno ne uspe; prva pomeni, da promet ni izbran, druga, da se premika in je napaka dlje. Preberite števce dvakrat, nekaj sekund narazen, ker en vzorec ne more pokazati trenda.
swanctl --list-sas ip xfrm state list ip -s link show dev tun0
Ničelni števci kažejo na izbiro: usmerjanje, politiko, imenski prostor, iz katerega je paket odšel, ali vmesnik, na katerega se odjemalec nikoli ni vezal. Naraščajoči števci kažejo stran od tunela, zato nadaljujte s posredovanjem na oddaljenem koncu, razreševanjem imen, povratno potjo in ciljno storitvijo, v tem vrstnem redu. Protokol brez ločenega objekta child razkrije isti dokaz v svojih lastnih izrazih, zato uporabite, kar poroča o stanju partnerja in številu paketov, namesto da si izposojate besedišče IPsec. Oblika odčitka je pomembnejša od orodja, ki ga je ustvarilo.
Kje je napaka, potem ko se števci premaknejo
Prehod, ki odgovarja na lastnem upravljalnem naslovu, dokazuje, da prehod deluje, ne da nekaj za njim streže vaši zahtevi, zato preizkusite oddaljeno stran in ne škatle na sredini. Razreševanje imen najbolje skriva okvare, ker resolver, ki ni dosegljiv skozi tunel, poteče enako kot mrtva povezava. Dve poizvedbi ločita ta primera in obe sta poceni. Najprej vprašajte resolver, ki ga tunel vsiljuje, nato vprašajte javni resolver za isto ime.
dig +short host.example dig +short @10.20.0.1 host.example ping -c 2 10.20.0.25
Ime, ki se razreši prek javnega resolverja, ne pa prek tunelskega, pomeni, da je pot DNS prekinjena, medtem ko ime, ki se razreši prek obeh in v brskalniku še vedno poteče, kaže na povratno pot ali na storitev. Če ping po naslovu uspe in aplikacija še vedno zavrača, je omrežje zahtevo dostavilo in storitev jo je zavrnila, kar je povsem poznejša stopnja.
Zapišite sprožilec, nato spremenite eno stvar
Zapišite, kaj je bilo pred okvaro: obdobje nedejavnosti, sprememba omrežja, obnovitev ključa, prebujen prenosnik ali obnovljen sistem. Ti ustvarijo različne mehanizme in običajno se sam popravi le obnovljen sistem, kar je natanko tisti primer, ki vas ničesar ne nauči. Ponovni zagon odstrani vrstni red dogodkov in nato znova ustvari pogoje dovolj blizu, da skrije vzrok. Zapišite sprožilec, dokler je še ponovljiv.
Nato naredite eno podprto popravek in ponovite prvotno zahtevo skupaj s sprožilcem, ki je povzročil okvaro. Nedejavnost je najlažje ponovljiv sprožilec, zato je najhitrejša potrditev, da je popravek obravnaval mehanizem in ne simptoma.
Kar želite sporočiti, je dokaz, da je promet, ki ste ga nameravali poslati, dosegel storitev, ki ste jo nameravali doseči. Ikona, ki postane zelena, stran iz predpomnilnika, ki se naloži, in števec, ki se premakne, vsi dokazujejo manj kot ena dokončana zahteva na predvideni cilj. Držite zahtevo, odčitek števca in sprožilec skupaj, da lahko naslednja oseba loči popravek od naključja.