Port Nedir? TCP ve UDP Farkı, Bağlantı Arızası Tespiti

Bir sunucunun portuna bağlanamadığınızda elinizde genellikle tek bir veri olur: bekleyip zaman aşımına düşen bir ekran. O ekran size sorunun var olduğunu söyler, nerede olduğunu söylemez. Sonrasında başlayan yazışma da hemen hemen her zaman aynı yere varır: “bizde bir sorun görünmüyor, sizde olmalı.”

Bu makale o tartışmayı bitiren şeyi anlatıyor. Önce portun ne olduğunu, üç aralığa neden bölündüğünü ve TCP ile UDP’nin gerçekte neyi farklı yaptığını kuruyoruz. Sonra elimizi kirletiyoruz: aynı bağlantı denemesini beş farklı güvenlik duvarı kuralı altında ölçüp, kronometrenin neyi gösterip neyi gizlediğini yan yana koyuyoruz. Bu makale Kurumsal Network Kurulumu hizmetimizin arıza tespiti tarafına odaklanıyor ve ağ protokolleri yazımızdaki port tablosunun altını dolduruyor.

Baştan söyleyelim: buradaki bütün ölçümler kendi laboratuvarımızda alındı, çıktılar gerçek. Yöntemin kendisi de masa başında doğmadı; farklı kurumların sistem ekipleriyle aynı çıkmazı yeterince yaşadıktan sonra, onu aşmanın tek yolu olarak yerleşti.

Acelesi olan için iki kısayol: kendi sunucunuzda hangi portların dinleme yaptığını görmek istiyorsanız oradan, bir bağlantının neden kurulmadığını arıyorsanız doğrudan arıza tespiti bölümünden başlayabilirsiniz.

Port Nedir? Tek Adreste Onlarca Kapı

Port numarası, aynı IP adresine gelen trafiğin hangi servise ait olduğunu ayıran 16 bitlik bir sayıdır ve 0 ile 65535 arasında değer alır. IP adresi paketi doğru makineye götürür, port numarası o makinenin içinde doğru programa teslim eder.

Büyük bir yemek katını düşünün. Binanın tek bir adresi vardır, kapıdan girersiniz ve içeride numaralı tezgahlar sıralanır. Adres sizi binaya getirir; ama pideyi 3 numaralı tezgahtan, kahveyi 7 numaralı tezgahtan alırsınız. Yanlış numaraya gittiğinizde bina yanlış değildir, tezgah yanlıştır. Port numarası tam olarak bu numaradır.

Mekanizması şöyle işler: paket makineye ulaştığında işletim sisteminin çekirdeği başlıktaki hedef port numarasına bakar, o numarayı dinleyen bir soket var mı diye kontrol eder ve varsa paketi o sokete verir. Yoksa paket uygulamaya hiç ulaşmaz; ne olacağı da bu makalenin ikinci yarısının konusu.

Burada çoğu anlatımın atladığı bir ayrıntı var ve ilerideki bütün ölçümleri okumanız buna bağlı: bir bağlantıda iki port vardır, bir değil. Sunucunun dinlediği hedef port sabittir (22, 443), ama istemci de kendine geçici bir kaynak portu seçer. Bir bağlantıyı benzersiz kılan şey şu beşlidir:

• taşıma protokolü (TCP ya da UDP)
• kaynak IP adresi
• kaynak port
• hedef IP adresi
• hedef port

Listedeki ilk madde çoğu anlatımda unutulur ama gereklidir: TCP 443 ile UDP 443 aynı port numarası olsa da iki ayrı bağlantıdır, işletim sistemi bunları karıştırmaz. Bu ayrımın pratik sonucunu makalenin ilerleyen bölümünde göreceksiniz.

Aynı sunucunun 443 portuna aynı anda yüzlerce kişi bağlanabilmesinin sebebi de bu beşlidir: hedef taraf herkeste aynıdır, kaynak port herkeste farklıdır. Bir tezgaha aynı anda birçok kişi sipariş verebilir, çünkü siparişleri ayıran şey tezgahın numarası değil, siparişi verenin kim olduğudur.

Beşlideki iki adresin kendisi bu makalenin kapsamı dışında: adresin hangi kısmının ağı, hangi kısmının cihazı gösterdiğini ve subnet maskesinin bu sınırı nasıl çizdiğini IP adresi rehberimizde bulabilirsiniz.

Beşli Bir Bağlantıyı Tanımlar, Bir Kişiyi Değil

Buradaki ayrım hem teşhis hem hukuk açısından belirleyici: bu beşli bir bağlantıyı o an benzersiz kılar, ama kimin yaptığını söylemez. Aynı beşli iki saat sonra bambaşka bir oturuma ait olabilir, çünkü kaynak portu işletim sistemi bağlantı bitince havuza geri alır ve yeniden dağıtır.

Kimlik sorusunun cevabı bu yüzden başka katmanlarda durur:

1. Zaman. Bir kaydı geriye dönük anlamlı kılan tek şey zaman damgasıdır. Zamansız bir bağlantı kaydı, hangi oturuma ait olduğu belirsiz olduğu için delil değeri taşımaz.
2. NAT çeviri kaydı. Dışarıya çıkan trafikte karşı tarafın gördüğü adres sizin genel adresinizdir. O anda hangi iç adrese karşılık geldiği yalnız çeviriyi yapan cihazın kaydında durur. O kaydın içinde tam olarak ne yazdığını ve beşlinin hangi iki alanının değiştiğini çeviri tablosunu açtığımız rehberde gerçek çıktıyla gösteriyoruz.
3. MAC adresi ve DHCP kirası. MAC, bağlantının beşlisinin parçası değildir: ikinci katmanda yaşar ve her yönlendirici geçişinde değişir, yani uçtan uca taşınmaz. Ama “o iç IP o saatte hangi fiziksel cihazdaydı” sorusunun cevabı DHCP kira kaydındadır ve orası MAC adresini tutar. Bu iki adresin neden ayrı yaşadığı ve aralarındaki çeviriyi hangi protokolün yaptığı MAC adresi ve ARP rehberimizde ele alınıyor.

Üçünü birleştirdiğinizde zincir tamamlanır: fiziksel cihaz → iç adres → çeviri → dış adres ve port → zaman. Halkalardan biri eksikse zincir kopar ve elde kalan kayıt “var ama işe yaramaz” durumuna düşer.

Kaynak portu şimdilik aklınızın bir kenarına yazın. Birazdan bir arızanın kaç kez denendiğini de, o denemelerin tek bir bağlantıya mı ait olduğunu da o sayıdan okuyacağız.

Üç Port Aralığı ve Neden Bölündüler?

Port numaraları rastgele dağıtılmaz, üç aralığa ayrılır ve bu ayrım bir yetki sınırı taşır.

