Què pot demostrar i què no pot demostrar una pantalla d’iftop sobre una VPN

Una pantalla d’iftop respon una pregunta cada vegada: quins parells d’amfitrions intercanvien bytes per la interfície on l’heu apuntat. No respon si cada aplicació segueix una política de VPN, i una pantalla buida no demostra que no s’hagi filtrat res. És just en la diferència entre aquestes dues afirmacions on fallen la majoria dels arguments sobre proves de fuites. Tres condicions decideixen què significa realment la pantalla, i les tres són visibles a la línia d’ordres que heu fet servir.

Tres condicions decideixen què significa la pantalla

Les condicions són quina interfície es mostra, què amaguen el filtre i l’eina mateixa, i què ha exercitat realment la prova. Responeu-les en aquest ordre, perquè un error en la primera fa inútils les altres dues.

La condició de la interfície importa perquè la vista del túnel i la vista física mostren capes diferents del mateix trànsit. Mirar la interfície del túnel mostra els fluxos dins del túnel; mirar la interfície física mostra el portador del túnel, més qualsevol trànsit legítim de configuració, control o local que comparteixi aquest enllaç. Cap de les dues vistes no és incorrecta, i cap no és la imatge completa. Anomenar quina mireu és la diferència entre una prova i una impressió.

Condició primera: quina interfície es mostra

iftop pren la interfície explícitament amb -i, i el seu manual descriu el comportament quan no ho feu: n’escull una, que pot ser el dispositiu que sembla extern en lloc del túnel. Aquest valor per defecte és una opció raonable per a una eina d’amplada de banda i dolenta per a una prova de fuites.

Passeu sempre la interfície i anoteu-la al costat del resultat. Una captura de pantalla sense el nom de la interfície no és reproduïble.

Condició segona: què amaguen el filtre i l’eina

iftop accepta una expressió de filtre, i un flux que el filtre exclou és invisible per construcció, no per absència. L’eina també fa cerques de noms d’amfitrió per defecte per etiquetar adreces, i aquestes cerques generen el seu propi trànsit DNS, és a dir, trànsit que no preteníeu observar. -n desactiva les cerques i fa numèrica la pantalla; amagar després les files de DNS no és el mateix que no generar les consultes.

Val la pena dir aquesta distinció ben clarament, perquè també apareix en altres eines: suprimir la visualització d’una activitat no és el mateix que evitar-la. Si les cerques de DNS formen part del que proveu, feu la prova amb les cerques desactivades perquè l’observació no quedi contaminada per l’observador.

Condició tercera: què ha exercitat realment la prova

Una sola petició d’una aplicació, a una destinació, en una família d’adreces, demostra alguna cosa sobre aquesta petició. No demostra res sobre una altra aplicació, una altra destinació o l’altra família d’adreces, i IPv6 és la família que més sovint s’oblida justament en aquesta mena de comprovació.

Per tant, definiu la petició abans de començar: una destinació innòcua, des de l’aplicació que us importa, en la família que us importa, amb el túnel en el seu estat aprovat. Després comproveu el costat receptor o els propis diagnòstics del client, perquè l’extrem llunyà sap què ha arribat d’una manera que la pantalla local no pot. Després exerciteu el cas aprovat de túnel no disponible i mireu si el trànsit s’atura, perquè aquest és el comportament al qual normalment es refereix el requisit.

El DNS mereix la seva pròpia observació. El destinatari de la consulta i la ruta que ha pres la consulta són dos fets, i una pantalla d’amplada de banda no mostra cap dels dos.

Fer servir iftop com a prova de suport

Només llavors iftop aporta valor, i l’aporta com a corroboració. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" mostra si el flux que esperàveu apareix a la interfície que esperàveu, amb recomptes de bytes que fan verificable una afirmació d’inactivitat.

Compareu-ho amb ss -tnp per a la vista a nivell de sòcol i ip route get per a la ruta que triaria el nucli, i teniu tres observacions d’una petició en lloc d’una impressió d’una màquina. El manual d’iftop documenta la selecció d’interfície, la sintaxi del filtre i el comportament de les cerques, que són les tres coses de què depèn una prova de fuites. Una pantalla d’amplada de banda localitza l’activitat; la ruta, les excepcions i el comportament davant d’un error decideixen si aquesta activitat compleix el requisit.