Un serviciu privat se încarcă prin tunel și următorul expiră, iar tentația este să reconstruiești întregul profil al clientului. Serviciul care funcționează este mai util ca control decât ca motiv să o iei de la capăt. Demonstrează că o destinație, un port și o cale de autorizare au fost satisfăcute, și nimic mai mult.

Două servicii pe același gateway pot fi atinse prin familii de adrese diferite, subrețele diferite și politici diferite.

Separați fluxul care funcționează de cel care eșuează

Tratați fiecare serviciu ca pe propriul flux și nu ca pe un simptom al VPN-ului. Un client ilustrativ poate deschide portal.corp.example la 172.20.4.15:443 și totuși nu poate ajunge la o bază de date la 172.20.9.40:5432, pentru că sunt două destinații cu două seturi de reguli. Notați ambele rânduri înainte de a schimba ceva, inclusiv portul și protocolul, pentru că o regulă care permite TCP 443 pe un host nu spune nimic despre TCP 5432 pe același host.

Rândul care eșuează este cel care trebuie investigat. Rândul care funcționează spune doar unde se află linia de bază și va fi punctul de comparație după fiecare modificare.

Comparați adresele înainte de a compara numele

Rezolvați fiecare nume complet prin politica pe care aplicația o folosește efectiv, apoi înregistrați familia de adrese aleasă. Un nume poate returna o adresă IPv6 în timp ce altul returnează IPv4, iar un răspuns vechi din cache poate trimite o cerere către o adresă publică ce nu are nimic de-a face cu serviciul privat.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

Interogarea răspunde la o întrebare îngustă: ce rută ar alege acest host pentru acea destinație, având în vedere tabelele și regulile de politică actuale. O rută pentru 172.20.4.0/24 nu acoperă 172.20.9.0/24, iar un al doilea manager de rețea sau o rută locală cu specificitate mai bună poate suprascrie tunelul în liniște. Repetați interogarea în interiorul spațiului de nume sau cu marcajul pe care aplicația îl folosește atunci când acestea diferă de shell-ul dumneavoastră. Înregistrați și interfața pe care pachetul iese, pentru că tabelul de rute poate numi o interfață în timp ce rutarea bazată pe politică trimite fluxul prin alta.

O rută care se potrivește este o condiție necesară, nu o permisiune. Spune că pachetul are unde să meargă și nimic despre dacă un firewall, un serviciu de autorizare sau hostul însuși îl va accepta.

Protocolul și etapa de răspuns arată unde se oprește

Un răspuns la ping nu dovedește că un port de bază de date este deschis, iar o pagină HTTPS reușită nu autorizează partajarea de fișiere pe aceeași mașină. Înregistrați ce a revenit efectiv în loc să aplatizați fiecare eșec într-o singură categorie. Un timeout, un reset, o eroare de identitate TLS și o respingere la nivel de aplicație indică fiecare un alt strat.

Distincția contează pentru că corecțiile diverg. Liniștea înseamnă de obicei o problemă de rută, de firewall sau de traducere pe cale. Un reset imediat sugerează că ceva a ajuns la host și a refuzat portul. O eroare de certificat înseamnă că conexiunea a ajuns și numele nu se potrivea, ceea ce este o problemă de configurare, nu de accesibilitate. O respingere a aplicației înseamnă că rețeaua și-a făcut treaba, iar identitatea a fost respinsă după aceea.

Când o resursă este publicată printr-un gateway, comparați adresa sursă pe care o vede destinația cu sursa pe care clientul dumneavoastră crede că o folosește. O cerere originată de gateway însuși poate reuși în timp ce aceeași cerere de la un client eșuează, pentru că cele două vin din adrese diferite și întâlnesc reguli diferite.

Schimbați o variabilă și rulați din nou ambele cereri

Identitatea este ultimul loc în care oamenii se uită și primul în care apare o respingere corectă. Autentificarea VPN, grupul din director și contul aplicației sunt trei identități separate care pot diverge. Accesul la un portal nu implică niciodată accesul la baza de date din spate, iar un nume într-un director nu creează un rând în altul. Dacă serviciul se află în afara scopului prevăzut al utilizatorului, respingerea este sistemul care funcționează.

Rugați proprietarul resursei să confirme dreptul prevăzut în loc să adăugați o rută largă sau să deschideți un grup ca test. Lărgirea rețelei pentru a demonstra un punct este modul în care un diagnostic temporar devine o expunere permanentă și distruge controlul cu care ați început. O singură nepotrivire demonstrată pe iterație este suficientă: o rută lipsă, o familie de adrese greșită, un port blocat sau o apartenență la grup lipsă.

După fiecare modificare, repetați ambele cereri și țineți rezultatele alături. Investigația se termină când serviciul care eșua funcționează conform propriei politici, în timp ce serviciul care funcționează și respingerile pe care încă le așteptați se comportă exact ca înainte.

Articole similare