İlk aralığın özel bir kuralı var: Linux ve benzeri sistemlerde 1024ün altındaki bir portu dinlemek için yönetici yetkisi gerekir. Bu tek satırlık kısıt, ilk bakışta bürokratik bir ayrıntı gibi durur. Değildir.

Neden var olduğunu görmek için olmadığını hayal edin. Ortak kullanılan bir sunucuda sıradan bir kullanıcı hesabı, 443 portunu dinleyen kendi programını başlatabilseydi, o makineye HTTPS için gelen herkes o programa düşerdi. Kullanıcı adı ve parola isteyen bir sayfa göstermek için ek bir yetkiye ihtiyaç kalmazdı. Ayrıcalıklı aralık, “bu makinede standart servisi ancak makineyi yöneten kişi ilan edebilir” demenin teknik yoludur.

Üçüncü aralık ise sessizce çalışan taraftır. Bir tarayıcı açtığınızda, bir SSH oturumu başlattığınızda, işletim sisteminiz size o bağlantıya özel bir kaynak portu verir ve bağlantı bitince geri alır. Birazdan göreceğiniz yakalamalarda 54799, 60360, 41216 gibi sayılar geçecek; hepsi bu aralıktan, hepsi tek bir bağlantı için ayrılmış geçici numaralar.

Bu aralığı yalnız istemcilerin kullandığını sanmak kolaydır, ama bir karşı örnek var: TFTP’de sunucu da cevabını geçici bir porttan döner. İstek 69’a gider, yanıt bambaşka bir numaradan gelir ve aktarımın geri kalanı orada yürür. Durum tabanlı güvenlik duvarlarının TFTP’yi kırmasının sebebi tam olarak budur; ölçülmüş hâli TFTP makalemizde duruyor.

1024 Sınırı Nereden Geliyor?

Bu sayı yuvarlak olduğu için seçilmiş gibi durur, ama arkasında somut bir güvenlik tasarımı var ve bugün bakınca öğretici olan da o tasarımın hangi varsayıma dayandığı.

Ayrıcalıklı port kavramı 1980’lerin başında BSD Unix ile geldi (IPPORT_RESERVED). Sebebi dönemin uzaktan erişim komutlarıydı: rlogin ve rsh. Bu araçlar karşıdaki kullanıcının kim olduğunu parolayla değil, bağlantının geldiği port numarasıyla doğruluyordu. Mantık şuydu: bağlantı 1024ün altındaki bir porttan geliyorsa, o portu ancak root yetkisiyle çalışan bir program açabilmiştir; öyleyse karşı taraftaki makinenin yöneticisi bu bağlantıya kefildir ve “ben şu kullanıcıyım” beyanına güvenilebilir. Sıradan bir kullanıcı ayrıcalıklı portu kullanamadığı için başkasının kimliğine bürünemezdi.

Bu varsayım sayesinde rlogin bazı yapılandırmalarda parola hiç sormadan kabuk açabiliyordu. Bugün bu cümle tüyler ürpertici geliyor, ama o dönemin ağı bir üniversite binasının içiydi: her makine güvenilir, root yetkisi az sayıda kişide, dışarıdan bağlanan yok. BSD ekibi de bunun temiz bir çözüm değil, işe yarayan bir kestirme olduğunu biliyordu.

O varsayım çöktüğünde geriye kalan kısıt bugün hâlâ yürürlükte. Aynı çöküş, aynı yıllarda doğan Telnet’in neden terk edildiğinin de cevabıdır: ikisi de ağın kendisinin güvenli olduğunu varsayıyordu.

Numaraların nasıl dağıtıldığına dair en güzel örnek ise 22’dir. Tatu Ylönen 1995’te SSH’ı yazdığında, yerine geçmeyi hedeflediği iki protokolün arasındaki boşluğu istedi: FTP 21, Telnet 23. IANA’ya bir e-posta yazdı ve ertesi gün cevabı aldı. Yani bugün milyonlarca sunucuda dinleyen o numaranın teknik bir anlamı yok; sadece iki komşusunun arasındaki boş sıraydı.

O iki komşudan ilki, kayıtlı bir numaranın her zaman yetmediğinin de örneğidir: FTP 21’i komut için kullanır ama dosyayı ayrı ve önceden belli olmayan bir porttan taşır, ve firewall kuralı yazarken asıl zorluk buradan doğar. Dosya aktarım protokollerini ele aldığımız rehberde bu ikinci kanalın nasıl seçildiğini ve engellendiğinde arızanın neye benzediğini ölçümlerle gösteriyoruz.

Açık Port Kontrolü: Kendi Makinenizde Hangi Portlar Dinleme Yapıyor?

Aralıkları öğrendiniz; sıradaki soru kendi sunucunuzda o aralıklardan hangilerinin fiilen kullanıldığı. Cevabı tek komut, ve sonucu okumak komutu çalıştırmaktan daha önemli.

Linux’ta dinleyen portları listelemek için:

ss -tuln

Windows tarafında iki yol var, ikisi de aynı bilgiyi verir:

Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess

netstat -an | findstr LISTENING

Çıktıda asıl bakılacak yer port numarası değil, onun solundaki adres. Üç ihtimal var ve üçü üç ayrı anlam taşır:

1. 0.0.0.0 veya [::]: servis makinenin bütün ağ arayüzlerinde dinliyor. Ağ üzerinden erişime aday olan tek durum budur.
2. 127.0.0.1 veya ::1: servis yalnızca makinenin kendisini dinliyor. Dışarıdan hiçbir şekilde erişilemez; güvenlik duvarını açsanız da değişmez, çünkü sorun güvenlik duvarında değil.
3. Belirli bir IP (192.168.1.30 gibi): servis yalnız o arayüzden geliyor.

ss -tuln çıktısının ilk sütunu ayrıca tcp mi udp mi olduğunu söyler. Bu ayrım bir sonraki bölümün konusu ve göründüğünden çok daha belirleyici.

TCP ve UDP Farkı: Garson Servisi ve Self Servis

Az önceki çıktıda her satırın başında tcp ya da udp yazıyordu. O tek kelime, servisin nasıl konuştuğunu belirler.

TCP ile UDP arasındaki fark tek cümleyle şudur: TCP karşı tarafla önce bir bağlantı kurar ve teslimatı doğrular, UDP ne bağlantı kurar ne de doğrular. Hız farkı bu tercihin sonucudur, sebebi değil.

Yemek katı benzetmesine dönelim. UDP self servistir: siparişinizi tezgaha bırakır, arkanıza bakmadan yürürsünüz. Karşı tarafta birinin olup olmadığını, siparişin duyulup duyulmadığını bilmezsiniz. Hızlıdır, çünkü hiçbir şey beklemez.

TCP ise garson servisidir. Oturursunuz, garson gelir, sipariş alınır ve her adım karşılıklı onaylanır. Karşınızda birinin olduğunu bilerek konuşursunuz.

