Trafik gerçekten VPN'den mi geçiyor? Nasıl doğrulanır

İki arıza sistem tepsisi simgesinden aynı görünür: tünele giren trafik ve onu sessizce atlayan trafik. İstemci her iki durumda da Connected gösterir, çünkü Connected yalnızca tünel arabiriminin var olduğunu ve istemcinin istediği rotaları kurduğunu belirtir. Bir uygulamanın bir paketinin bu rotaları kullanıp kullanmadığı ayrı bir sorudur ve yığının başka bir yerinde yanıtlanır. Dört ölçüm bunun çoğunu çözer — rota sorgusu, ilk atlama, fiziksel bağdaştırıcıda bir yakalama ve dışarıdan bir gözlem — ve sunucunun kendi oturum görünümü geri kalanı kapsar.

Paketin izleyeceği rotayla başlayın

Yönlendirme tablosu kararın kendisidir, bu yüzden hepsini okuyup tahmin etmek yerine ona tek bir hedef sorun. Linux'ta ip route get çekirdeğin seçtiği arabirimi ve kaynak adresi adlandırır:

ip route get 203.0.113.10
ip route get 10.20.5.7

Windows'ta Find-NetRoute -RemoteIPAddress 203.0.113.10 aynı nedenle route print -4'ten daha kullanışlıdır: kazanan rotayı bildirir, var olan tüm rotaları değil. Yine de tabloyu 0.0.0.0 satırı için bir kez okuyun. Oradaki bir /1 çifti, tam tünel istemcisinin varsayılan rotayı yeniden yazdığı anlamına gelir: OpenVPN'in redirect-gateway def1 seçeneği 0.0.0.0/1 ve 128.0.0.0/1'i tünel üzerinden kurar; bu, fiziksel varsayılanı silmeden en uzun önek eşleşmesinde var olan 0.0.0.0/0'u yener. Bu yüzden iki varsayılan rota bir arada bulunabilirken her şey yine de tünele girer.

İki ayrıntı tabloyu yalancı yapar. Birincisi, varsayılan rota sayısına değil eşleşen öneke bakın, çünkü kazananı arabirim metriği veya bir /1 çifti belirler. İkincisi, zaten var olan bir bağlantı kurulduğu yolu korur; tünel kalktıktan sonra açık bir oturum sıfırlanana kadar eski rotayı kullanmaya devam edebilir, bu yüzden yeniden bağlanmak yönlendirme sorununu düzeltiyormuş gibi görünür. Çalışan bir istemci — ps ax | grep openvpn — yalnızca sürecin başladığını kanıtlar.

Bir iç ve bir genel adı izleyin

Rota sorgusu niyeti gösterir; yol teslimi gösterir. Bağlıyken iç olması gereken bir adı ve olmaması gereken bir adı izleyin, ilk atlamayı karşılaştırın:

traceroute intranet.corp.example
traceroute 1.1.1.1

Her ikisi için aynı ilk atlama, iç adın tünele hiç girmediğini ve arızanın onun üstünde olduğunu gösterir, genellikle genel bir adrese çözülen bir ad veya hiç kurulmamış bir rota. İç trafik 10.8.0.1 üzerinden çıkarken genel trafik 192.168.1.1 üzerinden çıkıyorsa, bölünmüş tünel tam olarak yapılandırıldığı işi yapıyor. VPN geçidine ulaşıp sonra yalnızca zaman aşımı döndüren bir iz genellikle dönüş yolu veya sunucu güvenlik duvarı sorunudur, eksik bir iletme rotası değil.

Süzülmüş ICMP bu kontrolü yalancı yapar: iki izde de yıldızlar ölü bir tünel gibi görünür ve genellikle güvenlik duvarıdır. Yapabildiğiniz yerde bir TCP bağlantı noktası deneyin — Linux'ta traceroute -T -p 443 — ve izin hangi çözümleyicinin yanıtladığını söylemediğini unutmayın: bir ad yerelde çözülüp yine de tünelden erişilebilir olabilir.

Tünelde değil, fiziksel bağdaştırıcıda yakalayın

Fiziksel bağlantı, ağın gerçekte ne gördüğünü gösteren tek yerdir. Tünel açıkken ofise giden oturum VPN sunucusuna yönelik şifreli yük olarak görünmelidir, 10.20.5.7'e bir bağlantı olarak değil:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

İlk süzgeç yerelde dışarı çıkan ad çözümlemesini yakalar; bu en yaygın ve en sessiz sızıntıdır — sayfa yine yüklenir, çözümleyici yalnızca sorguyu gördü. İkincisi yalnızca tünel içinde var olması gereken iç adrese giden sıradan trafiği yakalar. Windows'ta pktmon aynı işi sürücü olmadan yapar: pktmon filter add -p 53, sonra pktmon start --capture --pkt-size 128, sonra pktmon stop ve pktmon format pktmon.etl -o capture.txt. Bu bayraklar Windows sürümleri arasında biraz farklıdır, bu yüzden sözdizimine güvenmeden önce pktmon filter add /?'i kontrol edin.

