Az eth0 forgalma nem azt jelenti, hogy a VPN-alagút szivárog

Nyilvános címeket látni az eth0-n, miközben az alagút fut, olyan érzés, mintha valami megszökött volna. Általában az ellenkezője igaz: az alagút saját csomagjainak át kell haladniuk ezen az adapteren, hogy elérjék a szervert, és úgy néznek ki, mint a közönséges UDP- vagy TCP-folyamok. A belső csomag csak az alagút eszközén jelenik meg. A kettő megkülönböztetése a burkolat olvasásának kérdése, nem a bájtszámban való bizakodásé.

Minden alagútcsomag továbbra is átkel a vezetéken

Az alagút interfész, nem vezeték. A kliens fog egy belső csomagot, becsomagolja, és az eredményt a profilból vett szervercímre és portra küldi. A fizikai adapteren a burkolatot látja; az alagút eszközén azt látja, amit becsomagoltak.

UDP módban a külső folyam irányonként egyetlen cím- és portpár, ezért egy egészséges alagút szinte unalmasan néz ki az eth0-n. Elsőként éppen ezt az egyetlen párt kell keresni.

Egyszerre egy interfészt rögzítsen

Egyszerre csak egy interfészt rögzítsen, ha a számokat össze akarja hasonlítani. Az any álnévvel jelölt interfész egyszerre gyűjti az összes eszközt, ezért egy továbbított csomag a belépésnél és a kilépésnél is megjelenik, egy helyben létrehozott pedig kétszer, két különböző formában. Az egyenlő csomagszám eltérő bájtszámmal normális, mert a burkolat nagyobb annál, amit szállít. Az ARP, a DHCP és az IPv6-os útválasztó-hirdetések a helyi kapcsolathoz tartoznak, és semmit sem mondanak az alkalmazásáról.

sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194

Cserélje ki a címet és a portot a profil saját értékeire. Ha ez a folyam egyenletes, az alagút szállít valamit.

Kérdezze meg a kernelt, melyik eszközt választja

Kérdezze meg a kernelt, melyik eszközt választaná, majd erősítse meg a vezetéken. Az útvonalkeresés a döntés, a rögzítés pedig annak bizonyítéka, hogy a döntést követték. Különböző kérdésekre válaszolnak, és mindkettőre szüksége van.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

A megosztott eredmény a szokásos lelet: az IPv4 az alagútba megy, az IPv6 pedig a fizikai adapterre, mert a profil csak IPv4-útvonalakat tolt be. Ez valódi szivárgás, és egy csak IPv4-et tartalmazó rögzítésben láthatatlan. Szűrjön IPv6-ra, és figyelje azokat a címeket, amelyek nem a szerver és nem link-local címek.

Futtassa le mindkét keresést csatlakozás előtt és után, hogy lássa, mit változtatott valójában a kliens. A két futás közötti különbség a kliens valódi hatása.

Amikor a rögzítés valóban szivárgás

Néha a rögzítés igazat mond. Egy szűkebb útvonal, amely egy előtagot az alagút mellett küld, egy alhálózat, amelyet a kliensnek ki kellett zárnia, vagy egy tűzfal-szabály, amely az alagút házirendje előtt fut, mind nyíltan a vezetékre teheti a forgalmat. Egy folyamatcsoporthoz illeszkedő szabály is lehet szándékos kivétel. Olvassa el az interfészét és a cél tartományát, mielőtt hibának nevezné.

Az útvonalat vagy a kivételt javítsa, ne a tűzfalat. Utána rögzítsen újra egy friss kapcsolatból, és ellenőrizze külön az IPv4-et és az IPv6-ot, mert az egyik javítása semmit sem mond a másikról. A tcpdump kézikönyv ismerteti a fent használt interfész- és irányválasztókat.