Verificați dacă un tunel divizat funcționează: un singur rezultat IP nu este un test

O singură pagină de browser care afișează o adresă IP nu dovedește aproape nimic despre un tunel divizat. O adresă vizibilă poate fi cea corectă din motivul greșit, iar un flux exclus nu este niciodată exercitat de ea. Notați rezultatul așteptat înainte de a testa: ce aplicație sau destinație ar trebui să folosească tunelul, care ar trebui să rămână directă și ce ar trebui să se oprească atunci când tunelul eșuează. Fără acel plan, orice cifră plauzibilă pare un succes.

Mitul: o interogare de adresă dovedește acoperirea

Verificarea IP răspunde la o singură întrebare: ce vede lumea exterioară dintr-o aplicație într-un anumit moment. Nu spune nimic despre un prefix intern, un al doilea profil de browser sau un nume care ar trebui rezolvat privat. Nu spune nimic nici despre eșec, iar aceasta este jumătatea unui proiect de tunel divizat care se rupe în producție.

O pagină de adresă nu poate arăta nici ruta, nici resolverul, nici politica de eșec. Tratați-o ca o singură observație, nu ca un verdict.

Testați un flux inclus și unul exclus

Trimiteți o cerere inofensivă din aplicația care ar trebui inclusă, sau către prefixul pe care vă așteptați să fie rutat prin tunel, și înregistrați sursa, destinația, familia de adrese și calea observată. Faceți același lucru pentru un flux care ar trebui să rămână direct. Partea exclusă este cea pe care oamenii o sar, și este singura dovadă că divizarea este deliberată și nu accidentală. Un proces auxiliar poate purta o identitate de politică separată, așa că testați în procesul care deține socketul.

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

De aceea un test rulat în aplicația greșită poate arăta opusul a ceea ce intenționează proiectul. Notați cele patru câmpuri pentru ambele părți înainte de a trage orice concluzie.

Adăugați DNS-ul și cazul de eșec

Interogați resolverul sistemului și resolverul pe care îl folosește aplicația, apoi comparați acele răspunsuri cu adresa de ieșire pe care o raportează site-ul. Cele două straturi pot fi în dezacord prin proiect, iar o singură interogare a browserului nu exercită politica sistemului de operare. Un shell face comparația repetabilă: Rupeți tunelul intenționat, apoi faceți o cerere pe care browserul nu a stocat-o în cache; o pagină servită din cache nu vă spune nimic despre direcția în care a mers rezerva. Înregistrați ce s-a întâmplat efectiv, nu ce a prezis proiectul.

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

Un tunel divizat care eșuează închis și unul care eșuează deschis arată identic până când rupeți tunelul intenționat. Înregistrați ce comportament ați observat, nu care era așteptat.

Repetați după schimbarea stării

Repetați aceleași observații după o reconectare, o schimbare de rețea și o actualizare relevantă a aplicației. O excludere stocată poate continua să arate spre o cale sau o identitate de aplicație care nu mai există, iar proiectul încetează încet să mai corespundă documentației sale. Acele trei evenimente sunt locurile în care tunelurile divizate derivă, iar fiecare este ieftin de retestat. Un test care rulează doar o dată la instalare descrie o configurație care nu mai există.

Dacă un rezultat diferă, găsiți proprietarul regulii și etapa de procesare înainte de a schimba mai multe setări deodată. A schimba cinci lucruri și a observa un singur rezultat nu este un diagnostic, ci o configurație nouă.

Ce trebuie să stabilească rezultatul

Legați observațiile de politica și versiunea de client pe care le-ați testat efectiv. Scopul este să arătați că această instalare corespunde acoperirii pe care o pretinde, nu că fiecare aplicație viitoare va fi privată. Aceasta este o afirmație mai îngustă și este cea pe care o puteți susține efectiv cu dovezi. Scrieți afirmația, versiunea și rezultatele cu patru câmpuri în registrul modificărilor.

Atunci următorul recenzent poate spune dacă s-a schimbat proiectul sau testul. Un tunel divizat este verificat atunci când ambele părți, separarea resolverului și comportamentul la eșec corespund cu ce ați notat la început. Un singur rezultat IP nu verifică niciunul dintre ele.