OpenVPN istemcisinin trafiği ağ geçidinde nerede izlenir

Bağlı bir istemcinin hangi hedeflere ulaştığını bilmek istiyorsunuz, bu yüzden VPN sunucusunda bir kabuk açıp ss yazıyorsunuz. İşe yarar hiçbir şey görünmüyor ve tünelin bozuk olduğu sonucu biraz fazla kolay geliyor. Yönlendirme yapan OpenVPN ağ geçidi istemcinin paketlerini iletir; onların TCP bağlantılarını sonlandırmaz ve onlar için soket tutmaz. Kanıt başka bir yerde yaşar ve nerede olduğu, trafiğin tünelden çıktıktan sonra nasıl ele alındığına bağlıdır.

Hangi düzenlemeye baktığınıza karar verin

İki yaygın biçim tamamen farklı kanıtlar üretir. Yönlendirme yapan ağ geçidi kapsülü çözer, iletir ve muhtemelen kaynak NAT yapar, böylece istemcinin bağlantısı yerel bir soket olmadan uçtan uca var olmaya devam eder.

Proxy trafiği sonlandırır: bağlantıyı kabul eder, sonra kendi üst bağlantısını açar. Bu düzenlemede bir istek için iki bağlantı vardır ve aralarındaki ilişki yalnızca proxy'nin kendi kayıtlarında bulunur. Bu ikisinden hangisini kurduğunuzu bilmek, çekirdeğin akış durumunu mu yoksa uygulama günlüklerini mi okumanız gerektiğine karar verir.

Karışıklığın çoğu tahminden gelir. Aracı seçmeden önce biçimi doğrulayın. Önce sunucu yapılandırmasında proxy yönergesi olup olmadığını okuyun, çünkü varlığı sonraki her adımı değiştirir. O yoksa paket yolu yönlendirmedir ve çekirdeğin akış durumu sizin kanıtınızdır.

Önce adresi bir oturuma bağlayın

Sunucunun oturum durumundan başlayın ve istemcinin mevcut iç adresini belirleyin. Havuz adresleri yeniden kullanılır, bu yüzden adres tek başına bir kiralamadır, kişi değil.

Zamanı ve doğrulanmış kimliği birlikte kaydedin ve o istemcinin arkasında bütün bir LAN'ın saklanıp saklanmadığını not edin. Uzak uç bir alt ağı yönlendiriyorsa gördüğünüz iç adresler özgün ana makineler veya çevrilmiş olanlar olabilir.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Bu çift aynı anda iki soruyu yanıtlar: tünel arayüzü hangi öneki sunuyor ve ilgilendiğiniz aralıkta hangi oturum etkindi. Herhangi bir akış kaydını yorumlamadan önce bunu yapın, çünkü yanlış oturuma bağlanmış inandırıcı bir tuple hiç kanıt olmamasından daha kötüdür.

Yönlendirme yapan ağ geçidinde akış tablosunu okuyun

Adres ve aralık belirlendikten sonra izlenen bağlantıların salt okunur listesi, ağ geçidinin onun için neyi ilettiğini gösterir. Tüm tabloyu okumamak için özgün kaynağa göre filtreleyin.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Her kayıt iki tuple içerir, özgün ve yanıt, bunlar tek bir akışın iki yönüdür, iki uygulama değil. Kaynak NAT'lı bir yolda özgün tuple tünelin adresini korurken yanıt tarafı çevrilmiş ağ geçidi adresini gösterir ve çıktının ilk bakışta yanlış görünmesinin nedeni tam olarak budur.

Listeyi tarih değil canlı durum olarak ele alın. Kısa akışlar çoktan sona ermiş olabilir, izlenmeyen trafik asla görünmez ve başka bir ağ ad alanı başka bir tablo gösterir. conntrack başvurusu filtreleri ve iki yönlü çıktıyı belgeler.

Okumayı doğrulamak için tek bir sınırlı yakalama

Tünel arayüzü baktığınız yerde görünüyorsa, tek bir sınırlı yakalama belirlediğiniz paketlerin kablodaki paketler olup olmadığını kesinleştirir. Filtreyi dar, paket sınırını küçük tutun.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Zaman damgalarını, protokolü ve bağlantı noktalarını akış kaydıyla ve test olarak yaptığınız istekle karşılaştırın. NAT'tan sonra alınan bir yakalama yalnızca ağ geçidinin genel adresini gösterir, tünel tarafı ise hâlâ istemcininkini gösterebilir ve bu fark bilgidir, tutarsızlık değil.

Arayüz hiçbir şey görmüyorsa, istemcinin boşta olduğu sonucuna varmadan önce veri yolunu kontrol edin: istemciden istemciye trafik ve bazı boşaltma yolları izlediğiniz noktadan asla geçmez.

Proxy günlükleri ve gördüklerinizin sınırları

Yolda bir proxy olduğunda, üst soketleri soket tablosunda görünür ama VPN istemcileriyle bire bir eşleşmez, özellikle havuzlama veya çoklama ile. İstemci kimliğini, hedefi, zaman damgasını ve kaydettiği herhangi bir istek tanımlayıcısını ilişkilendirmek için proxy'nin yapılandırılmış işlem günlüğünü kullanın.

Her isteğin varsayılan olarak günlüğe kaydedildiğini varsaymak yerine dağıtılan sürümün günlükleme yapılandırmasını kontrol edin.

Son olarak kapsam konusunda kesin olun. Hedef adresi ve bağlantı noktası üst veridir, URL değildir ve sayfa içeriği de değildir, çünkü iç HTTPS oturumu tünelden bağımsız olarak kendi korumasını korur. Neyi gözlemlediğinizi, hangi gözlem noktasından ve saat kaçta bildirin.