Bu tercihin neden yapıldığını görmek için ikisini tek tek ele alalım, çünkü aradaki fark çoğu kaynakta yazdığı gibi “biri güvenilir, öteki hızlı” değil.

TCP Nedir? Geç Kalsın ama Eksiksiz Gelsin

TCP (Transmission Control Protocol), verinin eksiksiz ve doğru sırada teslim edilmesini güvence altına alan taşıma protokolüdür. Bunu üç mekanizmayla yapar: her baytı numaralar, teslim alınanı karşı tarafa onaylatır, onayı gelmeyeni yeniden gönderir.

Bu maliyete neden katlandığını bir dosya indirirken görürsünüz. Ağ yavaşladığında indirme uzar; on saniye sürecek iş kırk saniyeye çıkar. Ama dosya sonunda tam iner. Yolda kaybolan bir paket olduysa TCP onu yeniden istemiştir ve siz bunu fark etmemişsinizdir bile. Fark etmemenizin sebebi önemli: bir tablo dosyasının ortasındaki birkaç bayt eksik gelirse o dosya bozulur, açılmaz. Yani orada beklemek kabul edilebilir bir bedeldir, eksik veri değildir.

TCP’nin bütün tasarımı bu tercihin üzerine kurulu: zamanı feda eder, bütünlüğü korur.

Üçlü El Sıkışma: Onayın Matematiği

TCP’nin “onaylatma” dediği şey somut olarak şudur: bir bağlantı, veri akmaya başlamadan önce üç adımda kurulur ve bu adımların adı üçlü el sıkışmadır (three-way handshake).

1. İstemci bir SYN gönderir: “Bir oturum açmak istiyorum, sayacım şu numaradan başlıyor.”
2. Sunucu SYN-ACK ile cevaplar: “Duydum ve kabul ediyorum, benim sayacım da şu numaradan başlıyor.”
3. İstemci ACK gönderir: “Senin numaranı da aldım, başlıyoruz.”

Buradaki “sayaç” bir benzetme değil, paketin içinde gerçekten duran bir alan: adı sıra numarası (sequence number). İki özelliği bu makalenin geri kalanını okumanızı kolaylaştırır. Birincisi, TCP paketleri değil baytları numaralandırır; sayıların bu kadar büyük görünmesinin sebebi budur. İkincisi, sayaç sıfırdan başlamaz: her bağlantı kendine rastgele bir başlangıç numarası seçer. Böylece hem eski bir bağlantıdan gecikmiş bir paket yeni oturuma karışamaz, hem de dışarıdan biri numarayı tahmin edip araya paket sokamaz.

Bu ayrıntıyı şimdi vermemizin pratik bir sebebi var: ilerideki kanıtların çoğu bu sayıya bakıyor. İki ayrı yakalamada aynı sıra numarasını görmek, “bu iki kayıt aynı pakete ait” demenin en kesin yoludur; makalenin sonunda iki kurum arasındaki tartışmayı bitiren şey de tam olarak bu olacak.

Üçüncü adım tamamlanana kadar hiçbir veri gitmez. Laboratuvarımızda bu üç adım şöyle görünüyor, iki makine arasında alınmış gerçek bir yakalama:

IP 192.168.1.30.41216 > 192.168.1.15.9999: Flags [S], seq 3290926036
IP 192.168.1.15.9999 > 192.168.1.30.41216: Flags [S.], seq 2464608652, ack 3290926037
IP 192.168.1.30.41216 > 192.168.1.15.9999: Flags [.], ack 1

Bu dökümde bakılacak üç şey var:

1. Flags alanı el sıkışmanın hangi adımında olduğunuzu söyler. [S] sadece SYN, [S.] SYN-ACK (nokta ACK bayrağını gösterir), [.] yalnız ACK demektir.
2. seq numaraları iki taraftan bağımsız başlar. İstemci 3290926036 diyor, sunucu kendi sayacını 2464608652den açıyor. Her yön kendi sayacını tutar.
3. ack 3290926037, istemcinin numarasının bir fazlasıdır. Bu “senin şu numarana kadar her şeyi aldım, sıradaki beklediğim bu” demektir. Onayın matematiği budur: TCP her baytı numaralar, karşı taraf da hangi numaraya kadar geldiğini bildirir.

Sunucunun cevabı 37 mikrosaniyede geldi. Bu sayı ileride işimize yarayacak, çünkü çalışan bir bağlantının ne kadar hızlı kurulduğunu bilmek, kurulmayan bir bağlantıyı yorumlamanın ön şartı.

Analoji burada bir yerde yalan söylüyor, söyleyelim: garson siparişi unutabilir ama masaya geri gelip “ne söylemiştiniz” diye sorar. TCP’de kaybolan paket ise kimseye sorulmaz; gönderen taraf onayın gelmediğini fark edip aynı paketi yeniden yollar. Fark önemli, çünkü birazdan bir arızada aynı paketin beş kez gittiğini göreceğiz ve bu bir hata değil, TCP’nin tasarımı gereği yaptığı iş olacak.

UDP Nedir? Geç Gelen Zaten İşe Yaramaz

Az önce gördüğünüz üç adımlı kurulum, UDP’de hiç yaşanmaz. UDP (User Datagram Protocol), veriyi bağlantı kurmadan ve teslimatı doğrulamadan gönderen taşıma protokolüdür. Kaybolan paketi yeniden göndermez, sıraya da sokmaz.

İlk bakışta bu bir eksiklik gibi görünür. Değildir, ve sebebini muhtemelen bu hafta yaşadınız: bir online toplantıda karşı tarafın sesi bir an kesilir, bir hece kaybolur. O hecenin ses paketi ağda kayboldu. Şimdi TCP mantığının orada ne yapacağını düşünün: paket yeniden istenir, istek gider, kopya geri gelir, aradan yarım saniye geçer. Ama o yarım saniyede konuşma devam etmiştir. Geri gelen ses paketinin çalınacağı an çoktan geçmiştir; artık hiçbir işe yaramaz.

Fark tam burada netleşiyor: indirilen bir dosyadan kaybolan bayt hâlâ değerlidir, kaybolan bir ses paketi değildir.

Bu yüzden UDP’nin yeniden göndermemesi bir zaaf değil, doğru karardır. Kaybı telafi etmeye çalışmak sesli görüşmeyi düzeltmez, bozar: konuşma her kayıpta durup beklemek zorunda kalır.

Buradan iki protokol arasındaki farkın en kısa hâli çıkıyor ve akılda kalması gereken cümle bu: soru “hangisi güvenilir” değil, “bu veri geç gelirse hâlâ işe yarar mı”. Cevap evetse TCP, hayırsa UDP.

