Vad en iftop-skärm kan och inte kan bevisa om en VPN

En iftop-skärm besvarar en fråga i taget: vilka värdpar som utbyter byte genom det gränssnitt du riktade den mot. Den besvarar inte om varje program följer en VPN-princip, och en tom skärm bevisar inte att ingenting läckt. Just i skillnaden mellan dessa två påståenden går de flesta läcktestdiskussioner fel. Tre villkor avgör vad visningen egentligen betyder, och alla tre syns i kommandoraden du använde.

Tre villkor avgör vad skärmen betyder

Villkoren är vilket gränssnitt som visas, vad filtret och verktyget självt döljer, och vad testet faktiskt utövade. Svara i den ordningen, eftersom ett fel i det första gör de andra två meningslösa.

Gränssnittsvillkoret spelar roll eftersom en tunnelvy och en fysisk vy visar olika lager av samma trafik. Att titta på tunnelgränssnittet visar flödena inne i tunneln; att titta på det fysiska gränssnittet visar tunnelns bärare, plus all legitim konfigurations-, styr- eller lokaltrafik som delar den länken. Ingen av vyerna är fel, och ingen av dem är hela bilden. Att namnge vilken du tittar på är skillnaden mellan bevis och intryck.

Villkor ett: vilket gränssnitt som visas

iftop tar gränssnittet explicit med -i, och dess manual beskriver beteendet när du inte gör det: den väljer ett, som kan vara enheten som ser extern ut i stället för tunneln. Den standarden är ett rimligt val för ett bandbreddsverktyg och ett dåligt för ett läcktest.

Ange alltid gränssnittet och skriv ner det bredvid resultatet. En skärmbild utan gränssnittsnamnet går inte att återskapa.

Villkor två: vad filtret och verktyget döljer

iftop accepterar ett filteruttryck, och ett flöde som filtret utesluter är osynligt genom konstruktionen och inte genom frånvaro. Verktyget gör också som standard värdnamnsuppslag för att märka adresser, och dessa uppslag genererar sin egen DNS-trafik, alltså trafik du inte avsåg att observera. -n stänger av uppslagen och gör visningen numerisk; att dölja DNS-raderna efteråt är inte samma sak som att inte generera frågorna.

Den skillnaden är värd att säga rakt ut, eftersom den också förekommer i andra verktyg: att undertrycka visningen av en aktivitet är inte samma sak som att förhindra den. Om DNS-uppslagen är en del av det du testar, kör testet med uppslagen avstängda så att observationen inte förorenas av observatören.

Villkor tre: vad testet faktiskt utövade

En enda begäran från ett program, till en destination, i en adressfamilj bevisar något om den begäran. Den bevisar ingenting om ett annat program, en annan destination eller den andra adressfamiljen, och IPv6 är den familj som oftast glöms bort just i den här typen av kontroll.

Definiera därför begäran innan du börjar: en ofarlig destination, från programmet du bryr dig om, i familjen du bryr dig om, med tunneln i dess godkända tillstånd. Kontrollera sedan mottagarsidan eller klientens egna diagnostik, eftersom den bortre änden vet vad som anlände på ett sätt som den lokala skärmen inte kan. Utför sedan det godkända fallet med otillgänglig tunnel och se om trafiken stannar, eftersom det är det beteende kravet vanligtvis egentligen handlar om.

DNS förtjänar sin egen observation. Mottagaren av frågan och den väg frågan tog är två fakta, och en bandbreddsskärm visar ingen av dem.

Att använda iftop som stödjande bevis

Först då tillför iftop värde, och det gör det som bekräftelse. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" visar om det förväntade flödet dyker upp på det förväntade gränssnittet, med byträkningar som gör ett påstående om ledighet verifierbart.

Jämför det med ss -tnp för vyn på socketnivå och ip route get för den väg kärnan skulle välja, och du har tre observationer av en begäran i stället för ett intryck av en maskin. iftop-manualen dokumenterar gränssnittsvalet, filtersyntaxen och uppslagsbeteendet, vilket är de tre saker ett läcktest beror på. En bandbreddsskärm lokaliserar aktivitet; vägen, undantagen och felbeteendet avgör om den aktiviteten uppfyller kravet.