Verkeer op eth0 betekent niet dat de VPN-tunnel lekt

Openbare adressen op eth0 zien terwijl de tunnel actief is, voelt als bewijs dat er iets ontsnapt is. Meestal is het omgekeerd: de eigen pakketten van de tunnel moeten die adapter passeren om de server te bereiken, en ze zien eruit als gewone UDP- of TCP-stromen. Het binnenste pakket verschijnt alleen op het tunnelapparaat. De twee onderscheiden is een kwestie van de envelop lezen, niet van een bytetelling vertrouwen.

Elk tunnelpakket steekt nog steeds de draad over

Een tunnel is een interface, geen draad. De client neemt een binnenste pakket, wikkelt het in en stuurt het resultaat naar het adres en de poort van de server uit het profiel. Op de fysieke adapter ziet u de wikkel; op het tunnelapparaat ziet u wat er ingewikkeld is.

In UDP-modus is de buitenste stroom één adres- en poortpaar per richting, waardoor een gezonde tunnel op eth0 bijna saai lijkt. Juist dat ene paar is het eerste waarnaar u moet zoeken.

Leg één interface tegelijk vast

Leg één interface tegelijk vast als u aantallen wilt vergelijken. De pseudo-interface any verzamelt elk apparaat in één keer, dus een doorgestuurd pakket verschijnt bij binnenkomst en vertrek en een lokaal gegenereerd pakket verschijnt twee keer in twee verschillende vormen. Gelijke pakketaantallen met ongelijke byteaantallen zijn normaal, omdat de wikkel groter is dan wat hij draagt. ARP, DHCP en IPv6-routeraankondigingen horen bij de lokale verbinding en zeggen niets over uw toepassing.

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

Vervang het adres en de poort door de waarden van het profiel zelf. Als die stroom gelijkmatig is, draagt de tunnel iets.

Vraag de kernel welk apparaat hij kiest

Vraag de kernel welk apparaat hij zou kiezen en bevestig het daarna op de draad. De routeopzoeking is de beslissing, en de opname is het bewijs dat de beslissing is gevolgd. Ze beantwoorden verschillende vragen en u wilt beide.

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

Een verdeeld resultaat is de gebruikelijke vondst: IPv4 gaat naar de tunnel en IPv6 gaat naar de fysieke adapter omdat het profiel alleen IPv4-routes heeft doorgeduwd. Dat is een echt lek, en het is onzichtbaar in een opname met alleen IPv4. Filter op IPv6 en let op adressen die niet de server zijn en niet link-local.

Voer beide opzoekingen voor en na het verbinden uit, zodat u ziet wat de client werkelijk heeft veranderd. Het verschil tussen de twee runs is het echte effect van de client.

Wanneer de opname echt een lek is

Soms vertelt de opname de waarheid. Een nauwere route die één prefix om de tunnel heen stuurt, een subnet dat de client moest uitsluiten, of een firewall-toestemming die vóór het tunnelbeleid loopt, kunnen allemaal verkeer in het openbaar op de draad zetten. Een regel die bij een procesgroep past, kan ook een bewuste uitzondering zijn. Lees de interface en het bestemmingsbereik voordat u het een fout noemt.

Repareer de route of de uitzondering, niet de firewall. Leg daarna opnieuw vast vanaf een nieuwe verbinding en controleer IPv4 en IPv6 apart, want het ene repareren zegt niets over het andere. De tcpdump-handleiding behandelt de interface- en richtingsselectors die hierboven zijn gebruikt.