Verkeer op eth0 beteken nie die VPN-tonnel lek nie
Publieke adresse op die fisiese adapter is gewoonlik die tonnel se eie omhulsel. Vergelyk koppelvlakke en vra dan die kernel watter toestel hy kies.
Om publieke adresse op eth0 te sien terwyl die tonnel op is, voel soos bewys dat iets ontsnap het. Gewoonlik is dit die teenoorgestelde: die tonnel se eie pakkette moet daardie adapter oorsteek om die bediener te bereik, en hulle lyk soos gewone UDP- of TCP-strome. Die binneste pakket verskyn net op die tonneltoestel. Om die twee te onderskei is 'n kwessie van die omhulsel lees, nie van 'n greptelling vertrou nie.
Elke tonnelpakket steek steeds die draad oor
'n Tonnel is 'n koppelvlak, nie 'n draad nie. Die kliënt neem 'n binneste pakket, draai dit toe en stuur die resultaat na die bediener se adres en poort uit die profiel. Op die fisiese adapter sien jy die omhulsel; op die tonneltoestel sien jy wat toegedraai is.
In UDP-modus is die buitenste stroom een adres-en-poortpaar in elke rigting, en daarom lyk 'n gesonde tonnel amper vervelig op eth0. Daardie enkele paar is die eerste ding om na te kyk.
Vang een koppelvlak op 'n slag
Vang een koppelvlak op 'n slag wanneer jy tellings wil vergelyk. Die any-skynkoppelvlak versamel elke toestel gelyktydig, so 'n aangestuurde pakket verskyn by die in- en uitgang en een wat plaaslik geskep is, verskyn twee keer in twee verskillende vorme. Gelyke pakkettellings met ongelyke greptellings is normaal, want die omhulsel is groter as wat dit dra. ARP, DHCP en IPv6-routeraankondigings hoort op die plaaslike skakel en sê niks oor jou toepassing nie.
sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194Vervang die adres en poort met die profiel se eie waardes. As daardie stroom bestendig is, dra die tonnel iets.
Vra die kernel watter toestel hy kies
Vra die kernel watter toestel hy sou kies en bevestig dan op die draad. Die roetesoektog is die besluit, en die opname is die bewys dat die besluit gevolg is. Hulle beantwoord verskillende vrae en jy wil albei hê.
ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111'n Gesplete resultaat is die algemene bevinding: IPv4 gaan na die tonnel en IPv6 gaan na die fisiese adapter omdat die profiel net IPv4-roetes gestuur het. Dit is 'n werklike lek, en dit is onsigbaar in 'n opname wat net IPv4 dek. Filter vir IPv6 en let op adresse wat nie die bediener is nie en nie skakel-lokaal nie.
Voer albei soektogte voor en ná die verbinding uit, sodat jy kan sien wat die kliënt werklik verander het. Die verskil tussen die twee lopies is die kliënt se werklike effek.
Wanneer die opname werklik 'n lek is
Soms vertel die opname die waarheid. 'n Nouer roete wat een voorvoegsel om die tonnel stuur, 'n subnet wat die kliënt aangesê is om uit te sluit, of 'n firewall-toelating wat voor die tonnelbeleid loop, kan alles verkeer onverskuil op die draad plaas. 'n Reël wat 'n prosesgroep pas, kan ook 'n doelbewuste uitsondering wees. Lees sy koppelvlak en bestemmingsbestek voordat jy dit 'n fout noem.
Maak die roete of die uitsluiting reg, nie die firewall nie. Vang dan weer op vanaf 'n nuwe verbinding en kyk IPv4 en IPv6 afsonderlik na, want om die een reg te maak sê niks oor die ander nie. Die tcpdump-handleiding dek die koppelvlak- en rigtingkeurders wat hierbo gebruik is.