Bu ayrımın doğrudan bir pratik sonucu var. Zamana bağlı trafiğin (ses, video konferans) sınırlı bir hatta öncelikli taşınması ayrı bir mühendislik konusudur ve switch ve router yapılandırmasındaki QoS bölümünde ele alınır. UDP kaybı telafi etmediği için, o trafiğin korunması protokolün değil ağın işidir. Hattı büyütmek yerine önceliklendirerek çözdüğümüz gerçek bir vakayı QoS ve video konferans optimizasyonu çalışmamızda anlatıyoruz.

Üçüncüsü Var mı? QUIC ve UDP’nin Üstüne Kurulan Güvenilirlik

TCP ile UDP’yi yan yana koyunca akla gelen ilk soru şu oluyor: arada bir yer yok mu, illa birini seçmek zorunda mıyız? Var, ve bu sayfayı okurken büyük ihtimalle kullanıyorsunuz. Adı QUIC ve bir port değil, üçüncü bir taşıma protokolü.

QUIC’i anlamanın en kısa yolu şu cümle: UDP’nin telafi etmemesi, üstünde çalışan bir protokolün telafi edemeyeceği anlamına gelmez. QUIC, UDP datagramlarının üzerine kendi kayıp yönetimini kuruyor. Yani UDP’nin hızını alıyor, güvenilirliği ise kendisi ekliyor.

Üstelik bunu TCP’den daha iyi yapıyor. TCP tek bir sıra tutar: bir paket kaybolduğunda arkasındaki her şey, ilgisiz olsa bile, o paket gelene kadar bekler. QUIC kayıp yönetimini her akış için ayrı yürütür, dolayısıyla kaybolan paket yalnız kendi akışını bekletir, komşularına dokunmaz.

Buradan çıkan ayrım ince ama bu makalenin en çok yanlış bilinen cümlesini düzeltiyor: “UDP güvenilmezdir” ifadesi protokolün kendisi için doğrudur, üzerine inşa edilen her şey için değil.

Kurumsal ağda görünen yüzü ise doğrudan bu makalenin konusu. QUIC, 443 numaralı UDP portunu kullanır ve birçok kurum dışarı çıkışta TCP 443’e izin verirken UDP 443’ü kapalı tutar. Bu çoğu zaman bir ihmal değil, bilinçli bir güvenlik kararıdır. Kurumsal güvenlik ürünleri QUIC’i engellemeyi açıkça önerir, çünkü UDP üzerindeki şifreli taşıma vekil sunucuyla denetlenemez: içerik filtreleme, kategori politikaları ve veri sızıntısı önleme QUIC devredeyken uygulanamaz hale gelir. Yani kurum, kendi koyduğu kuralın delindiğini göremez. Trafiği kapatmak burada bir eksiklik değil, görünürlüğü korumak için ödenen bedeldir.

Ama kapatma kararı ile arızanın teşhisi çoğu zaman aynı masada oturmaz, ve makalenin baştan beri anlattığı sorun tam da burada tekrar eder. Kapalı olduğunda ortada bir arıza görünmez: tarayıcı sessizce eski sürüme düşer, her şey çalışmaya devam eder, geriye yalnızca açıklanamayan bir yavaşlık kalır ve hata mesajı yoktur. Politikayı koyan güvenlik ekibi bunu bilir; yavaşlığı araştıran kişi çoğu zaman bilmez. Kendi ağınızda hangi sürümün kullanıldığını merak ediyorsanız, güvenlik duvarı kurallarında UDP 443’ün durumuna bakmak iyi bir başlangıçtır.

QUIC’in nasıl doğduğu, el sıkışmayı nasıl birleştirdiği ve HTTP/3’ün neden TCP’yi bıraktığı ayrı bir hikâye; onu HTTP ve HTTPS yazımızın HTTP/3 bölümünde anlatıyoruz.

Hangi Protokol Neden TCP veya UDP Seçer?

Mekanizmayı gördüğünüze göre, protokollerin bu ikisi arasındaki tercihi de artık keyfî görünmeyecek; o tercih, protokolün hayatın hangi anında devreye girdiğini ele verir.

DHCP neden UDP kullanır? Çünkü DHCP konuştuğu anda istemcinin henüz bir IP adresi yoktur. TCP el sıkışması için karşılıklı adres gerekir; adresi olmayan bir cihaz üçlü el sıkışmayı başlatamaz. DHCP’nin görevi zaten o adresi almaktır, yani kendi ön koşulunu sağlayamayacağı bir taşıma protokolünü seçemez.

DNS neden çoğunlukla UDP, bazen TCP kullanır? Tipik bir DNS sorusu ve cevabı tek pakete sığar. Böyle bir alışverişte üçlü el sıkışma kurup kapatmak, taşınan veriden daha fazla trafik üretir. Ama cevap büyüdüğünde (bölge transferi, uzun kayıt kümeleri) tek paket yetmez ve DNS TCP’ye geçer.

NTP neden UDP kullanır? Zaman senkronizasyonunda ölçülen şey gecikmenin kendisidir. Araya bağlantı kurulumu ve yeniden gönderim mantığı girerse, ölçülen gecikme protokolün kendi katkısını da taşır.

Aynı mantık listenin tamamı için geçerlidir: LDAP dizin sorgusu güvenilir ve sıralı bir kanal ister, TCP kullanır; SNMP’nin durum bildirimi tek atımlıktır, UDP kullanır. Hangi protokolün hangi portta ve hangi taşıma katmanında çalıştığını tek tabloda görmek isterseniz, protokol ve port eşleşmelerinin toplu listesi orada duruyor.

Buraya kadar her şey doğru yapılandırılmış bir dünyayı anlattı. Şimdi işin asıl kısmına geliyoruz: doğru port, doğru protokol ve çalışan bir servise rağmen bağlantı kurulmadığında ne oluyor?

Bağlantı Kurulmadığında Ne Oluyor? Üç Farklı Sessizlik

Bir bağlantı denemesinin başarısızlığı tek tip değildir. Karşı taraftaki güvenlik duvarının yapılandırmasına göre en az üç ayrı şey olur ve üçü de kullanıcıya “olmadı” diye görünür.

Bunu kendi makinenizde bir dakikada tekrarlayabilirsiniz, lab kurmanıza gerek yok. Deneyi anlamlı kılan şey hedefin ve iki portun bilinçli seçilmiş olması, o yüzden önce onu açalım.

Hedef 8.8.8.8: Google’ın herkese açık DNS hizmetinin adresi. Tek bir makine değil, dünyanın dört bir yanına dağılmış bir sunucu kümesi; 8.8.8.8 o kümenin kapı numarası. Seçme sebebimiz basit: internete bağlı herkes oraya erişebiliyor, yani sonucu siz de aynen tekrarlayabilirsiniz.

Önce Kapalı Olması Gereken Kapıyı Çalalım: Port 22

