Kva ein iftop-skjerm kan og ikkje kan prova om ein VPN

Ein iftop-skjerm svarar på eitt spørsmål om gongen: kva vertspar som byter byte gjennom grensesnittet du peika han mot. Han svarar ikkje på om kvar applikasjon følgjer ein VPN-policy, og ein tom skjerm provar ikkje at ingenting lekte. Nettopp i skilnaden mellom desse to utsegnene går dei fleste lekkasjetest-diskusjonar gale. Tre vilkår avgjer kva visinga eigentleg tyder, og alle tre er synlege i kommandolinja du brukte.

Tre vilkår avgjer kva skjermen tyder

Vilkåra er kva grensesnitt som vert vist, kva filteret og verktøyet sjølv løyner, og kva testen faktisk utførte. Svar på dei i den rekkjefølgja, fordi ein feil i den første gjer dei to andre meiningslause.

Grensesnittvilkåret er viktig fordi ein tunnelvising og ei fysisk vising viser ulike lag av den same trafikken. Å sjå på tunnelgrensesnittet viser straumane inne i tunnelen; å sjå på det fysiske grensesnittet viser beraren av tunnelen, pluss all legitim oppsett-, kontroll- eller lokaltrafikk som deler den sambindinga. Inga av visingane er feil, og inga av dei er heile biletet. Å namngje kva du ser på er skilnaden mellom prov og inntrykk.

Vilkår éin: kva grensesnitt som vert vist

iftop tek grensesnittet eksplisitt med -i, og handboka skildrar åtferda når du ikkje gjer det: ho vel eitt, som kan vera eininga som ser ekstern ut i staden for tunnelen. Den standarden er eit rimeleg val for eit bandbreiddeverktøy og eit dårleg for ein lekkasjetest.

Oppgje alltid grensesnittet, og skriv det ned ved sida av resultatet. Eit skjermbilde utan grensesnittnamnet kan ikkje gjerast om att.

Vilkår to: kva filteret og verktøyet løyner

iftop godtek eit filteruttrykk, og ein straum som filteret utelèt er usynleg av konstruksjon og ikkje av fråvær. Verktøyet gjer også som standard vertsnamnoppslag for å merka adresser, og desse oppslaga genererer sin eigen DNS-trafikk, altså trafikk du ikkje hadde til hensikt å observera. -n slår av oppslaga og gjer visinga numerisk; å løyna DNS-radene etterpå er ikkje det same som å ikkje generera spørjingane.

Den skilnaden er verd å seia rett ut, fordi han også dukkar opp i andre verktøy: å undertrykkja visinga av ein aktivitet er ikkje det same som å hindra han. Viss DNS-oppslaga er ein del av det du testar, køyr testen med oppslag slått av, så observasjonen ikkje vert forureina av observatøren.

Vilkår tre: kva testen faktisk utførte

Éin einaste førespurnad frå éin applikasjon, til éin destinasjon, i éin adressefamilie provar noko om den førespurnaden. Han provar ingenting om ein annan applikasjon, ein annan destinasjon eller den andre adressefamilien, og IPv6 er familien som oftast vert gløymd nettopp i denne typen kontroll.

Definer derfor førespurnaden før du byrjar: ein ufarleg destinasjon, frå applikasjonen du bryr deg om, i familien du bryr deg om, med tunnelen i sin godkjende tilstand. Kontroller deretter mottakarsida eller klienten sine eigne diagnosar, fordi den fjerne enden veit kva som kom på ein måte den lokale skjermen ikkje kan. Utfør deretter det godkjende tilfellet med utilgjengeleg tunnel og sjå om trafikken stoppar, fordi det er åtferda kravet vanlegvis eigentleg handlar om.

DNS fortener si eiga observing. Mottakaren av spørjinga og ruta spørjinga tok er to fakta, og ein bandbreiddeskjerm viser ingen av dei.

Å bruka iftop som støttande prov

Først då tilfører iftop verdi, og det gjer det som stadfesting. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" viser om den forventa straumen dukkar opp på det forventa grensesnittet, med bytteteljingar som gjer ein påstand om lediggang etterprøvbar.

Samanlikn det med ss -tnp for visinga på socket-nivå og ip route get for ruta kjernen ville valt, og du har tre observasjonar av éin førespurnad i staden for eitt inntrykk av ein maskin. iftop-handboka dokumenterer grensesnittvalet, filtersyntaksen og oppslagsåtferda, som er dei tre tinga ein lekkasjetest er avhengig av. Ein bandbreiddeskjerm lokaliserer aktivitet; ruta, unntaka og feilåtferda avgjer om den aktiviteten oppfyller kravet.