Sızıntıları bulmak için fiziksel arabirimi yakalayın; tüneldeki yakalama zaten orada olduğuna inandığınız paketleri içerir, sunucuda ise kaynağı geçit olan okunamaz dış paketleri içerir. Herhangi bir arabirimdeki bayt sayaçları paketleri tanımlar, programları değil; trafiği bir sürece atfetmek için soketleri süreçlerle eşleyen bir izleyici gerekir.

Dışarıdaki bir hizmete sorun, sonra her uygulama için yeniden sorun

Çıkışı kanıtlayan tek kontrol dışarıdan gelen bir yanıttır: gördüğü kaynak adresi geri döndüren bir hizmet. Arabirimi seçebildiğiniz bir kabuktan çalıştırın ve iki kez çalıştırın:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Farklı yanıtlar iki yolun kanıtını ve belirli bir uygulamayı sınama yöntemini verir: uygulamayı bağlayın ya da tek rotalı bir ağ ad alanında çalıştırın ve uzak ucun hangi adresi kaydettiğini görün. Aynı yanıtlar ilginç arızadır: ya bağlama etkili olmadı ya da ana bilgisayar ile uzak uç arasında bir şey kaynak adresi varmadan önce yeniden yazıyor. Windows'ta curl --interface bağdaştırıcının adını değil adresini ister.

VPN adresini bildiren bir tarayıcı tarayıcıyı kanıtlar. Bir e-posta istemcisi, bir paket yöneticisi, bir yedekleme aracısı veya ikinci bir tarayıcı profili her biri başka bir yol izleyebilir, özellikle bir proxy ayarı veya bölünmüş tünel rotası bunlardan birini kapsadığında. Adres değişikliği tek başına sızıntı kanıtı değildir: yük dengeleyici gördüğü çıkışa göre farklı yanıt verebilir, bu yüzden sayfayı değil kaydedilen kaynak adresini karşılaştırın.

Eşi doğrulamak için sunucu görünümünü kullanın

Sunucu başka bir soruyu yanıtlar: bir eş bağlı mı, ne kadar taşımış ve oturum yeniden başlamış mı. Sunucuda eş etkinken istemci sayaçları neredeyse kımıldamıyorsa, istemci tablosu ne derse desin uygulama trafiği tünele girmiyor demektir. Hiçbir şeyin çalışmadığını bildiren bir kullanıcı için çok veri taşıyan bir eş ise başka bir soruşturmadır.

Burada iki tuzak var. Maskelenmiş bir tünel her akışı geçitten geliyormuş gibi gösterir, böylece günlükler ve istemci başına muhasebe tek adreste çöker. Ve istemci yerel ana bilgisayar olarak ele alınır, bu yüzden birinin VPN üzerinden dosya kopyalayıp kopyalamadığı sorusuna sunucudaki dosya paylaşımı trafiği veya sunucudaki ana bilgisayar denetimi yanıt verir — tüneli izlemek uç noktaları ve hacmi verir, dosya adlarını değil.

Tasarım kararını sızıntıdan ayırın

Tünel dışındaki her şey sızıntı değildir. Bağlantı yerel ve yayın trafiği tasarım gereği yerel kalır, multicast ile bulunan bir yazıcı LAN'da duyurmaya devam eder ve DHCP yerelden çıkmalıdır. Belirli bir arabirime bağlanmış bir uygulama yönlendirme tablosunu bilerek atlar ve bunu yalnızca bir güvenlik duvarı kuralı, bir ad alanı veya bir ilke rotası değiştirir.

IPv6 kontrol listesinde kendi satırını hak eder. Yalnızca IPv4 taşıyan bir tünel, çift yığınlı bir ana bilgisayara ikinci kullanılabilir yolu bırakır ve çift yığınlı bir hedef onu tercih eder — çözümleyici IPv6 üzerinden erişilebilirse DNS dahil. IPv4 sonucunu tam saymadan önce bağdaştırıcıda IPv6'yı kapatın veya tünelin onu taşıdığını doğrulayın.

Kontroller çeliştiğinde, çelişki genellikle arızayı adlandırır:

İşleyen bir sıra: yönlendirme tablosunu bağlanmadan önce ve sonra kaydedin, bir iç ve bir genel adı izleyin, DNS'i fiziksel bağdaştırıcıda yakalayın, belirli uygulama için çıkış adresini kabuktan geri alın, sonra hacim için sunucuyu okuyun. İlk dördü uyuşursa tünel düşündüğünüzü taşıyor ve kalan sorun onun üstünde. İkisi uyuşmazsa, uyuşmayan çift arızadır, simge değil.