Port 22 SSH’a ait ve bir yönetim kapısıdır. Bir sunucuya bu porttan giren kişi komut satırına düşer: yapılandırmayı değiştirir, servisi durdurur, kullanıcı ekler. Yani şimdi yapacağımız şey, dışarıdan bir yabancının Google’ın sunucusunda yönetici olarak oturum açmayı denemesine benziyor. Hiçbir kurumun bu kapıyı internete açık bırakmayacağını baştan biliyoruz; deneyin amacı da zaten kapalı bir kapının nasıl göründüğünü kaydetmek.

Test-NetConnection 8.8.8.8 -Port 22

WARNING: TCP connect to (8.8.8.8 : 22) failed

ComputerName           : 8.8.8.8
RemoteAddress          : 8.8.8.8
RemotePort             : 22
InterfaceAlias         : Wi-Fi
SourceAddress          : 192.168.1.115
PingSucceeded          : True
PingReplyDetails (RTT) : 12 ms
TcpTestSucceeded       : False

Beklediğimiz oldu: TcpTestSucceeded : False. Ama asıl öğretici olan başarısızlık değil, onun yanındaki satır.

PingSucceeded : True ile TcpTestSucceeded : False aynı çıktıda yan yana duruyor. Bu ikisi çelişmiyor, farklı şeyler söylüyorlar: makine ayakta ve size cevap veriyor (ping 12 ms’de döndü, yani paket gidip geldi), ama istediğiniz kapı size kapalı. Sahada en sık duyulan cümlelerden birinin, “ping atıyorum, sunucu çalışıyor” cümlesinin neden hiçbir şey kanıtlamadığı tam olarak budur: ping makineye ulaşır, servise değil.

Bir de ekranda görünmeyen bir şey var: bu komut cevabını hemen vermedi, yaklaşık 22 saniye bekletti. O bekleme sonraki bölümlerin konusu olacak.

Şimdi Açık Olması Gereken Kapıya Bakalım: Port 53

Port 53 DNS’e ait ve bu sunucunun var oluş sebebi. Google bu adresi dünyaya bir DNS hizmeti olarak sunuyor; 53 kapalı olsa ortada hizmet diye bir şey kalmaz. Yani az önceki kapının aksine, bu kapının herkese açık olması zorunlu. Aynı komutu, aynı adrese, yalnız port numarasını değiştirerek çalıştırıyoruz.

Test-NetConnection 8.8.8.8 -Port 53

ComputerName     : 8.8.8.8
RemoteAddress    : 8.8.8.8
RemotePort       : 53
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.1.115
TcpTestSucceeded : True

Bu sefer TcpTestSucceeded : True ve cevap göz açıp kapayana kadar geldi.

İki çıktıyı yan yana koyduğunuzda üç şey netleşiyor:

1. Aynı makine, iki farklı cevap. Adres değişmedi, mesafe değişmedi, tek değişen port numarası oldu. Yani sonucu belirleyen şey sunucunun nerede olduğu değil, o kapıda ne yapılmasına izin verildiği.
2. Süre farkı bin katın üzerinde. 53 anında döndü, 22 yaklaşık 22 saniye bekletti. Bir kapının kapalı olması yalnız “hayır” demek değil; ne kadar sürede hayır dediği de bir bilgi, ve makalenin geri kalanı büyük ölçüde bunun üstüne kurulu.
3. Başarılı testte PingSucceeded satırı hiç yok. Test-NetConnection bağlantıyı kurabildiğinde ping ayrıntısını yazdırmıyor, çünkü artık gereksiz: bağlantı zaten kuruldu. Kendi ekranınızda iki çıktının farklı görünmesi bir tuhaflık değil, aracın davranışı.

İşte sahadaki asıl sorun tam burada başlıyor. 22 portuna gelen paketin yutulduğunu biliyorsunuz. Kimin yuttuğunu bilmiyorsunuz. Google mu kapattı, aradaki bir cihaz mı düşürdü, kendi kurumunuzun güvenlik duvarı mı engelledi? Ekranda bu üçünü ayıracak tek bir bilgi yok.

Beş Senaryo: Hangi Kural Ne Kadar Bekletiyor?

Bunu ayırmak için laboratuvara geçiyoruz. Kurulum sade: iki makine var, biri bağlanmaya çalışan istemci, diğeri hedef sunucu. Sunucuda tek bir ayarı değiştirip aynı bağlantıyı tekrar tekrar deniyoruz, böylece sonucu etkileyen tek şeyin o ayar olduğunu biliyoruz.

Değiştirdiğimiz ayar şu: bir güvenlik duvarı, gelen pakete üç şeyden birini yapabilir.

1. Geçirir. Paket servise ulaşır, bağlantı kurulur.
2. Açıkça reddeder. “Burada böyle bir şey yok” diye cevap gönderir. Bu cevabı iki farklı biçimde verebilir ve ikisini ayrı ayrı ölçtük: TCP’nin kendi ret sinyaliyle (reject with tcp reset) ya da ağ katmanının hata mesajıyla (reject, yani ICMP unreachable).
3. Sessizce yutar. Paketi çöpe atar ve hiçbir cevap vermez. Adı drop.

Bu üçünü, artı “servis hiç yok” ve “servis çalışıyor” durumlarını da ekleyerek beş ayrı senaryo ölçtük.

Ölçümü Test-NetConnection ile değil, tek denemelik ham bir bağlantı isteğiyle yaptık. Sebebi önemli: hazır araçlar başarısız olduklarında kendiliğinden birkaç kez daha deniyor, dolayısıyla ekranda gördüğünüz süre aracın kendi sabrını da içeriyor. Biz aracın değil, protokolün davranışını ölçmek istedik.

Tablodan üç şey okunuyor ve üçü de sahada işinize yarar:

1. Kabul de ret de anında gelir. Çalışan servis 0 milisaniyede bağlandı, kapalı port 2 saniyede net cevap verdi. Hızlı başarısızlık kötü haber değildir: paketin karşı makineye ulaştığının kanıtıdır.
2. Uzun bekleme tek bir anlama gelir: cevapsızlık. 21 saniye, karşı tarafın “hayır” demesi değil, hiçbir şey dememesidir.
3. drop ile reject arasındaki fark 5 milisaniye. Yani kronometreyle bakan biri için bu ikisi aynı arızadır.

Üçüncü madde masum görünüyor ama makalenin dönüm noktası orası.

Bağlantı Zaman Aşımı Yanıltır: Aynı Süre, İki Ayrı Olay

drop ile reject aynı şey değildir. drop paketi sessizce çöpe atar; karşı taraf hiçbir cevap almaz. reject ise bir cevap gönderir: “burada böyle bir port yok.”

Yani biri susuyor, öteki konuşuyor. Ağ üzerinde bunlar birbirinden tamamen farklı iki davranış.

Şimdi ölçtüğümüz sürelere bakın: ikisi de yaklaşık 21 saniye sürdü. Tam değerler 21.165 ve 21.170 milisaniye, yani aralarında 5 milisaniyelik bir fark var. Bu, aynı testi arka arkaya iki kez çalıştırsanız zaten göreceğiniz kadar küçük bir sapma; ölçümün kendi hata payı içinde kalıyor.

