Mit bizonyíthat és mit nem egy iftop-képernyő egy VPN-ről

Egy iftop-képernyő egyszerre egy kérdésre válaszol: mely gép párok cserélnek bájtokat azon az interfészen, amelyre irányította. Arra nem válaszol, hogy minden alkalmazás követ-e VPN-szabályzatot, és egy üres képernyő nem bizonyítja, hogy semmi sem szivárgott. Éppen a két állítás közötti résben hibáznak a legtöbb szivárgásteszt-viták. Három feltétel dönti el, mit jelent valójában a megjelenítés, és mindhárom látható a használt parancssorban.

Három feltétel dönti el, mit jelent a képernyő

A feltételek: melyik interfész jelenik meg, mit rejtenek el a szűrő és maga az eszköz, és mit gyakoroltatott valójában a teszt. Ebben a sorrendben válaszoljon rájuk, mert az első hibája értelmetlenné teszi a másik kettőt.

Az interfészfeltétel azért számít, mert az alagútnézet és a fizikai nézet ugyanannak a forgalomnak különböző rétegeit mutatja. Az alagút interfészére nézve az alagúton belüli folyamok látszanak; a fizikai interfészre nézve az alagút hordozója látszik, valamint minden legitim beállítási, vezérlési vagy helyi forgalom, amely ezt a kapcsolatot megosztja. Egyik nézet sem hibás, és egyik sem a teljes kép. Megnevezni, melyiket nézi, a különbség a bizonyíték és a benyomás között.

Első feltétel: melyik interfész jelenik meg

Az iftop az interfészt kifejezetten -i segítségével veszi át, és a kézikönyve leírja a viselkedést, ha ezt nem teszi meg: kiválaszt egyet, amely a külsőnek látszó eszköz lehet az alagút helyett. Ez az alapértelmezés ésszerű egy sávszélesség-eszköznél és rossz egy szivárgástesztnél.

Mindig adja meg az interfészt, és jegyezze fel az eredmény mellé. Az interfész neve nélküli képernyőkép nem reprodukálható.

Második feltétel: mit rejtenek el a szűrő és az eszköz

Az iftop szűrőkifejezést fogad el, és az a folyam, amelyet a szűrő kizár, felépítésénél fogva láthatatlan, nem hiány miatt. Az eszköz alapértelmezés szerint gazdagépnév-kereséseket is végez a címek felcímkézéséhez, és ezek a keresések saját DNS-forgalmat generálnak, vagyis olyan forgalmat, amelyet nem kívánt megfigyelni. A -n kikapcsolja a kereséseket, és numerikussá teszi a megjelenítést; a DNS-sorok utólagos elrejtése nem ugyanaz, mint a lekérdezések meg nem termelése.

Ezt a különbséget érdemes egyenesen kimondani, mert más eszközökben is megjelenik: egy tevékenység megjelenítésének elnyomása nem ugyanaz, mint megakadályozása. Ha a DNS-keresések részei annak, amit tesztel, futtassa a tesztet kikapcsolt keresésekkel, hogy a megfigyelést ne szennyezze a megfigyelő.

Harmadik feltétel: mit gyakoroltatott valójában a teszt

Egyetlen kérés egyetlen alkalmazásból, egyetlen célhoz, egyetlen címcsaládban bizonyít valamit arról a kérésről. Semmit sem bizonyít egy másik alkalmazásról, egy másik célról vagy a másik címcsaládról, és az IPv6 az a család, amelyet éppen az ilyen ellenőrzésekben felejtenek el a leggyakrabban.

Ezért a kezdés előtt határozza meg a kérést: ártalmatlan cél, abból az alkalmazásból, amely fontos Önnek, abban a családban, amely fontos Önnek, az alagúttal a jóváhagyott állapotában. Ezután ellenőrizze a fogadó oldalt vagy az ügyfél saját diagnosztikáját, mert a távoli vég tudja, mi érkezett meg, olyan módon, ahogyan a helyi képernyő nem tudhatja. Ezután gyakorolja a jóváhagyott, elérhetetlen alagút esetét, és nézze meg, leáll-e a forgalom, mert a követelmény általában valójában erről a viselkedésről szól.

A DNS saját megfigyelést érdemel. A lekérdezés címzettje és a lekérdezés útvonala két tény, és egy sávszélesség-képernyő egyiket sem mutatja.

Az iftop használata támogató bizonyítékként

Csak ezután ad hozzá értéket az iftop, és megerősítésként adja hozzá. A sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" megmutatja, hogy a várt folyam megjelenik-e a várt interfészen, bájtszámokkal, amelyek ellenőrizhetővé teszik a tétlenségre vonatkozó állítást.

Hasonlítsa össze ezt a ss -tnp paranccsal a socket szintű nézethez és a ip route get paranccsal azzal az útvonallal, amelyet a kernel választana, és egy gép benyomása helyett egy kérés három megfigyelése áll rendelkezésére. Az iftop kézikönyve dokumentálja az interfész kiválasztását, a szűrő szintaxisát és a keresési viselkedést, és ez a három dolog az, amitől egy szivárgásteszt függ. Egy sávszélesség-képernyő lokalizálja a tevékenységet; az útvonal, a kivételek és a hiba viselkedése dönti el, hogy az a tevékenység megfelel-e a követelménynek.