De ce un VPN poate părea conectat când nimic nu funcționează

Clientul tău raportează conectat în timp ce interfața este sus și browserul ajunge la timeout, și niciuna dintre aceste trei afirmații nu este falsă. Conectat descrie un strat care nu are nimic de-a face cu pagina pe care ai cerut-o. A decide care strat raportează necesită o cerere nouă și o privire la contorul care ar demonstra că traficul s-a mișcat. O repornire aruncă acea dovadă și reconstruiește condițiile pe care încercai să le observi.

Trei lucruri diferite numite conectat

La bază, conectat poate însemna că un proces client rulează și ține un socket către un partener. Deasupra, poate însemna că există o interfață cu o adresă, pe care un dispozitiv persistent sau o rutină de recuperare o pot crea fără o sesiune vie în spate. La nivel de control, poate însemna că s-a negociat o asociere, ceea ce nu spune nimic despre dacă un singur pachet a trecut pe sub ea. Fiecare dintre ele supraviețuiește unor defecțiuni la care celelalte nu supraviețuiesc, iar un client afișează de obicei cea mai puternică pe care o poate revendica.

O pictogramă verde și un tunel mort sunt, prin urmare, compatibile și nu contradictorii; ele raportează despre obiecte diferite. Acesta este tot motivul pentru care această defecțiune este diagnosticată greșit în mod repetat ca eroare a clientului.

Trimite o cerere inofensivă către o destinație de care ai într-adevăr nevoie înainte de a atinge daemonul, și păstrează blocul de trafic direct cerut la locul lui cât timp lucrezi. O repornire șterge ordinea evenimentelor și apoi le recreează suficient de aproape încât să ascundă cauza, motiv pentru care același tichet revine o săptămână mai târziu fără nimic nou în el. O cerere, o citire a contorului și declanșatorul care a produs defecțiunea sunt dovada minimă.

Care contor demonstrează că pachetele s-au mișcat

În IPsec, asocierea IKE și asocierea CHILD sunt obiecte separate, iar numai child poartă contoarele care răspund la această întrebare. Listează child, urmărește dacă pachetele cresc în ambele direcții și compară cu ceea ce încearcă aplicația să facă. O asociere instalată la zero este o constatare diferită de una care crește în timp ce aplicația încă eșuează; prima înseamnă că traficul nu este selectat, a doua că se mișcă și că defecțiunea este mai departe. Citește contoarele de două ori, la câteva secunde distanță, pentru că o singură probă nu poate arăta o tendință.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Contoarele zero indică selecția: rutarea, politica, un spațiu de nume din care a ieșit pachetul sau o interfață de care clientul nu s-a legat niciodată. Contoarele crescătoare indică departe de tunel, așa că continuă cu redirecționarea la capătul îndepărtat, rezolvarea numelor, calea de întoarcere și serviciul de destinație, în această ordine. Un protocol fără obiect child separat expune aceeași dovadă în termenii lui, așa că folosește ce raportează despre starea partenerului și numărul de pachete în loc să împrumuți vocabularul IPsec. Forma citirii contează mai mult decât instrumentul care a produs-o.

Unde se află defecțiunea după ce contoarele se mișcă

Un gateway care răspunde pe propriul adresă de administrare demonstrează că gateway-ul rulează, nu că ceva din spatele lui servește cererea ta, așa că testează partea îndepărtată și nu cutia din mijloc. Rezolvarea numelor ascunde cel mai bine defecțiunile, pentru că un resolver inaccesibil prin tunel expiră exact ca o conexiune moartă. Două interogări separă acele cazuri, și ambele sunt ieftine. Întreabă mai întâi resolverul pe care tunelul îl impune, apoi întreabă un resolver public despre același nume.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Un nume care se rezolvă prin resolverul public dar nu prin resolverul tunelului înseamnă că calea DNS este ruptă, în timp ce un nume care se rezolvă prin ambele și tot expiră în browser indică calea de întoarcere sau serviciul. Dacă ping-ul pe adresă reușește și aplicația tot refuză, rețeaua a livrat cererea și serviciul a respins-o, ceea ce este o etapă mult mai târzie.

Notează declanșatorul, apoi schimbă un singur lucru

Notează ce a precedat defecțiunea: o perioadă de inactivitate, o schimbare de rețea, o reînnoire de cheie, un laptop reluat sau un sistem restaurat. Acestea produc mecanisme diferite, iar de obicei numai sistemul restaurat se repară singur, ceea ce este exact cazul care nu te învață nimic. O repornire elimină ordinea evenimentelor și apoi recreează condiții suficient de apropiate pentru a ascunde cauza. Scrie declanșatorul cât timp este încă reproductibil.

Apoi fă o corecție susținută și repetă cererea originală împreună cu declanșatorul care a produs defecțiunea. Inactivitatea este declanșatorul cel mai ușor de reprodus, așa că este confirmarea cea mai rapidă că remedierea a vizat mecanismul și nu simptomul.

Ceea ce vrei să raportezi este dovada că traficul pe care intenționai să-l trimiți a ajuns la serviciul la care intenționai să ajungi. O pictogramă care devine verde, o pagină din cache care se încarcă și un contor care se mișcă dovedesc toate mai puțin decât o cerere finalizată către destinația dorită. Ține împreună cererea, citirea contorului și declanșatorul, ca următoarea persoană să poată distinge o corecție de o coincidență.