Sonuç şu: kronometre bu ikisini birbirinden ayırt edemiyor. Biri sustu, öteki konuştu, ama ekranda ikisi de aynı göründü.

Paket dökümüne bakınca durum hiç öyle değil. Aynı iki denemenin alıcı taraftaki dökümleri şöyle:

# drop kuralı altında
00:00:00.000000 In IP 192.168.1.115.54821 > 192.168.1.15.9999: Flags [S], seq 2794383364
00:00:01.010682 In IP 192.168.1.115.54821 > 192.168.1.15.9999: Flags [S], seq 2794383364
00:00:02.005321 In IP 192.168.1.115.54821 > 192.168.1.15.9999: Flags [S], seq 2794383364
00:00:04.014247 In IP 192.168.1.115.54821 > 192.168.1.15.9999: Flags [S], seq 2794383364
00:00:08.012780 In IP 192.168.1.115.54821 > 192.168.1.15.9999: Flags [S], seq 2794383364

# reject kuralı altında
00:00:00.000000 In  IP 192.168.1.115.54799 > 192.168.1.15.9999: Flags [S], seq 2738215150
00:00:00.000042 Out IP 192.168.1.15 > 192.168.1.115: ICMP tcp port 9999 unreachable
00:00:01.009350 In  IP 192.168.1.115.54799 > 192.168.1.15.9999: Flags [S], seq 2738215150
00:00:00.000070 Out IP 192.168.1.15 > 192.168.1.115: ICMP tcp port 9999 unreachable

İki dökümde okunacak dört şey var:

1. Her satırın başındaki 00:00:... değeri saat değil, bir önceki paketten bu yana geçen süredir. Yani 00:00:01.010682 yazan satır şunu söylüyor: bu paket, bir öncekinden 1 saniye sonra gönderildi. (Yakalamayı tcpdump -ttt seçeneğiyle aldık; varsayılan ayarda orada günün saatini görürsünüz.) drop altında bu aralıklar 1, 2, 4, 8 saniye diye ikiye katlanıyor: TCP cevap alamayınca pes etmiyor, giderek seyrekleşen aralıklarla yeniden deniyor.
2. Kaynak portu beş satırda da aynı (54821, 54799). Yani bunlar beş ayrı bağlantı denemesi değil, tek bir bağlantının beş kez tekrarlanan ilk adımıdır.
3. seq numarası da beş satırda aynı. Aynı paket yeniden gönderiliyor, yenisi üretilmiyor. Bu, ikinci maddeyi kesinleştiren kanıttır.
4. Asıl fark ikinci dökümde: alıcı her SYNe karşılık 40 ila 70 mikrosaniye içinde bir ICMP cevabı göndermiş. Yani karşı taraf sessiz kalmadı, açıkça “böyle bir port yok” dedi. Bu cevabı üreten protokolün kendisi, taşıdığı diğer mesaj tipleri ve ping çıktısındaki karşılıkları ICMP nedir rehberinde ele alınıyor.

Burada bir soru doğuyor ve cevabı bu makalenin en pratik bulgusu: madem karşı taraf cevap verdi, istemci neden 21 saniye bekledi?

Aynı Kural, İki İşletim Sistemi, 21 Saniyelik Fark

Cevap istemcinin işletim sisteminde. Aynı kuralı, aynı sunucuda, bu kez bir Linux istemciden denedik:

Hedef: 192.168.1.15:9999, kural: reject (ICMP unreachable)

Windows istemci : 21.170 ms  → TimedOut
Linux istemci   :      0 ms  → ConnectionRefused

Aynı sunucu, aynı güvenlik duvarı kuralı, aynı port. Bir istemci 21 saniye bekliyor, diğeri anında cevap alıyor. Windows’un TCP yığını, bağlantı kurulum aşamasında gelen ICMP “port unreachable” mesajını dikkate almayıp yeniden denemeye devam ediyor; Linux ise mesajı alır almaz bağlantıyı sonlandırıyor.

Bu davranış standartların gri bir bölgesinde duruyor ve gri olduğunu standardın kendisi söylüyor. RFC 1122’nin 4.2.3.9 numaralı bölümü port unreachable mesajını “hard error” sayıp bağlantının sonlandırılmasını tavsiye ediyor; aynı belgenin 3.2.2.1 numaralı bölümü ise bunu RST ile aynı işleve sahip sayıp zorunlu tutuyor. RFC 5927 bu iki maddenin çeliştiğini açıkça yazıyor ve durumu “belirsizlik” olarak adlandırıyor.

Peki uygulamadaki yaygın esneklik bunu açıklıyor mu? Hayır, ve fark burada. RFC 5927’nin belgelediği esneklik yalnız kurulmuş bağlantılar için tanımlı (ESTABLISHED ve sonrası). Bizim ölçtüğümüz durum ise bağlantının henüz kurulmadığı an, yani o listenin dışında.

Sahada bunun karşılığı şu: aynı arızayı iki taraf farklı yaşar. Windows tarafındaki kişi 21 saniyelik bir donma görür ve “hiçbir cevap gelmiyor” der. Linux tarafındaki kişi anında bir ret alır ve “bağlantı reddedildi, karşı tarafta servis yok” der. İkisi de dürüsttür, ikisi de kendi ekranında haklıdır ve ikisi de aynı olayı anlatmaktadır. Tartışmanın kilitlendiği yer tam olarak burasıdır.

Aynı yığının RST karşısında ne yaptığı bunu doğruluyor. Güvenlik duvarına ICMP yerine RST göndertince Windows istemci ConnectionRefused dönüyor ve tekrar aralığı üstel geri çekilmeden sabit yarım saniyeye iniyor. Yani sorun cevabı almamak değil, hangi cevabı dinlediği.

Buradan çıkan pratik kural şu: teşhisi kronometreye bırakmayın. Süre size yalnızca “cevap gelmedi” der, oysa cevap gelmiş olabilir.

Çift Uçlu Yakalama: “Bize Bir Şey Gelmiyor” Nasıl Çürütülür?

Kronometrenin yetmediğini gördük; peki iki ayrı kurum söz konusuysa teşhis nasıl yapılır? Orada mesele teknik olmaktan çıkıp diplomatik bir sürece dönüşür. Farklı bir firmayla çalışırken karşı taraftaki sistemciden ya da network sorumlusundan alınan cevap çoğu zaman tek cümledir: “bizde bir sorun yok, sizde var.” Elinizde bunu çürütecek bir şey olmadığında tartışma orada kilitlenir.

Çürüten şey şudur: aynı bağlantı denemesini iki uçtan aynı anda yakalamak.

ÖNCE ve SONRA: Değişen Tek Şey Bir Satır

