Ferkeer op eth0 betsjut net dat de VPN-tunnel lekket
Iepenbiere adressen op de fysike adapter binne meastentiids de eigen omhulling fan de tunnel. Fergelykje ynterfaces en freegje dan de kernel hokker apparaat er kiest.
Iepenbiere adressen op eth0 sjen wylst de tunnel oan stiet fielt as bewiis dat der wat ûntkommen is. Meastentiids is it oarsom: de eigen pakketten fan de tunnel moatte dy adapter oerstekke om de server te berikken, en se lykje op gewoane UDP- of TCP-streamen. It binnenste pakket ferskynt allinnich op it tunnelapparaat. It ferskil tusken dy twa is in kwestje fan de omhulling lêze, net fan in bytetelling fertrouwe.
Elk tunnelpakket stekt noch altyd de tried oer
In tunnel is in ynterface, gjin tried. De klient nimt in binnenst pakket, wikkelt it yn en stjoert it resultaat nei it adres en de poarte fan de server út it profyl. Op de fysike adapter sjogge jo de omhulling; op it tunnelapparaat sjogge jo wat ynwikele is.
Yn UDP-modus is de bûtenste stream ien adres- en poartpear yn elke rjochting, dêrom liket in sûne tunnel hast ferfelend op eth0. Krekt dat iene pear is it earste om nei te sykjen.
Fange ien ynterface tagelyk
Fange ien ynterface tagelyk as jo tellingen fergelykje wolle. De skyn-ynterface any sammelt elk apparaat tagelyk, dêrom ferskynt in trochstjoerd pakket by de yn- en útgong en in pleatslik makke pakket twa kear yn twa ferskillende foarmen. Lykweardige pakkettingen mei ûngelikense bytetingen binne normaal, om't de omhulling grutter is as wat er draacht. ARP, DHCP en IPv6-routeroanbefellingen hearre by de pleatslike keppeling en sizze neat oer jo applikaasje.
sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194Ferfange it adres en de poarte troch de eigen wearden fan it profyl. As dy stream gelykmatich is, draacht de tunnel wat.
Freegje de kernel hokker apparaat er kiest
Freegje de kernel hokker apparaat er kieze soe, en befêstigje it dan op de tried. De rûtesyk is it beslút, en de opname is it bewiis dat it beslút folge is. Se beantwurdzje ferskillende fragen en jo wolle beide.
ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111In splitsk resultaat is de gewoane fynst: IPv4 giet nei de tunnel en IPv6 giet nei de fysike adapter, om't it profyl allinnich IPv4-rûtes skood hat. Dat is in echte lek, en it is ûnsichtber yn in opname fan allinnich IPv4. Filterje op IPv6 en let op adressen dy't net de server binne en net link-local binne.
Rin beide sykjen foar en nei it ferbinen, sadat jo sjen kinne wat de klient echt feroare hat. It ferskil tusken de beide rinnen is it echte effekt fan de klient.
As de opname echt in lek is
Soms fertelt de opname de wierheid. In smeller rûte dy't ien foarheaksel om de tunnel stjoert, in subnet dat de klient sei om út te sluten, of in firewall-tastimming dy't foar it tunnelbelied rint, kinne allegear ferkear iepen op 'e tried sette. In regel dy't by in prosesgroep past, kin ek in bewuste útsûndering wêze. Lês syn ynterface en bestimmingsberik foardat jo it in flater neame.
Meitsje de rûte of de útsûndering goed, net de firewall. Fange dan wer op fan in nije ferbining en kontrolearje IPv4 en IPv6 apart, want ien reparearje seit neat oer de oare. It tcpdump-hânboek beskriuwt de ynterface- en rjochtingsselektors dy't hjirboppe brûkt binne.