Proxy üzerinden çalışırken tcpdump ve Wireshark: kopmaların teşhisi
Makale içeriği
- Giriş: istemci loglarının artık yetmediği an
- Temeller: tek bir bağlantının üç segmenti
- Derinlemesine: tünelde neden yalnızca connect görünür
- Tcpdump pratikte: gigabaytlar olmadan döküm almak
- Wireshark: dökümü açık bir kitap gibi okumak
- Dökümden teşhis: bağlantıyı tam olarak kim kesti
- Kendi trafiğinizi sslkeylogfile ile şifresiz hale getirme
- Tipik kopma tabloları ve nasıl okunur
- Döküm alırken ve okurken tipik hatalar
- Mühendisin araçları ve kaynakları
- Vakalar ve uygulama sonuçları
- Desteğe başvurmak için döküm alma kontrol listesi
- Sss: proxy üzerinden dökümlerle ilgili sık sorulan sorular
İstemci logları, bir şey gösterdikleri sürece mükemmeldir. Ama bir gün duvara toslarsınız: uygulama sadece connection reset yazar, proxy kendi loglarında sessizdir ve hedef sunucu her şeyin yolunda olduğuna yemin eder. Kim yalan söylüyor? Hiç kimse. Siz sadece soruna üst kattan bakıyorsunuz, gerçek ise paket seviyesinde yaşıyor. Ve oraya inmeniz gerekiyor.
Bu makale, trafiğin proxy üzerinden geçtiği durumlarda tcpdump ve Wireshark ile çalışmaya dair ayrıntılı bir mühendislik rehberidir. Proxy'den önce ve sonra gözlemcinin tam olarak ne gördüğünü, HTTPS tünelinin içinde neden sadece CONNECT isteğinin göründüğünü ve tek bir dökümden kopmanın sizin tarafınızda mı yoksa hedef sunucuda mı olduğunu nasıl ayırt edeceğinizi ele alacağız. Bu, uygulama seviyesinde HTTPS'i yakalama veya değiştirme ile ilgili değil - bu, paket seviyesi ve dürüst kopma teşhisi ile ilgilidir.
Giriş: istemci loglarının artık yetmediği an
Tipik bir altyapı hayal edin. Uygulamanız, HTTP proxy Proxeon üzerinden harici bir API'ye başvuruyor. Genelde her şey çalışır. Ama isteklerin yüzde beşi hata ile düşüyor ve nedenini anlamıyorsunuz. Uygulama logları yalnızca kopma gerçeğini gösteriyor. Proxy logları tünelin kurulduğunu gösteriyor. Hedef sunucu sizin kontrolünüzün dışında. Üç kara kutu arasında sıkışıp kaldınız.
İşte tam burada paket teşhisi başlar. Trafik dökümü, makineler arasındaki konuşmanın kelimesi kelimesine, yorum olmadan ve yalan söyleme hakkı olmadan kaydedilmiş tutanağıdır. Paket ya gelmiştir ya da gelmemiştir. RST bayrağı ya vardır ya da yoktur. TCP rol yapmayı bilmez. Ve bu tutanağı okumayı öğrenirseniz, tahmin etmeyi bırakırsınız.
Bu rehberden öğrenecekleriniz: diski gigabaytlarca veriyle doldurmadan tcpdump komutuyla döküm nasıl alınır; Wireshark'ta hangi görüntüleme filtreleri saatler kazandırır; şifre çözmeden TLS el sıkışması nasıl okunur; bayraklardan kopmanın sorumlusu nasıl belirlenir; ve kendi trafiğinizi SSLKEYLOGFILE değişkeni üzerinden yasal olarak nasıl şifresiz hale getirebilirsiniz. Sonunda, desteğe başvurmak için hazır bir kontrol listesi ve ayrıntılı bir SSS sizi bekliyor.
Temeller: tek bir bağlantının üç segmenti
İlk olarak kafanıza yerleştirmeniz gereken şey: istemci proxy üzerinden çalıştığında, bu tek bir bağlantı değil, en az iki farklı TCP bağlantısıdır. Biri istemciden proxy'ye. Diğeri proxy'den hedef sunucuya. Bu, sonraki analizin anlamsız olacağı temeldir.
Döküm nedir ve nasıl yapılandırılmıştır
Paket dökümü, belirli bir makinenin belirli bir ağ arayüzünde yakalanan ağ paketlerinin dizisidir. Anahtar kelime - belirli. Her zaman yalnızca yakalama noktasından fiziksel olarak geçen trafiği görürsünüz. İstemcide döküm alırken istemci-proxy konuşmasını görürsünüz. Proxy'de alırken her iki tarafı da görürsünüz. Hedef sunucuda - yalnızca proxy-sunucu konuşmasını.
Her paket katman başlıkları taşır: Ethernet, IP, TCP veya UDP ve yük. Kopma teşhisi için öncelikle TCP seviyesiyle ilgileniyoruz: port numaraları, sıra numaraları (sequence), onaylamalar (ACK) ve bayraklar - SYN, ACK, FIN, RST, PSH.
Proxy modeli: tek yerine iki bağlantı
HTTP proxy ile tünel modunda çalışırken trafik akışının şemasını inceleyelim:
- Segment A (istemci - proxy). İstemci, proxy'nin IP ve portuna bir TCP bağlantısı açar. Bu kanal üzerinden tünel kurma komutunu gönderir.
- Segment B (proxy - hedef sunucu). Proxy kendi adına hedef sunucuya ayrı bir TCP bağlantısı açar. Bu artık farklı bir src-IP, farklı bir src-port, farklı bir durumdur.
- Mantıksal tünel. Kurulumdan sonra proxy, segment A'daki baytları segment B'ye ve tersine körü körüne aktarmaya başlar. İçindekini incelemez.
Bu neden teşhis için önemli? Çünkü kopma iki segmentten herhangi birinde meydana gelebilir ve istemci açısından semptom aynı olacaktır - bağlantı düştü. Ancak neden, dolayısıyla çözüm farklıdır.
HTTP proxy, SOCKS ve tünelleme
Şifrelemesiz normal bir HTTP isteğinde proxy hem yöntemi, hem URL'yi, hem de başlıkları görür. Ancak HTTPS söz konusu olduğunda tablo değişir. İstemci, proxy'ye şifrelenmemiş isteği veremez - aksi halde şifrelemenin anlamı kalmaz. Bu nedenle tünelleme mekanizması uygulanır: istemci proxy'ye beni şu hosta şu porttan bağla ve daha fazla karışma der. Bu komut CONNECT'tir.
Derinlemesine: tünelde neden yalnızca CONNECT görünür
Bu, ilk kez proxy üzerinden HTTPS trafiğinin dökümünü açan mühendislerin en sık karşılaştığı kafa karışıklığı kaynağıdır. İstek ve yanıtları görmeyi beklersiniz, ama tek bir satır ve ardından okunamayan bir karmaşa görürsünüz. Neden böyle olduğunu ve neden doğru olduğunu anlayalım.
CONNECT anatomisi
İstemci proxy üzerinden güvenli bir bağlantı kurmak istediğinde, proxy'ye açık metin olarak şu isteği gönderir:
CONNECT api.example.com:443 HTTP/1.1\r\nHost: api.example.com:443\r\n\r\nProxy, api.example.com'a 443 portundan bir TCP bağlantısı açar ve her şey başarılıysa istemciye şöyle yanıt verir:
HTTP/1.1 200 Connection established\r\n\r\nBu andan itibaren proxy aptal bir boruya dönüşür. İstemcinin bundan sonra gönderdiği her şeyi proxy sunucuya bayt bayt iletir ve tam tersi. Peki istemci bundan sonra ne gönderir? TLS ClientHello, el sıkışmanın başlangıcı. Şifrelenmiş alışveriş. Proxy'nin anahtarları yok ve fiziksel olarak içeri bakamaz.
Dökümü olan bir gözlemci için bu ne anlama gelir
İstemcide veya proxy'de döküm alıyorsanız şunları görürsünüz:
- Proxy'ye TCP bağlantısının kurulması (SYN, SYN-ACK, ACK).
- Hedef host adı ve portu ile CONNECT isteğinin açık metni.
- Proxy'nin tünel kurulum durumu hakkındaki yanıtı.
- Ve sonra - yalnızca TLS kayıtları, çıplak gözle yalnızca el sıkışma meta verilerinin okunabildiği şifrelenmiş akış.
İşte ana içgörü: hedef host adı dökümde her zaman görünür - CONNECT satırında. Tek bir şifresi çözülmüş bayt olmadan bile, istemcinin tam olarak nereye ulaşmaya çalıştığını bilirsiniz. Bu teşhiste paha biçilmezdir: istek gerçekten oraya mı gitti sorusunu hemen elersiniz.
TLS SNI: host adının ikinci kaynağı
CONNECT olmasa bile (örneğin, proxy'siz doğrudan bağlantıda), host adı genellikle ClientHello içindeki SNI alanında görünür. Server Name Indication, el sıkışmanın başında açık metin olarak iletilir. Wireshark bunu mükemmel şekilde gösterir. Modern ağlarda SNI'yi gizleyen Encrypted Client Hello popülerlik kazanıyor, ancak CONNECT tüneli üzerinden çalışırken bu teşhisi engellemez - host adı zaten CONNECT'in kendisinde belirtilmiştir.
tcpdump pratikte: gigabaytlar olmadan döküm almak
Artık işe koyulalım. tcpdump, neredeyse her Unix benzeri sistemde bulunan komut satırı paket yakalama aracıdır. Güçlü, hafif ve grafik arayüzü olmayan sunucularda vazgeçilmezdir. Kilit senaryoları inceleyelim.
Doğru arayüzde temel yakalama
Önce arayüz listesine bakalım:
tcpdump -DBelirli bir arayüzde ekrana yazdırarak yakalama:
tcpdump -i eth0 -n-n bayrağı isim çözümlemesini devre dışı bırakır, böylece tcpdump DNS sorgularında yavaşlamaz ve saf IP'ler gösterir. Bu önemlidir: gerçek zamanlı çözümleme tabloyu bozar ve yakalamayı yavaşlatır.
Host ve porta göre filtreleme
Yüklü bir sunucuda tüm arayüz trafiğini yakalamak - gigabaytlarca çöpe giden kesin yoldur. Baştan filtreleyin. Belirli bir proxy'ye IP ve port üzerinden trafik yakalama:
tcpdump -i eth0 -n host 203.0.113.10 and port 8080Yalnızca hedef sunucuya (proxy tarafında faydalı):
tcpdump -i eth0 -n host api.example.com and port 443Birleştirme: proxy'ye VEYA hedef sunucuya trafik:
tcpdump -i eth0 -n "(host 203.0.113.10 and port 8080) or (host 198.51.100.5 and port 443)"Tırnak işaretlerine dikkat edin: ifade parantez ve mantıksal operatörler içerdiğinde, kabuğun özel karakterleri yorumlamaması için filtreyi tırnak içine alın.
Dosyaya yazma ve doğru format
Wireshark'ta sonraki analiz için pcap formatında bir dosya gerekir. -w bayrağı ham paketleri dosyaya yazar:
tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump.pcapÇok önemli bir nokta: -s 0 veya modern varsayılan davranış, paketi tamamen yakalar (snaplen). Eski sürümler paketleri keserdi. Tam veriye ihtiyacınız varsa, snaplen'in yeterli olduğundan emin olun:
tcpdump -i eth0 -n -s 0 host 203.0.113.10 and port 8080 -w dump.pcapKopma teşhisi için yalnızca başlıklara ihtiyacınız varsa (bayraklar, seq, ack), içeriğe değil, dosyanın daha kompakt olması için snaplen'i sınırlayın:
tcpdump -i eth0 -n -s 96 host 203.0.113.10 and port 8080 -w headers.pcapDosya rotasyonu: disk nasıl doldurulmaz
Aralıklı bir sorunun uzun teşhisinde yakalama saatlerce sürebilir. Tek bir devasa dosya elde etmemek için boyut ve dosya sayısına göre rotasyon kullanın. -C bayrağı dosya boyutunu megabayt cinsinden, -W ise halka tampondaki dosya sayısını belirler:
tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -w dump-%Y%m%d-%H%M%S.pcap -C 100 -W 10Bu komut yüz megabaytlık on adede kadar dosya oluşturur. Onuncu dolduğunda tcpdump birinciyi üzerine yazmaya başlar. Böylece her zaman son yaklaşık bir gigabayt trafiği saklarsınız ve diski asla taşırmazsınız. Dosya adındaki zaman şablonu arşivi okunabilir kılar.
Alternatif - zamana göre rotasyon. -G bayrağı, yeni bir dosyanın oluşturulacağı saniye cinsinden aralığı belirler:
tcpdump -i eth0 -n host 203.0.113.10 and port 8080 -G 3600 -w dump-%Y%m%d-%H%M%S.pcapHer saat - yeni bir dosya. Olayın zaman aralığını sonradan hızlıca bulmanız gerektiğinde kullanışlıdır.
Olay etrafında yakalama: nadir kopmayı yakalamak
En sinsi durum - sorun saatte bir ve öngörülemez şekilde tekrarlanıyor. Halka tamponu başlatır ve beklersiniz. Uygulama hatayı kaydettiğinde, tam zamanı işaretler ve yakalamayı durdurursunuz. Ardından analizde doğru saniyeye gidersiniz. Pratik bir püf noktası: uygulama hata durumunda loga milisaniyeli tam zaman damgası yazsın - bu, dökümdeki çapanızdır.
Doğrudan tcpdump'ta TCP bayraklarına göre filtre
Bazen yalnızca belirli bayraklı paketleri yakalamak yararlıdır. Örneğin, yalnızca RST bayraklı paketleri, sıfırlamaların uçuşup uçuşmadığını hemen anlamak için:
tcpdump -i eth0 -n "tcp[tcpflags] & tcp-rst != 0"Yalnızca SYN paketleri - bağlantı kurma girişimlerini izlemek için kullanışlı:
tcpdump -i eth0 -n "tcp[tcpflags] & tcp-syn != 0"Proxy'ye bağlantı kapanışlarını izlemek için RST veya FIN kombinasyonu:
tcpdump -i eth0 -n "host 203.0.113.10 and (tcp[tcpflags] & (tcp-rst|tcp-fin) != 0)"Wireshark: dökümü açık bir kitap gibi okumak
tcpdump yakalar, Wireshark okur. Bu, zengin görüntüleme filtresi ve protokol çözücü sistemine sahip grafik bir analizördür. Kaydedilen pcap dosyasını açar ve soruşturmaya başlarsınız. Görevimiz için gerçekten gerekli araçları inceleyelim.
Görüntüleme filtreleri ve yakalama filtreleri
Karıştırmamak önemlidir. Yakalama filtresi (tcpdump'taki) paketleri yazımdan önce eler - yakalanmayan yoktur. Wireshark'taki görüntüleme filtresi bir mercektir: yalnızca zaten yüklenmiş dosyadan gereksizi gizler, hiçbir şeyi silmez. Sözdizimleri farklıdır. Aşağıdakiler görüntüleme filtreleridir.
Temel görüntüleme filtreleri
Yalnızca belirli bir IP'ye trafik gösterme:
ip.addr == 203.0.113.10Yalnızca proxy TCP portu:
tcp.port == 8080Host ve port kombinasyonu:
ip.addr == 203.0.113.10 && tcp.port == 8080Yalnızca RST bayraklı paketleri gösterme - tüm bağlantı sıfırlamaları anında görünür:
tcp.flags.reset == 1Yalnızca FIN paketleri:
tcp.flags.fin == 1Yalnızca ACK'siz SYN - bağlantı açma girişimleri:
tcp.flags.syn == 1 && tcp.flags.ack == 0CONNECT ve HTTP başlıklarını arama
Dökümde CONNECT isteğinin kendisini bulmak için:
http.request.method == "CONNECT"Proxy'nin tünel kurulum yanıtı bir HTTP yanıtı olarak görünür. Tüm HTTP isteklerini filtreleme:
http.requestKodlu tüm HTTP yanıtları:
http.responseFollow TCP Stream: konuşmayı bir araya getirme
Bu, muhtemelen Wireshark'ın görevimiz için en değerli özelliğidir. Bir bağlantının herhangi bir paketine sağ tıklayın, ardından Follow, ardından TCP Stream. Wireshark tüm iki yönlü alışverişi tek bir pencerede toplar; istemci ve sunucu verileri farklı renklerde gösterilir. Şifrelemesiz trafik için saf metin görürsünüz: CONNECT isteği, proxy yanıtı ve ardından okunamayan TLS baytları.
İşte Follow Stream'de kopmayı CONNECT'te açıkça görürsünüz. İlk satırlar insan metni olarak okunur, ardından şifrelenmiş alan başlar. Bu şunu doğrular: tünel kuruldu, ardından şifreleme geliyor ve anahtarlar olmadan daha derine bakamazsınız - ki bu tamamen normaldir.
Şifre çözmeden TLS el sıkışmasını okumak
Anahtarlarınız olmasa bile, TLS el sıkışması çok şey anlatır. El sıkışma kayıtlarını filtreleyin:
tls.handshakeİstemcinin sunucuya kendini tanıttığı ClientHello'yu bulma:
tls.handshake.type == 1Sunucunun yanıtı olan ServerHello'yu bulma:
tls.handshake.type == 2Bu çift ne verir? ClientHello görüyorsanız ama hiç ServerHello görmüyorsanız - sunucu el sıkışmaya yanıt vermedi. Neden: ya hedef sunucu proxy'nin arkasından erişilemez, ya da kopma yanıttan önce meydana geldi. İkisini de görüyorsanız ama ardından kopma varsa - sorun daha derinde, zaten şifrelenmiş alışverişte veya uygulama seviyesinde.
ClientHello içinde hiçbir şifre çözme olmadan SNI alanı okunur - başvurunun yapıldığı host adı:
tls.handshake.extensions_server_name == "api.example.com"Ayrıca önerilen TLS sürümlerini ve şifre takımlarını da görürsünüz. Sunucu ServerHello yerine Alert yanıtı verirse, el sıkışma reddedilmiştir - örneğin sürüm veya şifre uyumsuzluğu. Alertler için filtre:
tls.alert_messageDökümden teşhis: bağlantıyı tam olarak kim kesti
Makalenin kalbine geldik. Bağlantı düştü - soru onu kimin ve neden kestiği. TCP iz bırakır ve bunlardan bir karara varabilirsiniz. Kilit sinyalleri inceleyelim.
Normal sonlandırma: FIN
Bağlantının düzenli kapanışı FIN paket alışverişi ile gerçekleşir. Bir taraf iletimi bitirdim der, diğer taraf onaylar ve o da FIN gönderir. Bu nazik bir vedadır. Dökümde düzgün bir FIN-ACK-FIN-ACK alışverişi görüyorsanız, bağlantı doğru şekilde kapanmıştır. Tek soru, istemcinizin bu kapanışı bekleyip beklemediğidir. Sunucu yanıtı tamamen verdikten sonra FIN gönderdiyse, her şey yolundadır. FIN beklenen verinin ortasında geldiyse - sunucu erken kapatmıştır.
Acil sonlandırma: RST
RST bayrağı - bu kaba bir kopmadır. Veda değil, kapıyı çarpıp çıkmaktır. RST şu anlama gelir: bu bağlantı geçersiz, derhal unut. Nedenleri çeşitlidir:
- Port kapalı - o tarafta kimse dinlemiyor. RST, SYN'den neredeyse anında sonra gelir.
- O taraftaki uygulama soketi acil olarak kapatmıştır.
- Ara bir cihaz (güvenlik duvarı, yük dengeleyici, proxy'nin kendisi) bağlantıyı zaman aşımı veya politika gereği zorla sıfırlamıştır.
- Taraflardan biri, hakkında çoktan unuttuğu bir bağlantı için paket almıştır.
Çözümün anahtarı - RST'yi kimin gönderdiği. RST paketinin source IP'sine bakın. RST proxy'nin IP'sinden geldiyse - proxy ya da proxy ile siz arasındaki bir şey kesmiştir. Hedef sunucunun IP'sinden geldiyse - proxy-sunucu segmenti sunucuya ulaşmıştır ve onu ya sunucu ya da yanındaki bir cihaz kesmiştir.
Ama iki segmenti unutmayın. İstemcide döküm alırken yalnızca proxy'nin IP'sinden RST görürsünüz, çünkü sunucuyla doğrudan iletişim kurmuyorsunuz - aranızda proxy var. Segment B'de ne olduğunu anlamak için proxy tarafında döküm gerekir. Bundan kontrol listesi bölümünde bahsedeceğiz.
Yeniden iletimler: retransmission
Wireshark yeniden iletimleri otomatik olarak işaretler. Filtre:
tcp.analysis.retransmissionYeniden iletim, göndericinin gönderilen segmente zamanında ACK almadığını ve tekrar gönderdiğini gösterir. Tekil retransmissionlar internet için normaldir. Ama retransmission fırtınası, yolda paket kaybının belirtisidir. Özellikle mobil ve kararsız ağlar için tipiktir.
İlgili faydalı filtreler. Kaçırılan segmenti işaret eden yinelenen ACK'ler:
tcp.analysis.duplicate_ackWireshark'ın tanıyabildiği tüm sorunlu olaylar:
tcp.analysis.flagsArdından RST gelen bir dizi retransmission görüyorsanız, tablo netleşir: paketler kayboldu, taraflardan biri beklemekten yoruldu ve bağlantıyı kesti. Bu, kötü bir kanal için tipik bir hikayedir.
Zero Window: alıcı boğuldu
TCP, alım penceresi aracılığıyla akış kontrol mekanizmasına sahiptir. Alıcı verileri işlemeye yetişemezse zero window bildirir - tampon dolu, yavaşla. Filtre:
tcp.analysis.zero_windowZero window bir ağ kaybı değil, alıcı uygulamanın soketten yavaş okuduğunun sinyalidir. Örneğin, istemciniz büyük bir yanıt alıyor ama tek iş parçacığında işliyor ve yetişemiyor. Gönderici bekliyor, pencere açılmıyor ve sonunda zaman aşımı devreye girebilir. Zero window'dan sonra window update gelirse, her şey normale döner. Zero window'dan sonra sessizlik ve ardından RST gelirse - alıcı dondu veya çöktü.
İlgili sinyal - window full, göndericinin bildirilen pencereye takıldığı ve daha fazla gönderemediği durum:
tcp.analysis.window_fullKarar matrisi
Mantığı pratik bir çerçeveye dökelim. Kopmadan önceki canlı bağlantının son paketlerine bakın:
- SYN var, SYN-ACK yok, ardından RST veya sessizlik. Bağlantı kurulmadı. Hedef nokta erişilemez veya port kapalı. Proxy üzerinden çalışırken RST, arkasındaki sunucu erişilemezse proxy'den gelir.
- Kurulum geçti, CONNECT gönderildi, yanıt yok. Proxy komutu kabul etti ama hedef sunucuya ulaşamadı ya da sunucu sessiz. Zaman aşımını bekleyin.
- ClientHello var, ServerHello yok. Hedef sunucu el sıkışmaya yanıt vermedi. Sorun proxy-sunucu segmentinde.
- Veri aktı, ardından sunucudan RST. Sunucu bağlantıyı acil olarak kapattı - aşırı yük, uygulama hatası, kendi tarafında zaman aşımı.
- Veri aktı, ardından yanıtın ortasında sunucudan FIN. Sunucu düzenli olarak kapattı ama istemcinin beklediğinden önce - muhtemelen yanıt boyutu limiti veya istek zaman aşımı.
- Retransmission fırtınası, ardından RST. Kanaldaki kayıplar. Sorunu ağda arayın - mobil bağlantı, aşırı yüklü rota.
- Zero window, ardından sessizlik. İstemciniz verileri yeterince hızlı okumadı. Sorun sizin işleme tarafınızda.
Kendi trafiğinizi SSLKEYLOGFILE ile şifresiz hale getirme
Bazen yalnızca meta veriler yeterli değildir - şifrelenmiş alışverişin içeriğini görmeniz gerekir. Bu yalnızca trafik sizin olduğunda yasal ve doğrudur: sizin istemciniz, sizin anahtarlarınız, sizin uygulamanız. Başkasının trafiğini yakalamıyor ve sertifika değiştirmiyoruz. Kendi istemcimizden nazikçe oturum anahtarlarını bir dosyaya yazmasını ister, ardından bunları Wireshark'a besleriz.
Nasıl çalışır
Birçok istemci TLS kütüphanesi SSLKEYLOGFILE ortam değişkenini destekler. Tanımlandığında, kütüphane belirtilen dosyaya oturum sırlarını standart formatta ekler. Wireshark bu dosyayı okuyabilir ve dökümdeki ilgili oturumların şifresini çözebilir. Sihir yok ve hack yok - istemcinin kendisi anahtarlarını gönüllü olarak verir, çünkü siz, istemcinin sahibi olarak öyle emrettiniz.
Komut satırı ve destekli motorlu tarayıcılar için örnek
Unix benzeri sistemlerde uygulamayı başlatmadan önce değişkeni ayarlama:
export SSLKEYLOGFILE=/home/user/tls-keys.logÖrneğin, uygun kütüphaneyle derlenmiş bu değişkeni destekleyen curl istemcisini başlatma:
SSLKEYLOGFILE=/home/user/tls-keys.log curl -x http://203.0.113.10:8080 https://api.example.com/statusBurada -x bayrağı Proxeon proxy'sini belirtir ve SSLKEYLOGFILE oturum anahtarlarını kaydettirir. Paralel olarak tcpdump ile döküm alırsınız. Ardından hem pcap hem de anahtar dosyanız olur.
Wireshark'ta anahtarları bağlama
Wireshark'ta ayarları açın, TLS protokolü bölümünü bulun, ön ana sırlar log dosyası alanına anahtar dosyasının yolunu belirtin. Ardından dökümü yeniden okuyun. Daha önce okunamayan TLS kayıtları şifresiz hale gelir: tünel içindeki gerçek HTTP isteklerini ve yanıtlarını görürsünüz. Artık Follow TLS Stream uygulama alışverişini tamamen gösterir.
Önemli uygulanabilirlik sınırları
- Yalnızca anahtarları dosyaya giren trafiğin şifresi çözülür. Başkalarının oturumları şifreli kalır - ve bu doğrudur.
- Anahtarlar hassastır. tls-keys.log dosyası aslında oturumlarınızın içeriğini açar. Bir sır gibi saklayın, hata ayıklamadan sonra silin.
- Yöntem, başkalarının trafiğini gözlemlemek için değil, kendi uygulamalarınızda hata ayıklamak içindir. Bu temel bir etik ve yasal sınırdır.
Tipik kopma tabloları ve nasıl okunur
Tanınabilir kalıplar olmadan teori hızla uçar. Tekrar tekrar karşılaşacağınız birkaç karakteristik senaryoyu inceleyelim. Onları ilk bakışta tanımayı öğrenin.
Bağlantı zaman aşımı: proxy arkasındaki sunucu erişilemez
İstemcideki dökümdeki tablo: proxy'ye TCP normal kuruldu, istemci CONNECT gönderdi ve sessizlik başladı. Proxy'den 200 yanıtı yok. Bir süre sonra ya proxy'den RST gelir ya da uygulama kendi zaman aşımıyla bağlantıyı kapatır.
Bu ne anlama gelir: proxy komutunuzu kabul etti, hedef sunucuya Segment B açmaya çalıştı, ama sunucu yanıt vermedi. Hedef sunucu yatıyor, port kapalı veya ona giden rota kopuk. Sizin tarafınız ve proxy düzgün çalışıyor. Eylem: hedef hostun erişilebilirliğini kontrol edin, gerekirse Segment B'yi görmek için proxy tarafında döküm alın.
Yanıtın ortasında kopma
Tablo: tünel kuruldu, TLS çalıştı, veri akmaya başladı, yanıtın bir kısmı alındı ve aniden sunucu tarafından FIN veya RST. İstemci eksik yanıt aldı ve kesilmiş içerikten şikayet ediyor.
Bu bir FIN ise, sunucu düzenli ama erken kapatmıştır - muhtemelen yanıt üretiminde zaman limiti veya kendi tarafında boyut kısıtlaması tetiklenmiştir. RST ise, sunucu ya da yanındaki bir cihaz acil olarak kesmiştir. Eylem: sorun büyük yanıtlarda tekrarlanıyorsa - zaman aşımları ve limitleri arayın. SSLKEYLOGFILE ile kendi trafiğinizin şifresini çözmek, HTTP başlığının alınıp alınmadığını ve gövdenin ne kadarının gelebildiğini görmenize yardımcı olur.
Mobil ağdaki kayıplar
Tablo: birçok paket retransmission olarak işaretlenmiş, duplicate ack görülüyor, paketler arasında belirgin zaman sıçramaları gözlemleniyor. Bağlantı ya dayanılmaz yavaş ya da sonunda zaman aşımıyla kopuyor.
Bu, kararsız radyo kanalının klasiğidir. Paketler kaybolur, TCP bunları yeniden gönderir, hız düşer. Mobil ağlar ayrıca operatörün ara ekipmanının NAT zaman aşımları yoluyla uzun süre boş kalan bağlantıları koparmaya eğilimlidir: sessizliğin ortasında, taraflardan biri operatörün çoktan unuttuğu bağlantı üzerinden alışverişi yeniden başlatmaya çalıştığında aniden RST gelir. Eylem: makul keep-alive ve zaman aşımları, uygulama seviyesinde yeniden denemeler ayarlayın, uzun süre boş kalan bağlantılar tutmayın.
Proxy hiç erişilemez
Tablo: istemci proxy'nin IP ve portuna SYN gönderiyor, ama SYN-ACK almıyor. Ya sessizlik ve SYN retransmissionları ya da anında RST. Sessizlikse - sizinle proxy arasında bir şey paketleri filtreliyor veya proxy dinlemiyor. Anında RST ise - o portta kimse yanıt vermiyor. Eylem: proxy adresini ve portunu, ağ erişilebilirliğini, yapılandırmanın doğruluğunu kontrol edin.
Yavaş istemci: zero window
Tablo: alışveriş sürüyor, ama periyodik olarak istemci zero window bildiriyor, gönderici duraklıyor, ardından window update akışı yeniden başlatıyor. Bu sık tekrarlanıyorsa, uygulamanız sunucunun verdiğinden daha yavaş soketten okuyor. Eylem: yanıt işlemeyi optimize edin, akışı ayrı bir iş parçacığında okuyun, tamponları artırın.
Döküm alırken ve okurken tipik hatalar
Deneyim, alınan darbelerin koleksiyonudur. Bunları tekrarlamamanız için en sık yapılan hataları toplayalım.
- Dökümü yanlış yerde almak. Proxy-sunucu segmentindeki kopmayı arıyorsunuz, ama dökümü istemcide aldınız, oysa bu segment hiç görünmüyor. Her zaman hangi segmente ihtiyacınız olduğunu düşünün ve dökümü doğru noktada alın.
- Her şeyi yakalamak. Yüklü bir sunucuda filtre olmadan gigabaytlar elde eder ve içinde boğulursunuz. Baştan host ve porta göre filtreleyin.
- Veri gereken yerde kesik snaplen. İçeriği görmek istiyorsanız ama kısa snaplen ayarladıysanız, yük kesilecek ve Follow Stream parçalar gösterecek.
- İsim çözümlemesi açık. -n bayrağını unuttunuz ve tcpdump DNS'te yavaşlayarak zamanlamaları bozuyor. Yakalarken her zaman -n kullanın.
- RST yönünü görmezden gelmek. RST'yi görüp kimin gönderdiğine bakmadan sonuç çıkarıyorlar. RST paketinin source IP'si - yanıtın yarısıdır.
- Normal FIN'i acil durumla karıştırmak. FIN normal kapanıştır. Panik, FIN'in kendisinden değil, beklenen veri sonundan önce gelen FIN'den kaynaklanmalıdır.
- Saat dilimlerini ve tam zamanı unutmak. Uygulama logları ve döküm zaman açısından senkronize olmalıdır, aksi halde doğru anı bulamazsınız. NTP'yi düzenli tutun.
- SSLKEYLOGFILE dosyasını saklamak. Hata ayıklamadan sonra silinmelidir. Bu, oturumlarınızın içeriğini açığa çıkaran bir sırdır.
- Tek bir bağlantıdan sonuç çıkarmak. Aralıklı sorunlar istatistik gerektirir. Tek bir düşen istek tesadüf olabilir, onlarcasının kalıbı ise teşhistir.
Mühendisin araçları ve kaynakları
Proxy trafiğiyle çalışırken elinizin altında olması gereken cephaneliği toplayalım.
Yakalama
- tcpdump - sunucularda ve konsolda ana yakalama aracı. Hafif, her zaman mevcut, esnek filtre.
- dumpcap - Wireshark paketindeki konsol aracı, özellikle rotasyonlu verimli yakalama için tasarlanmış.
- tshark - konsol Wireshark. Grafik olmadan görüntüleme filtreleri uygulamanıza izin verir, betikler ve uzak sunucular için kullanışlıdır.
Analiz
- Wireshark - grafik analizör, yüzlerce protokolün çözücüsü, güçlü filtre sistemi, Follow Stream, bağlantı istatistikleri.
- Wireshark Uzman Bilgisi - retransmission, sıfırlama, zero window gibi anormallikleri vurgulayan yerleşik panel. Soruşturmaya tam da ondan başlayın.
- Konuşma istatistikleri - dökümdeki tüm TCP bağlantılarının bayt ve süre ile tablosu. Hangi bağlantının anormal derecede kısa olduğunu hızlıca gösterir.
Faydalı komut satırı teknikleri
tshark ile görüntüleme filtresiyle pcap içeriğini konsolda hızlıca inceleyin:
tshark -r dump.pcap -Y "tcp.flags.reset == 1"Dosyadan yalnızca CONNECT isteklerini çıkarın:
tshark -r dump.pcap -Y "http.request.method == \"CONNECT\""Tüm retransmissionları görün:
tshark -r dump.pcap -Y "tcp.analysis.retransmission"Bu komutlar grafik olmadığında ve ssh üzerinden hemen çözmeniz gerektiğinde paha biçilmezdir.
Vakalar ve uygulama sonuçları
Hiçbir şey canlı hikayelerden daha iyi ikna etmez. Proxy trafiği teşhisinin gerçek mühendislik pratiğini yansıtan derleme vakalar sunacağım.
Vaka 1: isteklerin yüzde beşi gece düşüyor
Entegrasyon ekibi şikayet ediyordu: proxy üzerinden harici API'ye yapılan isteklerin yaklaşık yüzde beşi kesilmiş yanıtla düşüyordu, çoğunlukla gece. Uygulama logları eksik içerik gösteriyordu. Proxy logları - hatasız kurulmuş tüneller.
İstemcide birkaç saat boyunca halka rotasyonlu döküm ve logdan tam hata işaretçisi aldık. Olay anında gördük: tünel kuruldu, TLS çalıştı, yanıt gövdesinin bir kısmı geldi, ardından proxy'den FIN. SSLKEYLOGFILE ile kendi trafiğimizin şifresini çözmek şunu gösterdi: gövde boyutunu belirten doğru HTTP başlığı geliyordu, ama gövde ortada kesiliyordu. Sonuç: hedef sunucu, büyük gece raporlarının üretiminde kendi zaman aşımıyla bağlantıyı kapatıyordu. Entegrasyon tarafındaki çözüm - verileri daha küçük yığınlarla sayfa sayfa istemek oldu. Sorun tamamen ortadan kalktı.
Vaka 2: gizemli anlık RST
Başka bir mühendis, belirli bir host için CONNECT gönderdikten hemen sonra anlık sıfırlama alıyordu, diğer hostlarda ise her şey çalışıyordu. İlk şüphe proxy'ye düşüyordu.
İstemcideki döküm şunu gösterdi: CONNECT gitti ve neredeyse anında proxy'nin IP'sinden RST döndü. Ama anlıklık düşündürücüydü - genellikle sunucu erişilemezliği zaman aşımı verir, anlık sıfırlama değil. Proxy tarafında döküm aldık ve Segment B'yi gördük: proxy hedef hosta istenen porttan bağlantı açıyordu, hedef sunucu da SYN'e RST ile yanıt veriyordu - port kapalıydı. Proxy bu reddi dürüstçe istemciye iletmişti. Meğer hedef servis yakın zamanda portu değiştirmiş. Sonuç: anlık RST çoğunlukla kapalı porttur, proxy sorunu değil. Doğru port çalışmayı geri getirdi.
Vaka 3: mobil segmentte bozulma
Proxy üzerinden çalışan mobil cihazlardaki uygulama, kullanıcıların bir kısmında düzenli olarak bağlantı kaybediyordu. Sorunlu kapsama alanındaki cihazdan alınan döküm klasik tabloyu gösterdi: retransmission dizileri, yinelenen ACK'ler, artan aralıklar ve sonunda uzun bir boşluktan sonra RST - operatördeki NAT zaman aşımının sonucu.
Sonuç: ağ, ne proxy ne de sunucu. Çözüm - uygulama seviyesinde uyarlanabilir yeniden denemeler, makul keep-alive ve bağlantıyı yeniden kurma ile kopmaların zarif işlenmesi tanıtıldı. Kullanıcıya görünen hata sayısı kat kat azaldı, radyo kanalı aynı kalsa bile. Paket dökümü, proxy ve sunucu hakkında yanlış hipotezlere zaman harcamayı önledi ve gerçek nedene odaklanmayı sağladı.
Vakalardan çıkan genel içgörü
Her üç hikayede de döküm, haftalarca yazışma ve ekipler arası karşılıklı suçlamayı önledi. Paketler yalan söylemez. Masaya RST'nin yönünü, ServerHello'nun varlığını veya yokluğunu ve retransmission tablosunu gösteren bir döküm geldiğinde, suçlu tartışması dakikalar içinde sona erer. Yöntemin esas değeri de budur: teşhisi görüş düzleminden gerçekler düzlemine taşır.
Desteğe başvurmak için döküm alma kontrol listesi
Desteğe başvurduğunuzda - ister proxy sağlayıcısı Proxeon'a, ister hedef API'nin sahibine - doğru alınmış bir döküm çözümü kat kat hızlandırır. İşte başvurudan önce yapılması gereken bir kontrol listesi.
Yakalamadan önce
- Teşhisin kesin başlangıç zamanını kaydedin ve ilgili tüm makinelerde saatleri NTP ile senkronize edin.
- Yakalama noktalarını belirleyin: en azından istemcide, mümkünse erişiminiz olan tarafta.
- Girdileri toplayın: proxy'nin IP ve portu, hedef hostun adı ve portu, beklenen ve gerçek davranış.
Yakalama sırasında
- tcpdump'ı proxy hostu ve hedef port filtresiyle, tam snaplen ve rotasyonla başlatın:
tcpdump -i eth0 -n -s 0 "host 203.0.113.10 and port 8080" -w support-%Y%m%d-%H%M%S.pcap -C 100 -W 10 - Sorunu yeniden üretin ve uygulama logundan milisaniyeli kesin olay zamanını kaydedin.
- Aynı aralık için uygulama loglarını da paralel olarak kaydetmeyi unutmayın.
Başvuruya eklenmesi gerekenler
- Gigabaytlar göndermemek için ilgili zaman aralığına kesilmiş pcap dosyasının kendisi.
- Olayın kesin zaman damgaları ve saat dilimi.
- Proxy'nin IP ve portu, hedef hostun adı ve portu, senaryo açıklaması.
- Hata ile birlikte uygulama loglarından bir kesit.
- Ön analiziniz: RST veya FIN'i kimin gönderdiği, ServerHello olup olmadığı, retransmission gözlemlenip gözlemlenmediği. Bu, ev ödevinizi yaptığınızı gösterir.
pcap'ı istenen aralığa nasıl kırparsınız
Devasa bir dosyayı tshark veya editcap ile zamana göre kırpabilirsiniz. Paket numarasına veya filtreye göre kesme örneği:
tshark -r big.pcap -Y "frame.time >= \"2026-01-01 03:00:00\" && frame.time <= \"2026-01-01 03:05:00\"" -w small.pcapBu şekilde düzenli ve odaklanmış bir dökümü destek hızlı işler, çünkü samanlıkta iğne araması gerekmeyecektir.
SSS: proxy üzerinden dökümlerle ilgili sık sorulan sorular
Proxy üzerinden HTTPS trafiğinin dökümünde neden yalnızca CONNECT ve ardından okunamaz bir şey görüyorum?
Çünkü tünel kurulduktan sonra proxy, anahtarlarına sahip olmadığı şifrelenmiş TLS baytlarını yalnızca iletir. Açık metin olarak yalnızca host adını içeren CONNECT komutu ve proxy'nin kurulum yanıtı gider. Geri kalan her şey şifreleme ile korunur - ve HTTPS'in var olma sebebi tam da budur. Kendi trafiğinizin içeriğini görmek için SSLKEYLOGFILE kullanın.
Bağlantıyı proxy'nin değil, hedef sunucunun kestiğini nasıl anlarım?
RST veya FIN paketinin source IP'sine bakın. Ama iki segmenti unutmayın: istemciden alınan dökümde yalnızca proxy'nin IP'sini görürsünüz, çünkü sunucuyla doğrudan iletişim kurmuyorsunuz. Kopmayı kesin olarak hedef sunucuya atfetmek için, proxy-sunucu segmentinin görüldüğü proxy tarafında döküm gerekir. Segment B'de RST sunucunun IP'sinden geliyorsa - onu kesmiştir.
Teşhis anlamında retransmission ile RST arasındaki fark nedir?
Retransmission, onaylanmamış bir segmentin yeniden gönderilmesidir; kanaldaki paket kaybının belirtisidir, ama bağlantı hâlâ canlı ve savaşıyor. RST ise bir sonlandırmadır, bağlantıyı unutma emridir. RST'ye dönüşen bir retransmission fırtınası şöyle okunur: kanal paket kaybediyordu, taraf beklemekten yoruldu ve bağlantıyı kesti. Tekil retransmissionlar internetin normalidir.
Zero window ne anlama gelir ve proxy suçlu mudur?
Zero window, alım tamponu uygulama tarafından doldurulduğu için alıcının bildirdiği durumdur, çünkü uygulama yavaş okuyordur...
