Hva en iftop-skjerm kan og ikke kan bevise om en VPN

En iftop-skjerm besvarer ett spørsmål om gangen: hvilke vertspar som utveksler byte gjennom grensesnittet du pekte den mot. Den besvarer ikke om hver applikasjon følger en VPN-policy, og en tom skjerm beviser ikke at ingenting lekket. Nettopp i forskjellen mellom disse to utsagnene går de fleste lekkasjetest-diskusjoner galt. Tre betingelser avgjør hva visningen egentlig betyr, og alle tre er synlige i kommandolinjen du brukte.

Tre betingelser avgjør hva skjermen betyr

Betingelsene er hvilket grensesnitt som vises, hva filteret og verktøyet selv skjuler, og hva testen faktisk utførte. Svar på dem i den rekkefølgen, fordi en feil i den første gjør de to andre meningsløse.

Grensesnittbetingelsen er viktig fordi en tunnelvisning og en fysisk visning viser ulike lag av den samme trafikken. Å se på tunnelgrensesnittet viser strømmene inne i tunnelen; å se på det fysiske grensesnittet viser tunnelens bærer, pluss all legitim oppsett-, kontroll- eller lokaltrafikk som deler den forbindelsen. Ingen av visningene er feil, og ingen av dem er hele bildet. Å navngi hvilken du ser på er forskjellen mellom bevis og inntrykk.

Betingelse én: hvilket grensesnitt som vises

iftop tar grensesnittet eksplisitt med -i, og håndboken beskriver oppførselen når du ikke gjør det: den velger ett, som kan være enheten som ser ekstern ut i stedet for tunnelen. Den standarden er et rimelig valg for et båndbreddeverktøy og et dårlig for en lekkasjetest.

Oppgi alltid grensesnittet, og skriv det ned ved siden av resultatet. Et skjermbilde uten grensesnittnavnet kan ikke gjenskapes.

Betingelse to: hva filteret og verktøyet skjuler

iftop godtar et filteruttrykk, og en strøm som filteret utelukker er usynlig av konstruksjon og ikke av fravær. Verktøyet gjør også som standard vertsnavnoppslag for å merke adresser, og disse oppslagene genererer sin egen DNS-trafikk, altså trafikk du ikke hadde til hensikt å observere. -n slår av oppslagene og gjør visningen numerisk; å skjule DNS-radene etterpå er ikke det samme som å ikke generere spørringene.

Den forskjellen er verdt å si rett ut, fordi den også dukker opp i andre verktøy: å undertrykke visningen av en aktivitet er ikke det samme som å forhindre den. Hvis DNS-oppslagene er en del av det du tester, kjør testen med oppslag slått av, så observasjonen ikke forurenses av observatøren.

Betingelse tre: hva testen faktisk utførte

Én enkelt forespørsel fra én applikasjon, til én destinasjon, i én adressefamilie beviser noe om den forespørselen. Den beviser ingenting om en annen applikasjon, en annen destinasjon eller den andre adressefamilien, og IPv6 er familien som oftest glemmes nettopp i denne typen kontroll.

Definer derfor forespørselen før du begynner: en ufarlig destinasjon, fra applikasjonen du bryr deg om, i familien du bryr deg om, med tunnelen i sin godkjente tilstand. Kontroller deretter mottakersiden eller klientens egne diagnoser, fordi den fjerne enden vet hva som ankom på en måte den lokale skjermen ikke kan. Utfør deretter det godkjente tilfellet med utilgjengelig tunnel og se om trafikken stopper, fordi det er oppførselen kravet vanligvis egentlig handler om.

DNS fortjener sin egen observasjon. Mottakeren av spørringen og ruten spørringen tok er to fakta, og en båndbreddeskjerm viser ingen av dem.

Å bruke iftop som støttende bevis

Først da tilfører iftop verdi, og det gjør det som bekreftelse. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" viser om den forventede strømmen dukker opp på det forventede grensesnittet, med byttetellinger som gjør en påstand om lediggang etterprøvbar.

Sammenlign det med ss -tnp for visningen på socket-nivå og ip route get for ruten kjernen ville valgt, og du har tre observasjoner av én forespørsel i stedet for ett inntrykk av en maskin. iftop-håndboken dokumenterer grensesnittvalget, filtersyntaksen og oppslagsadferden, som er de tre tingene en lekkasjetest avhenger av. En båndbreddeskjerm lokaliserer aktivitet; ruten, unntakene og feiladferden avgjør om den aktiviteten oppfyller kravet.