Preverite, ali razdeljeni tunel deluje: en rezultat IP ni preizkus

Ena sama stran brskalnika, ki prikazuje naslov IP, ne dokaže skoraj ničesar o razdeljenem tunelu. Viden naslov je lahko pravi iz napačnega razloga, izključen tok pa z njim ni nikoli preizkušen. Pred preizkusom zapišite pričakovani rezultat: katera aplikacija ali cilj naj uporablja tunel, kateri naj ostane neposreden in kaj naj se ustavi, ko tunel odpove. Brez tega načrta je vsaka verjetna številka videti kot uspeh.

Mit: iskanje naslova dokazuje pokritost

Preverjanje IP odgovori na eno vprašanje: kaj zunanji svet vidi iz ene aplikacije v enem trenutku. Ne pove ničesar o notranji predponi, drugem profilu brskalnika ali imenu, ki bi se moralo razrešiti zasebno. Prav tako ne pove ničesar o okvari, in to je tista polovica zasnove razdeljenega tunela, ki se v produkciji zlomi.

Stran z naslovom tudi ne more prikazati poti, razreševalnika ali politike okvare. Obravnavajte jo kot eno opažanje, ne kot razsodbo.

Preizkusite vključen tok in izključen tok

Pošljite neškodljivo zahtevo iz aplikacije, ki bi morala biti vključena, ali na predpono, za katero pričakujete, da bo usmerjena skozi tunel, in zabeležite vir, cilj, družino naslovov in opaženo pot. Enako storite za tok, ki bi moral ostati neposreden. Izključena stran je tista, ki jo ljudje preskočijo, in je edini dokaz, da je razdelitev namerna in ne naključna. Pomožni proces lahko nosi ločeno identiteto politike, zato preizkusite v procesu, ki ima vtičnico.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Zato lahko preizkus v napačni aplikaciji pokaže nasprotno od tega, kar zasnova namerava. Zapišite štiri polja za obe strani, preden naredite kakršen koli sklep.

Dodajte DNS in primer okvare

Vprašajte sistemski razreševalnik in razreševalnik, ki ga uporablja aplikacija, nato pa te odgovore primerjajte z izhodnim naslovom, ki ga poroča spletno mesto. Plasti se lahko namerno razhajata, in eno iskanje v brskalniku ne preizkusi politike operacijskega sistema. Lupina naredi primerjavo ponovljivo: Tunel namerno prelomite, nato pošljite zahtevo, ki je brskalnik nima v predpomnilniku; stran, postrežena iz predpomnilnika, vam ne pove ničesar o tem, v katero smer je šla rezerva. Zabeležite, kaj se je res zgodilo, namesto tega, kar je zasnova predvidevala.

curl -s https://ifconfig.me
nslookup intranet.example

Razdeljeni tunel, ki odpove zaprt, in tisti, ki odpove odprt, sta videti enako, dokler tunela namerno ne prelomite. Zabeležite, kakšno vedenje ste opazili, ne kakšnega ste pričakovali.

Ponovite po spremembi stanja

Ista opažanja ponovite po ponovni povezavi, menjavi omrežja in pomembni posodobitvi aplikacije. Shranjena izključitev lahko še naprej kaže na pot ali identiteto aplikacije, ki ne obstaja več, in zasnova tiho preneha ustrezati svoji dokumentaciji. Ti trije dogodki so mesta, kjer razdeljeni tuneli driftajo, in vsakega je poceni znova preizkusiti. Preizkus, ki teče samo enkrat ob uvedbi, opisuje konfiguracijo, ki ne obstaja več.

Če se rezultat razlikuje, poiščite lastnika pravila in stopnjo obdelave, preden spremenite več nastavitev hkrati. Spremeniti pet stvari in opazovati en rezultat ni diagnoza, je nova konfiguracija.

Kaj naj rezultat potrdi

Povežite opažanja s politiko in različico odjemalca, ki ste ju dejansko preizkusili. Cilj je pokazati, da ta uvedba ustreza pokritosti, ki jo zatrjuje, ne da bo vsaka prihodnja aplikacija zasebna. To je ožja trditev in to je tista, ki jo res lahko podprete z dokazi. Zapišite trditev, različico in rezultate štirih polj v zapis sprememb.

Potem lahko naslednji pregledovalec ugotovi, ali se je spremenila zasnova ali preizkus. Razdeljeni tunel je preverjen, ko se obe strani, razdelitev razreševalnika in vedenje ob okvari ujemajo s tem, kar ste zapisali na začetku. En rezultat IP ne preveri nobenega od njih.