Laboratuvarda bunu kurduk. İki sunucu, aralarında başka hiçbir cihaz yok. Alıcıda 9999 portunda gerçek bir servis dinliyor, ama alıcının güvenlik duvarında tek satırlık bir drop kuralı var: gelen paketler sessizce çöpe atılıyor. Gönderen taraftan bağlanmayı deniyor ve aynı anda iki uçtan birden yakalama alıyoruz.

Devam etmeden önce bir tahmin yapın. Gönderen tarafta ne göreceğimiz belli: cevapsız kalan SYN paketleri. Asıl soru şu: alıcının kendi makinesinde ne görünecek?

Sezgisel cevap “hiçbir şey” olur. Güvenlik duvarı paketi düşürdüyse orada bir kayıt kalmaması gerekir; karşı taraf da zaten tam bunu söylüyor: “bize bir şey gelmiyor.”

İşte ÖNCE aşamasının iki uçtaki dökümü, yan yana (dokuz SYN’in ilk ikisi):

# GÖNDEREN tarafında
00:00:00.000000 Out IP 192.168.1.30.60360 > 192.168.1.15.9999: Flags [S], seq 388863482, TS val 1793784401
00:00:01.021757 Out IP 192.168.1.30.60360 > 192.168.1.15.9999: Flags [S], seq 388863482, TS val 1793785424

# ALICI tarafında, aynı anda
00:00:00.000000 In  IP 192.168.1.30.60360 > 192.168.1.15.9999: Flags [S], seq 388863482, TS val 1793784401
00:00:01.021660 In  IP 192.168.1.30.60360 > 192.168.1.15.9999: Flags [S], seq 388863482, TS val 1793785424

Tahmin tutmadı. Alıcı tarafta paketler duruyor, hem de dokuzunun dokuzu. Üstelik bunlar “benzer” paketler değil:

1. Kaynak portu aynı (60360), sıra numarası aynı (388863482), zaman damgası aynı (TS val 1793784401). Yani bunlar aynı paketin iki ucundaki görüntüsü.
2. Tek fark yön bilgisidir: gönderende Out, alıcıda In.
3. Yani paketler alıcının makinesine ulaştı ve orada kaydedildi. Yalnızca uygulamaya hiç verilmediler.

Sezginin neden yanıldığını açıklayan şey şu: paket yakalama aracı, paketi güvenlik duvarı süzgecinden önce görür. Kayıt alma noktası, kuralın uygulandığı noktadan daha erkendedir. Dolayısıyla güvenlik duvarı paketi düşürse bile yakalama onu çoktan kaydetmiştir.

Pratik sonucu bu makalenin en işe yarar cümlesi olabilir: “bize hiçbir şey gelmiyor” diyen tarafın kendi makinesinde alınacak bir döküm, kendi kuralını ele verir.

Şimdi tek satırı silip aynı deneyi tekrarlıyoruz. Bu sefer beklenti net: kural gittiğine göre bağlantı kurulmalı.

Ve kuruldu, hem de 0,75 milisaniyede. Aynı iki uçtan alınan döküm bu sefer şöyle görünüyor:

# GÖNDEREN tarafında
00:00:00.000000 Out IP 192.168.1.30.41216 > 192.168.1.15.9999: Flags [S],  seq 3290926036
00:00:00.000508 In  IP 192.168.1.15.9999 > 192.168.1.30.41216: Flags [S.], seq 2464608652, ack 3290926037
00:00:00.000151 Out IP 192.168.1.30.41216 > 192.168.1.15.9999: Flags [.],  ack 1

# ALICI tarafında, aynı anda
00:00:00.000000 In  IP 192.168.1.30.41216 > 192.168.1.15.9999: Flags [S],  seq 3290926036
00:00:00.000037 Out IP 192.168.1.15.9999 > 192.168.1.30.41216: Flags [S.], seq 2464608652, ack 3290926037
00:00:00.000641 In  IP 192.168.1.30.41216 > 192.168.1.15.9999: Flags [.],  ack 1

İki dökümü ÖNCE aşamasıyla karşılaştırınca fark tek bakışta görünüyor:

1. Flags sütunu artık üç farklı değer taşıyor: [S] → [S.] → [.]. Bu, makalenin başında tanıdığınız üçlü el sıkışma. ÖNCE aşamasında ise dokuz satırın dokuzu da [S]’ti, çünkü karşı taraftan hiç cevap gelmiyordu.
2. Yön bilgisi artık dönüşümlü. Gönderende Out → In → Out, alıcıda In → Out → In. Yani konuşma karşılıklı. ÖNCE aşamasında gönderende sadece Out, alıcıda sadece In vardı: tek yönlü bir tekrar.
3. Sunucunun cevabı 37 mikrosaniyede geldi (alıcı dökümündeki ikinci satır). Aynı kablo, aynı iki makine; az önce 20 saniye bekleten kurulum şimdi mikrosaniyeler içinde tamamlanıyor.

Bunun ardından iki uçta düzgün bir kapanış da göründü (FIN alışverişi), ama asıl kanıt yukarıdaki üç satır.

Değişen tek şey alıcıdaki o tek satırdı. Sonucun tartışmaya kapalı olmasının sebebi de bu: başka hiçbir değişken yok.

Deneyde iki sunucunun arasında bilerek hiçbir cihaz bırakılmadı. Bu bir eksiklik değil, deneyin kontrolüdür: tek değişken alıcının kuralı olduğu için “belki aradaki bir cihaz düşürmüştür” şüphesi doğmaz. Gerçek hayatta arada cihazlar vardır ve o zaman soru “kim düşürdü”ye dönüşür. Sıradaki bölüm tam olarak bunun cevabı.

Paketi Nerede Yakalarsanız Neyi Kanıtlarsınız?

Yakalamanın nerede alındığı, neyi kanıtladığını doğrudan belirler. Aynı arıza için üç farklı noktadan alınan üç yakalama, üç farklı iddiayı destekler.

Sahada en verimli nokta ikincisidir: kontrol ettiğiniz en uç cihaz, yani trafiğin sizden çıkarken geçtiği son durak. Tek bir yakalamayla iç ağınızın tamamı aklanır. Bu bir cihaz markası ya da modeli meselesi değil, bir ilkedir.

Yakalama Komutları

Aynı işi her ortamda yapabilirsiniz, yalnızca aracın adı değişir. Üçü de belirli bir adres ve port çiftini süzer, çünkü filtresiz yakalama hem gereksiz yük bindirir hem okunamayacak kadar büyür.

Linux tarafında, bir sunucuda ya da geçit görevi gören bir makinede:

sudo tcpdump -i any -nn 'host 203.0.113.10 and tcp port 443'

Windows tarafında, ek yazılım kurmadan:

pktmon start --capture --pkt-size 128 -f C:\yakalama.etl
pktmon stop
pktmon etl2pcap C:\yakalama.etl -o C:\yakalama.pcap

