Inspectarea unei interfețe VPN Linux cu ip link, strat cu strat

Pictograma clientului spune conectat, interfața există, iar aplicația tot nu ajunge nicăieri. Combinația este obișnuită, pentru că o interfață virtuală poate rămâne prezentă în timp ce perechea ei la distanță, adresele sau rutele lipsesc. ip link este primul instrument potrivit și totodată cel mai ușor de suprainterpretat. Steagurile și contoarele descriu un singur strat, iar straturile de deasupra lor eșuează independent. Este și instrumentul pe care oamenii îl citează când vor să demonstreze că tunelul este sus, exact afirmația pe care nu o poate susține singur.

Citiți interfața înainte de a citi pictograma

Începeți cu ip -details link show dev tun0, așa cum este documentat în manualul ip-link, înlocuind numele cu interfața pe care clientul o deține efectiv, nu cu numele convențional. Steagurile, tipul, MTU și identitatea interfeței sunt observații utile. Formularea stării unei interfețe virtuale nu trebuie să se comporte ca indicarea purtătoare a unui cablu fizic, așa că tratați UP ca o afirmație despre interfață, nu despre tunel.

Această distincție explică cel mai confuz caz: o interfață care persistă în timp ce partea la distanță se reconectează sau este de neatins.

Setările de persistență pot păstra legătura exact pentru ca reconectarea să nu o reconstruiască, ceea ce înseamnă că prezența nu este sănătate.

Adăugați contoare și o cerere care ar trebui să le folosească

Folosiți vizualizarea de statistici acceptată, ip -s link show dev tun0, și notați numărătorile de pachete și octeți în ambele direcții. Apoi generați o cerere inofensivă care ar trebui să traverseze interfața și comparați direcția relevantă. O cerere care a luat ruta directă a unei alte aplicații nu va mișca acele contoare, iar acesta este scopul exercițiului.

Dacă se mișcă contorul de transmisie și cel de recepție nu, pachetul a plecat și nimic nu s-a întors. Aceasta este o problemă diferită de o interfață care nu a transportat niciodată nimic. Dacă ambele contoare se mișcă și aplicația tot eșuează, defectul se află deasupra interfeței, ceea ce este un progres, nu un punct mort.

Luați citirea de două ori, o dată înainte și o dată după, în loc să vă încredeți într-o singură instantanee.

Adresele și rutele sunt pași separați

O legătură poate exista fără prefix, fără configurația de rezolvare sau fără ruta de care aplicația are nevoie. Verificați adresa cu ip address show dev tun0, apoi verificați ce rută ar selecta destinația cu ip route get pentru ținta reală. Cele trei observații răspund la trei întrebări diferite, iar doar ultima ține de forwarding.

Pentru IPsec, starea politicii de securitate și a asocierii poate conta de asemenea, și nu fiecare design IPsec apare ca o simplă interfață tun. Să cauți un dispozitiv tun care nu avea să existe niciodată este o cale rapidă de a trage concluzia greșită.

Notați numele exact, spațiul de nume și momentul cu orice ieșire pe care o păstrați, pentru că un nume identic ca aspect într-un alt container sau într-o sesiune restaurată reprezintă cu totul alt context.

Nu ștergeți ce nu ați identificat

O interfață necunoscută nu este automat învechită. Identificați proprietarul înainte de a elimina ceva și folosiți demontarea documentată a clientului sau configurația gestionată atunci când eliminarea este cu adevărat intenționată. Ștergerea unui tunel activ pentru a vedea ce se întâmplă este un test care răspunde la o întrebare pe care nimeni nu a pus-o.

Dacă interfața aparține unui runtime de containere sau unui spațiu de nume de rețea pe care nu l-ați creat, proprietarul este la o comandă distanță și merită găsit mai întâi.

Această precauție se aplică și la ip link set down, care pare reversibil și adesea nu este.

Ce ar trebui să vă rămână după inspecție

O inspecție bună se termină cu patru fapte: numele interfeței și spațiul de nume, steagurile și MTU, delta contoarelor dintr-o cerere reală și ruta și adresa de care aplicația are efectiv nevoie. Cu acestea notate, pasul următor este evident și aparține unui strat anume. Fără ele, fiecare schimbare ulterioară este o presupunere cu un plan de revenire.

Comparați cele patru fapte cu aceleași patru dintr-o sesiune funcțională. Dacă numele interfeței și spațiul de nume se potrivesc, dar delta contoarelor este zero, cererea nu a ajuns niciodată la tunel. Dacă delta contoarelor este sănătoasă și ruta indică altundeva, tunelul este în regulă, iar rutarea nu. Această comparație transformă un morman de ieșire într-o decizie.

Păstrați ieșirea împreună cu tichetul, pentru că o comparație ulterioară este utilă doar dacă puteți vedea ce s-a schimbat.

Apoi închideți bucla testând din nou aplicația, pentru că interfața nu a fost niciodată lucrul de care îi păsa utilizatorului.