Kontroli, ĉu disigita tunelo funkcias: unu IP-rezulto ne estas testo

Unu sola retumila paĝo, kiu montras IP-adreson, pruvas preskaŭ nenion pri disigita tunelo. Videbla adreso povas esti la ĝusta pro la malĝusta kialo, kaj ekskludita fluo neniam estas ekzercita per ĝi. Skribu la atendatan rezulton antaŭ ol testi: kiu aplikaĵo aŭ celo uzu la tunelon, kiu restu rekta, kaj kio haltu kiam la tunelo fiaskas. Sen tiu plano, ĉiu kredinda nombro aspektas kiel sukceso.

La mito: adresa serĉo pruvas kovradon

La IP-kontrolo respondas unu demandon: kion la ekstera mondo vidas de unu aplikaĵo en unu momento. Ĝi diras nenion pri interna prefikso, dua retumila profilo aŭ nomo, kiu devus esti solvita private. Ĝi ankaŭ diras nenion pri fiasko, kaj tio estas la duono de disigita tunela dezajno, kiu rompiĝas en produktado.

Adresa paĝo ankaŭ ne povas montri la itineron, la solvilon aŭ la fiaskan politikon. Traktu ĝin kiel unu observon, ne kiel verdikton.

Ekzercu inkluzivitan fluon kaj ekskluditan

Sendu sendanĝeran peton el la aplikaĵo, kiu devus esti inkluzivita, aŭ al la prefikso, kiun vi atendas rutigi tra la tunelo, kaj registru la fonton, celon, adresan familion kaj observitan vojon. Faru la samon por fluo, kiu devus resti rekta. La ekskludita flanko estas tiu, kiun homoj preterlasas, kaj ĝi estas la sola pruvo, ke la disigo estas intenca kaj ne hazarda. Helpa procezo povas porti apartan politikan identecon, do testu en la procezo, kiu posedas la ingon.

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

Tial testo en la malĝusta aplikaĵo povas montri la malon de tio, kion la dezajno celas. Skribu la kvar kampojn por ambaŭ flankoj antaŭ ol fari iun ajn konkludon.

Aldonu DNS kaj la fiaskan kazon

Demandu la sistem-solvilon kaj la solvilon, kiun la aplikaĵo uzas, kaj poste komparu tiujn respondojn kun la elira adreso, kiun la retejo raportas. La du tavoloj povas malkonsenti laŭdezajne, kaj unu retumila serĉo ne ekzercas la operaciuman politikon. Ŝelo faras la komparon ripetebla: Rompu la tunelon intence, poste faru peton, kiun la retumilo ne kaŝmemorigis; paĝo servita el la kaŝmemoro diras al vi nenion pri tio, kien iris la rezerva vojo. Registru, kio efektive okazis, anstataŭ kion la dezajno antaŭdiris.

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

Disigita tunelo, kiu fiaskas fermite, kaj unu, kiu fiaskas malfermite, aspektas identaj ĝis vi intence rompos la tunelon. Registru, kiun konduton vi observis, ne kiun vi atendis.

Ripetu post kiam la stato ŝanĝiĝis

Ripetu la samajn observojn post rekonekto, retŝanĝo kaj grava aplikaĵa ĝisdatigo. Konservita ekskludo povas daŭre montri al vojo aŭ aplikaĵa identeco, kiu ne plu ekzistas, kaj la dezajno silente ĉesas kongrui kun sia dokumentaro. Tiuj tri eventoj estas la lokoj, kie disigitaj tuneloj drivas, kaj ĉiu el ili estas malmultekosta retesti. Testo, kiu ruliĝas nur unufoje ĉe la deplojo, priskribas agordon, kiu ne plu ekzistas.

Se rezulto malsamas, trovu la posedanton de la regulo kaj la prilaboran stadion antaŭ ol ŝanĝi plurajn agordojn samtempe. Ŝanĝi kvin aferojn kaj observi unu rezulton ne estas diagnozo, ĝi estas nova agordo.

Kion la rezulto devas konstati

Ligu la observojn al la politiko kaj klienta versio, kiujn vi efektive testis. La celo estas montri, ke ĉi tiu deplojo kongruas kun la kovrado, kiun ĝi pretendas, ne ke ĉiu estonta aplikaĵo estos privata. Tio estas pli mallarĝa aserto, kaj ĝi estas tiu, kiun vi efektive povas subteni per pruvoj. Skribu la aserton, la version kaj la kvar-kampajn rezultojn en la ŝanĝan registron.

Tiam la sekva revizianto povas vidi, ĉu la dezajno ŝanĝiĝis aŭ la testo. Disigita tunelo estas kontrolita, kiam ambaŭ flankoj, la solvila disigo kaj la fiaska konduto kongruas kun tio, kion vi skribis komence. Unu IP-rezulto kontrolas neniun el ili.