pktmon Windows 10 ve Windows Server 2019 ile birlikte geliyor, yani Npcap ya da Wireshark kurulumu gerektirmiyor. Kurulum izni olmayan bir kurumsal makinede yakalama alabilmenizin en pratik yolu budur.

Yönetilebilir bir switch üzerinde ise trafiğin kopyası, port yansıtma (port mirroring, SPAN) ile bir izleme portuna gönderilir ve yakalama o porta bağlı makinede alınır. Güvenlik duvarlarının çoğu da kendi komut satırında benzer bir yakalama komutu taşır.

Uçtaki Yakalamanın Asimetrisi

Bu yakalamanın önemli bir asimetrisi var ve makalenin en öğretici cümlesi bu: uçtaki yakalama gördüğünde güçlü, görmediğinde zayıf kanıttır.

• Paketi uçta görüyorsanız, iç ağınız aklanmıştır. Paket üretildi, yol aldı ve sizden çıktı.
• Paketi uçta görmüyorsanız, elinizde iki ayrı ihtimal kalır ve bu yakalama onları ayıramaz: uygulama paketi hiç üretmemiş olabilir ya da paket iç ağda düşmüş olabilir.

İkinci durumda teşhisi bir adım geriye, istemciye taşımanız gerekir.

Bir uyarı daha: yolun üstündeki bir cihazda alınan yakalama, o cihazın kendisi hakkında güvenilir tanık değildir. “Paket buradan geçti” demeye yeter, “bu cihaz onu düşürmedi” demeye yetmez.

UDP’de Sessizlik Ne Anlama Gelir?

Buraya kadarki her şey TCP’nin el sıkışması üzerine kuruluydu. UDP’de o el sıkışma hiç olmadığı için teşhis de zorlaşır. Bir TCP portunun açık olduğunu SYN-ACK gelmesinden anlarsınız; UDP’de böyle bir sinyal yoktur. Açık bir UDP portu, uygulama cevap vermediği sürece sessiz kalır. Kapalı bir UDP portu ise genellikle bir ICMP “port unreachable” cevabı üretir.

Buradan çıkan beklenti şudur: sessizlik filtreleme, ICMP cevabı ise kapalı port anlamına gelir. Yani kapalı bir UDP portuna vurduğunuzda test programınızın hemen “kapalı” demesi, engellenmiş bir porta vurduğunuzda ise beklemesi gerekir. Mantıklı görünüyor.

Laboratuvarda kapalı bir UDP portuna vurduk. Test programı 6 saniye bekledi ve “cevap gelmedi” dedi. Beklentiye göre bu, portun engellendiği anlamına gelir.

Sonra aynı anın paket dökümüne baktık: sunucu 47 mikrosaniyede bir ICMP “port unreachable” cevabı göndermişti. Yani açık ve net bir şekilde “böyle bir port yok” demişti. Test programı bu cevabı hiç görmedi.

Sebep ağda değil, test programının kendisinde. Ve bunu anlamak için connect() denen çağrıyı tanımak gerekiyor.

UDP’de connect() ilk bakışta kendi kendisiyle çelişiyor: UDP bağlantısız bir protokolse, neyi bağlıyor? Cevap: hiçbir şeyi. Bu çağrı ağa tek bir paket bile göndermez. Yaptığı tek iş, işletim sistemine yerel bir not düşmektir: “bu soketin muhatabı şu adres, şu port.”

O notun ne işe yaradığı, tam da hata geldiğinde ortaya çıkıyor. Sunucudan bir ICMP hata mesajı döndüğünde çekirdeğin onu bir sokete teslim etmesi gerekir, ama hangisine? Muhatabını bildirmiş soket bellidir: hata o adresten geliyorsa o sokete aittir. Muhatabını bildirmemiş soket ise herkesle konuşmaya açık durur; çekirdek gelen hatayı onunla eşleştiremez ve teslim etmez. Yani davranış keyfi değil, kaçınılmaz.

Test programımız soketi muhatapsız kurmuştu. Cevap makineye ulaştı, çekirdeğe kadar geldi, ama programa hiç verilmedi.

Bunu kanıtlamak için tek şeyi değiştirip testi tekrarladık: soketi bu sefer muhatabını bildirerek kurduk. Aynı porta, aynı makineden. Sonuç 0,68 milisaniyede ConnectionRefused oldu. Ağ aynı ağdı, sunucu aynı sunucu; değişen tek şey programın soketi nasıl açtığıydı.

Üç hedefe yapılan ölçümün tamamı şöyle:

İlk iki satırın üçüncü sütunu birebir aynı: 6.006 ms sessizlik. Biri kapalı port, öteki güvenlik duvarı kuralı, ama muhatapsız soketle bakan biri için ikisi tek bir şeye benziyor.

Pratik sonucu doğrudan işinize dokunuyor: muhatapsız yazılmış bir UDP testi, “kapalı port” ile “engellenmiş port”u ayırt edemez. Ayıran tek şey paket dökümüdür.

Bu, makalenin başından beri süren tezin TCP’den bağımsız ikinci kanıtı. İlk kanıtta kronometre iki farklı güvenlik duvarı davranışını aynı gösteriyordu. Bu ikincisinde ise test aracı, ağda açıkça var olan bir cevabı hiç görmüyor. İkisinde de aracın anlattığı hikaye ile ağda olan biten aynı değil.

Sonuç: Tartışmayı Bitiren Şey Paketin Kendisi

Port numarası, tek bir adrese gelen trafiği doğru programa dağıtan sayıdır; TCP o dağıtımı onaylayarak, UDP onaylamadan yapar. Buraya kadarı her kaynakta yazar.

Asıl mesele, bu bilgilerin bir arıza anında ne işe yaradığıdır. Bu makaledeki ölçümler üç şeyi gösterdi:

• Süre, arızanın türünü söylemez. drop ile reject arasındaki fark 5 milisaniyeydi, oysa biri sessizlik, diğeri açık bir rettir.
• Aynı arıza iki tarafta farklı görünür. Aynı kural karşısında bir istemci 21 saniye donarken diğeri anında ret aldı. “Bizde sorun yok, sizde var” tartışmasının teknik kaynağı çoğu zaman budur.
• Aracın gördüğü ile ağda olan aynı şey değildir. UDP testinde sunucunun 47 mikrosaniyede gönderdiği cevabı test programı hiç görmedi.

Üçünün de ortak cevabı aynı: paketin kendisine bakmak. Ve çift uçlu yakalama bunu tartışmaya kapalı hale getiriyor, çünkü aynı sıra numarasını taşıyan aynı paketi iki uçta birden göstermek bir yorum değil, kayıttır.

Bir sonraki bağlantı arızasında elinizde iki dosya olsun: sizden çıkarken alınmış bir yakalama ve karşı taraftan istenmiş bir yakalama. Tartışma o iki dosyanın yan yana konduğu yerde biter.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.