Ağ Dünyasının Görünmez Mimarisini Anlamak: Application Layer ve Kritik Protokoller — İkinci Kısım

HTTP ve HTTPS ile web iletişiminin nasıl çalıştığını, DNS ile alan adlarının nasıl çözümlendiğini, DHCP ile cihazların ağ bilgilerini nasıl aldığını, SMTP, IMAP ve POP3 ile e-posta iletişiminin nasıl ilerlediğini gördük.

Ardından SSH, RDP ve Telnet tarafında uzak bağlantı protokollerini; güvenli erişim, yönetim bağlantısı ve basit port testi bakış açısıyla değerlendirdik.

Ancak Application Layer yalnızca web, DNS, e-posta ve uzak bağlantı protokollerinden ibaret değildir.

Kurumsal yapılarda dosya aktarımı, merkezi kimlik doğrulama, dosya paylaşımı, cihaz izleme, zaman senkronizasyonu, merkezi loglama, erişim kontrolü, ses iletişimi, API entegrasyonları, mesajlaşma sistemleri ve veritabanı bağlantıları da bu katmanda karşımıza çıkar.

Bu nedenle Application Layer'ın ikinci kısmında daha çok kurumsal altyapılarda ve güvenlik operasyonlarında sık gördüğümüz protokollere odaklanacağız.

Bu yazıda şu başlıkları ele alacağız:

FTP, FTPS, SFTP ve TFTP ile dosya aktarımı,

LDAP ve Kerberos ile dizin servisleri ve merkezi kimlik doğrulama,

SMB ve NFS ile ağ üzerinden dosya paylaşımı,

SNMP, NTP ve Syslog ile izleme, zaman senkronizasyonu ve loglama,

RADIUS ve TACACS+ ile merkezi erişim kontrolü,

SIP ve RTP ile sesli iletişim,

WebSocket ile uzun süre açık kalan çift yönlü bağlantılar,

MQTT ve AMQP ile mesajlaşma sistemleri,

Veritabanı iletişim protokolleri ile uygulamaların veri katmanıyla nasıl konuştuğu.

Bu bölümde de amacımız yalnızca protokol isimlerini veya port numaralarını ezberlemek olmayacak.

Asıl bakacağımız şey şu olacak:

Bu protokol hangi ihtiyacı çözüyor ve nasıl çalışıyor?

Çünkü Layer 7'de bir sorun yaşandığında portun açık olması çoğu zaman tek başına yeterli değildir.

Trafiğin geçtiği topoloji, aradaki ürünler, kullanılan protokol, kimlik doğrulama yöntemi, uygulama davranışı ve loglar birlikte değerlendirilmelidir.

FTP, FTPS, SFTP ve TFTP

Dosya aktarımı için kullanılan protokoller birbirine benzer görünebilir.

Ancak aynı şey değildir.

Bu ayrımı bilmek özellikle firewall, NAT, proxy ve güvenlik politikaları tarafında önemlidir.

Çünkü bir dosya aktarımı çalışmadığında problem yalnızca "port açık mı?" sorusuyla çözülemez.

FTP, klasik dosya aktarım protokolüdür.

TCP 21 portu kontrol bağlantısı için kullanılır.

Kullanıcı girişi, dizin listeleme, dosya indirme veya dosya yükleme komutları bu kontrol bağlantısı üzerinden ilerler.

Ancak FTP'de dosya aktarımı için ayrıca veri bağlantısı açılır.

Bu yüzden FTP, bazı yapılarda firewall ve NAT açısından sorun çıkarabilir.

FTP iki farklı modda çalışabilir:

Aktif mod ve pasif mod.

Aktif modda istemci kontrol bağlantısını kurar, ancak veri bağlantısını sunucu istemciye doğru açmaya çalışır. Bu durum istemci NAT arkasındaysa veya firewall arkasındaysa problem oluşturabilir. Çünkü dışarıdaki sunucunun iç ağdaki istemciye doğru yeni bağlantı açması gerekebilir.

Pasif modda ise istemci hem kontrol bağlantısını hem de veri bağlantısını sunucuya doğru başlatır. Bu nedenle firewall ve NAT bulunan ortamlarda pasif mod genellikle daha kolay yönetilir.

Klasik FTP'nin önemli bir güvenlik problemi vardır.

Kullanıcı adı, parola ve dosya içeriği şifrelenmeden taşınabilir. Bu nedenle güvenilmeyen ağlarda klasik FTP kullanımı risklidir.

FTPS, FTP iletişiminin TLS ile korunmuş hâlidir. Yani FTP'ye güvenli taşıma katmanı eklenmiş gibi düşünebiliriz.

FTPS iki şekilde karşımıza çıkabilir.

Explicit FTPS çoğunlukla TCP 21 üzerinden başlar. Bağlantı kurulduktan sonra TLS'e yükseltilir.

Implicit FTPS ise genellikle TCP 990 kullanır ve bağlantı baştan itibaren TLS ile korunur.

FTPS, klasik FTP'ye göre daha güvenlidir. Ancak FTP'nin kontrol ve veri bağlantısı mantığı devam ettiği için firewall tarafında yine dikkatli yapılandırma gerekebilir.

SFTP ise FTP'nin TLS eklenmiş hâli değildir.

SFTP, SSH File Transfer Protocol'dür. SSH üzerinden çalışır ve genellikle TCP 22 kullanır.

Bu yüzden SFTP, FTP ve FTPS'ten farklıdır.

SFTP çoğunlukla tek bağlantı üzerinden ilerlediği için firewall tarafında yönetimi FTP'ye göre daha kolay olabilir. Ayrıca SSH kimlik doğrulama mekanizmalarını kullanabilir. Yani parola ile veya SSH key ile erişim sağlanabilir.

TFTP ise daha basit bir dosya aktarım protokolüdür. UDP 69 portunu kullanır. Kimlik doğrulama, şifreleme ve gelişmiş erişim kontrolleri sunmaz. Bu nedenle genel dosya aktarımı için değil, daha sınırlı ve kontrollü senaryolarda kullanılır.

LDAP ve Kerberos

Kurumsal yapılarda kullanıcı, grup, bilgisayar ve yetki bilgileri genellikle merkezi sistemlerde tutulur.

Bu noktada LDAP ve Kerberos sık karşımıza çıkar.

LDAP, dizin servislerindeki bilgileri sorgulamak ve yönetmek için kullanılan protokoldür.

Active Directory, LDAP ile erişilebilen en bilinen dizin servislerinden biridir.

LDAP'ın temel amacı kullanıcı, grup, bilgisayar ve organizasyon bilgilerini merkezi olarak sorgulayabilmektir.

Örneğin bir uygulama kullanıcıyı doğrulamak veya kullanıcının hangi gruplarda olduğunu öğrenmek isteyebilir. Bu durumda LDAP üzerinden dizin servisine sorgu gönderebilir.

LDAP ile şu bilgiler sorgulanabilir:

Kullanıcı hesapları, Gruplar, Bilgisayar nesneleri, Organizasyon birimleri, E-posta adresleri, Grup üyelikleri, Kullanıcı özellikleri.

LDAP genellikle TCP veya UDP 389 portunu kullanabilir.

LDAPS ise bağlantının başından itibaren TLS kullanır ve genellikle TCP 636 portunda çalışır.

LDAP çoğu zaman "kimlik doğrulama protokolü" gibi anlatılır. Ancak temel görevi dizin servisine erişmektir.

Bir uygulama kullanıcıyı doğrulamak için LDAP bind işlemi yapabilir. Bind, belirli kullanıcı bilgileriyle dizin servisine bağlanma işlemidir. Eğer kullanıcı adı ve parola doğruysa bind başarılı olur.

Ancak Active Directory ortamlarında merkezi kimlik doğrulama için Kerberos da çok kritik bir rol oynar.

Kerberos, bilet tabanlı kimlik doğrulama protokolüdür.

Genellikle TCP veya UDP 88 portunu kullanır.

Kerberos'un amacı, kullanıcının parolasını her servise tekrar tekrar göndermeden farklı sistemlere güvenli şekilde erişebilmesini sağlamaktır. Kullanıcı domain ortamında oturum açtığında önce TGT adı verilen bir bilet alır.

TGT, Ticket Granting Ticket anlamına gelir.

Bunu kullanıcının domain ortamında kimliğini kanıtladıktan sonra aldığı temel bilet gibi düşünebiliriz. Kullanıcı daha sonra belirli bir servise erişmek istediğinde bu TGT ile ilgili servis için ayrı bir bilet ister.

Örneğin kullanıcı dosya sunucusuna erişmek istediğinde, dosya sunucusu için servis bileti kullanılır.

Bu yapı Single Sign-On sağlar.

Yani kullanıcı domain'e giriş yaptıktan sonra yetkili olduğu farklı servislere tekrar parola girmeden erişebilir.

Kerberos zaman uyumuna çok hassastır.

İstemci, domain controller ve hedef sunucu saatleri arasında ciddi fark varsa kimlik doğrulama başarısız olabilir.

Bu yüzden NTP yapılandırması Kerberos için çok önemlidir.

SMB ve NFS

Dosya paylaşımı tarafında SMB ve NFS sık görülür.

SMB, ağ üzerinden dosya ve yazıcı paylaşımı için kullanılan protokoldür.

Windows ortamlarında çok sık karşımıza çıkar.

Modern SMB çoğunlukla TCP 445 portunu kullanır.

Eski yapılarda NetBIOS ile ilişkili 137, 138 ve 139 portları da görülebilir.

Bir kullanıcı şu şekilde bir paylaşıma bağlandığında SMB kullanıyor olabilir:

\\fileserver\share

\\fileserver\share

SMB yalnızca dosya indirmek için kullanılmaz.

Dosya oluşturma, silme, değiştirme, dosya kilitleme, yazıcı paylaşımı ve bazı uzak yönetim işlemleri için de kullanılabilir.

SMB erişiminde iki yetki seviyesi önemlidir.

Share permission ve NTFS permission.

Share permission, paylaşıma erişim seviyesini belirler.

NTFS permission ise dosya sistemi üzerindeki gerçek yetkiyi belirler.

Kullanıcı paylaşım seviyesinde yetkili olsa bile dosya sistemi seviyesinde yetkisi yoksa erişim sağlayamayabilir. Bu yüzden SMB problemlerinde yalnızca port kontrolü yapmak yeterli değildir. Kullanıcının gerçekten ilgili klasör üzerinde yetkili olup olmadığı da kontrol edilmelidir.

NFS ise özellikle Linux ve Unix sistemlerde ağ üzerinden dosya sistemi paylaşmak için kullanılan protokoldür.

Modern NFS sürümleri çoğunlukla TCP 2049 portunu kullanır.

NFS sunucusu belirli dizinleri istemcilere export eder. İstemciler de bu dizinleri kendi dosya sistemlerine mount eder. Yani uzak bir dizin, istemci üzerinde yerel bir dizin gibi kullanılabilir.

NFS, Kubernetes gibi ortamlarda ortak depolama veya PersistentVolume amacıyla da kullanılabilir.

NFS tarafında dosya sahiplikleri de önemlidir. Linux sistemlerde dosya yetkileri kullanıcı ID ve grup ID bilgilerine dayanır. Bunlara UID ve GID denir.

İstemci ve sunucu tarafında UID/GID eşleşmeleri doğru değilse dosya erişim problemleri yaşanabilir.

SNMP, NTP ve Syslog

Ağ cihazlarının izlenmesi, sistem saatlerinin senkron tutulması ve logların merkezi sistemlere gönderilmesi de Application Layer'da sık karşılaştığımız konulardır.

SNMP, ağ cihazlarını izlemek ve bazı bilgileri yönetmek için kullanılan protokoldür.

Switch, router, firewall, sunucu, yazıcı ve benzeri cihazlardan bilgi toplamak için kullanılabilir.

SNMP manager, cihazları sorgulayan izleme sistemidir.

SNMP agent ise cihaz üzerinde çalışan ve bilgileri sağlayan bileşendir.

SNMP sorguları genellikle UDP 161 portu üzerinden yapılır.

Cihazların kendiliğinden olay bildirmesi için UDP 162 kullanılır. Bu bildirimlere trap denir.

Örneğin bir port down olduğunda, CPU kullanımı yükseldiğinde, cihaz yeniden başladığında veya donanım problemi oluştuğunda SNMP trap gönderilebilir.

SNMP verileri OID adı verilen numaralandırılmış nesneler üzerinden okunur. MIB dosyaları bu OID'lerin ne anlama geldiğini daha anlaşılır hâle getirir.

SNMPv1 ve SNMPv2c community string kullanır. Community string ortak parola gibi düşünülebilir ancak güçlü bir güvenlik sağlamaz.

SNMPv3 ise kullanıcı doğrulama ve şifreleme özellikleri sunar. Bu yüzden güvenli ortamlarda SNMPv3 tercih edilmelidir.

NTP, sistem saatlerini senkronize etmek için kullanılan protokoldür.

Genellikle UDP 123 portunu kullanır.

NTP basit bir saat düzeltme mekanizması gibi görünse de birçok sistem için kritiktir.

Kerberos kimlik doğrulaması doğru zaman bilgisine ihtiyaç duyar. Sertifika geçerlilik kontrolleri sistem saatine göre yapılır. Logların doğru sırada incelenebilmesi için zaman bilgisi tutarlı olmalıdır. SIEM korelasyonları olay zamanlarına bağlıdır. Dağıtık sistemlerde farklı sunuculardaki olayların aynı zaman çizelgesinde değerlendirilmesi gerekir.

Bu yüzden NTP çalışmıyorsa bazı problemler ilk bakışta ilgisiz gibi görünse bile kimlik doğrulama, sertifika veya log analizi tarafında sorun çıkarabilir.

Syslog ise sistem ve cihaz loglarının merkezi bir sunucuya gönderilmesi için kullanılan yapıdır.

Firewall, switch, router, Linux sunucu ve güvenlik ürünleri Syslog üzerinden log gönderebilir.

Syslog geleneksel olarak UDP 514 portunu kullanır.

TCP 514 üzerinden de çalışabilir.

TLS ile korunan Syslog iletişiminde çoğunlukla TCP 6514 kullanılır.

UDP daha az ek yükle çalışır ama mesajın ulaştığını garanti etmez.

TCP daha kontrollü teslimat sağlar.

TLS ise log içeriğinin ağ üzerinde korunmasına yardımcı olur.

RADIUS ve TACACS+

RADIUS ve TACACS+, merkezi erişim kontrolü için kullanılan protokollerdir.

Bu protokoller özellikle network cihazları, VPN, kablosuz ağ ve kullanıcı erişim kontrollerinde karşımıza çıkar.

Bu yapılarda AAA kavramı önemlidir.

Authentication, kullanıcının kim olduğunu doğrular.

Authorization, kullanıcının hangi işlemleri yapabileceğini belirler.

Accounting ise oturum ve işlem kayıtlarını tutar.

RADIUS özellikle VPN, kablosuz ağ, 802.1X ve Network Access Control sistemlerinde kullanılır.

Genellikle UDP 1812 kimlik doğrulama için, UDP 1813 ise accounting için kullanılır.

Örneğin bir kullanıcı VPN'e bağlanmak istediğinde, VPN cihazı kullanıcının bilgilerini RADIUS sunucusuna sorabilir.

RADIUS sunucusu kullanıcıyı doğrular ve policy bilgisine göre erişim izni verip vermeyeceğini belirleyebilir.

TACACS+ ise daha çok router, switch ve firewall gibi network cihazlarının yönetici erişimlerinde kullanılır.

TCP 49 portunu kullanır.

TACACS+ ile yalnızca cihaz girişini değil, kullanıcının cihaz üzerinde hangi komutları çalıştırabileceğini de daha ayrıntılı kontrol etmek mümkündür.

Örneğin bir kullanıcı cihaza giriş yapabilir ama sadece show komutlarını çalıştırmaya yetkili olabilir. Başka bir kullanıcı ise konfigürasyon değiştirme yetkisine sahip olabilir.

Bu yüzden TACACS+ özellikle network cihazı yönetiminde daha ayrıntılı yetkilendirme ihtiyacı olduğunda tercih edilebilir.

SIP ve RTP

SIP ve RTP sesli ve görüntülü iletişimde birlikte karşımıza çıkan yapılardır.

SIP, görüşmenin başlatılması, yönetilmesi ve sonlandırılması için kullanılır.

Genellikle UDP veya TCP 5060 portunu kullanır.

TLS ile korunan SIP bağlantılarında TCP 5061 görülebilir.

Ancak SIP sesin kendisini taşımaz. SIP daha çok görüşmenin kurulmasını sağlar.

Gerçek ses veya görüntü çoğunlukla RTP üzerinden taşınır.

RTP genellikle dinamik UDP portları kullanır.

Bu ayrım çok önemlidir.

Çünkü telefon çalıyor olabilir. Çağrı kuruluyor olabilir. Ama ses gelmiyor olabilir. Bu durumda SIP tarafı çalışıyor olabilir, ancak RTP trafiği karşı tarafa ulaşmıyor olabilir. Örneğin NAT arkasında yanlış IP bilgisi paylaşılmış olabilir. Firewall RTP port aralığını engelliyor olabilir. SIP ALG trafiği yanlış değiştirmiş olabilir.

Tek yönlü ses problemleri de bu nedenle görülebilir.

WebSocket

WebSocket, istemci ile sunucu arasında uzun süre açık kalabilen çift yönlü bağlantı sağlar.

Klasik HTTP iletişiminde istemci istek gönderir, sunucu cevap döner.

Bu model birçok senaryo için yeterlidir.

Ancak bazı uygulamalarda sunucunun istemciye anlık veri göndermesi gerekir.

Chat uygulamaları, canlı bildirim sistemleri, gerçek zamanlı grafikler, anlık izleme ekranları ve oyunlar buna örnek olabilir.

WebSocket bu ihtiyaç için kullanılır.

WebSocket bağlantısı çoğunlukla normal bir HTTP isteğiyle başlar.

İstemci, bağlantının WebSocket'e yükseltilmesini ister.

Sunucu bunu kabul ederse bağlantı açık tutulur.

Bundan sonra iki taraf da bağlantı üzerinden veri gönderebilir.

Şifrelenmemiş WebSocket bağlantıları ws:// ile gösterilir.

TLS ile korunan WebSocket bağlantıları ise wss:// ile gösterilir.

wss:// çoğunlukla TCP 443 portunu kullanır.

WebSocket tarafında reverse proxy, load balancer ve firewall ayarları önemlidir.

Çünkü bağlantı uzun süre açık kalır.

Proxy veya load balancer bu bağlantıları desteklemiyorsa bağlantı kopabilir. Timeout değeri çok düşükse, belirli süre veri akmadığında bağlantı sonlandırılabilir.

Bu nedenle WebSocket bağlantılarında ping, pong veya heartbeat mekanizmaları kullanılabilir.

Bu mekanizmalar bağlantının hâlâ canlı olduğunu kontrol etmeye yardımcı olur.

MQTT ve AMQP

MQTT ve AMQP, uygulamaların mesajlaşarak haberleşmesini sağlayan protokollerdir.

Bu protokollerde uygulamalar çoğu zaman birbirine doğrudan istek atmaz.

Arada mesajları alan, saklayan ve ilgili tarafa ileten bir yapı bulunur.

Bu yapıya mesaj broker denir.

Basitçe şöyle düşünebiliriz:

Bir uygulama mesajı bırakır. Başka bir uygulama bu mesajı daha sonra alır ve işler.

Bu yöntem özellikle uygulamalar arasında anlık cevap beklenmediği durumlarda kullanılır.

Örneğin bir sipariş oluşturulduğunda, sistem bu sipariş bilgisini kuyruğa bırakabilir. Fatura servisi, bildirim servisi veya raporlama servisi bu mesajı daha sonra alıp kendi işini yapabilir.

Bu sayede uygulamalar birbirine daha az bağımlı çalışır.

MQTT daha hafif bir mesajlaşma protokolüdür.

IoT cihazları, sensörler, akıllı cihazlar ve düşük kaynaklı sistemlerde sık kullanılır.

Genellikle TCP 1883 portunu kullanır.

TLS ile güvenli hâle getirildiğinde TCP 8883 portu kullanılabilir.

AMQP ise daha çok kurumsal uygulamalarda ve servisler arası mesajlaşmada karşımıza çıkar.

Mesaj kuyruğu yapılarıyla çalışır.

Örneğin bir servis mesajı kuyruğa bırakır, diğer servis kuyruktan alıp işler.

Genellikle TCP 5672 portunu kullanır.

TLS ile güvenli hâle getirildiğinde TCP 5671 portu kullanılabilir.

RabbitMQ gibi mesaj broker'ları AMQP desteği sunabilir.

Veritabanı İletişim Protokolleri

Uygulamalar veritabanlarına da ağ üzerinden bağlanır.

Her veritabanı kendi iletişim protokolünü kullanabilir. Bu konu kendi başına ayrı bir yazı olabilecek kadar detaylıdır. Ancak Application Layer kapsamında temel mantığı anlamak önemlidir.

Bir uygulama veritabanına bağlandığında yalnızca bir porta gitmez. Aynı zamanda veritabanının anlayacağı protokol ile konuşur.

Bir web uygulamasında kullanıcı ekranda sadece bir butona bastığını görür. Ama arka planda uygulama sunucusu veritabanına gider, gerekli veriyi okur, günceller veya yeni veri kaydeder.

Örneğin kullanıcı giriş yaptığında uygulama, kullanıcının gerçekten var olup olmadığını veritabanından kontrol edebilir.

Bir liste ekranı açıldığında uygulama, gösterilecek kayıtları veritabanından çekebilir.

Bir form gönderildiğinde uygulama, gelen bilgiyi veritabanına yazabilir.

Yani uygulama ile veritabanı arasında sürekli bir iletişim vardır.

Bu iletişim de belirli kurallara göre yapılır. Bu kurallara veritabanı iletişim protokolü diyebiliriz.

Buradaki mantık şudur:

Uygulama veritabanına sadece "ben geldim" demez.

Şunu söyler:

Ben hangi veritabanına bağlanacağım? Hangi kullanıcı ile bağlanacağım? Hangi sorguyu çalıştıracağım? Gelen sonucu nasıl okuyacağım? Bağlantı şifreli mi olacak? Hata olursa ne cevap dönecek?

Her veritabanı sistemi bu konuşmayı kendi yapısına göre gerçekleştirir.

Bu yüzden Microsoft SQL Server, PostgreSQL, MySQL, Oracle, MongoDB veya Redis aynı şekilde konuşmaz. Hepsinin amacı veriyle çalışmaktır ama uygulama ile veritabanı arasındaki konuşma biçimleri farklıdır.

Basitçe şöyle düşünebiliriz:

HTTP'de tarayıcı web sunucusuna istek gönderir.

Veritabanı protokollerinde ise uygulama, veritabanı sunucusuna sorgu gönderir.

Web sunucusu HTML, JSON veya dosya dönebilir.

Veritabanı sunucusu ise sorgunun sonucunu döner.

Örneğin uygulama veritabanına şuna benzer bir sorgu gönderebilir:

SELECT * FROM users WHERE id = 15;

SELECT * FROM users WHERE id = 15;

Veritabanı bu sorguyu işler ve sonucu uygulamaya döner. Kullanıcı bunu doğrudan görmez. Kullanıcı sadece ekranda gelen veriyi görür.

Bu yüzden bir uygulamanın çalışması için veritabanı bağlantısı çok kritiktir.

Uygulama ayakta olabilir. Web sayfası açılabilir. Login ekranı gelebilir. Ama uygulama veritabanına bağlanamıyorsa kullanıcı giriş yapamaz, kayıtlar listelenmez veya işlem tamamlanmaz.

Uygulamanın veritabanına bağlanabilmesi için bazı bağlantı bilgilerine ihtiyacı vardır.

Bu bilgilerin birlikte yazıldığı bağlantı tanımına connection string denir.

Connection string'i, uygulamanın veritabanına nasıl bağlanacağını söyleyen adres tarifi gibi düşünebiliriz.

Örneğin uygulama şunu bilmek zorundadır:

Veritabanı sunucusu nerede? Hangi porttan bağlanacağım? Hangi veritabanını kullanacağım? Hangi kullanıcı adı ve parola ile bağlanacağım? Bağlantı şifreli mi olacak?

Basit bir örnek şöyle düşünülebilir:

Server=10.10.10.20;Port=5432;Database=appdb;User Id=appuser;Password=*****

Server=10.10.10.20;Port=5432;Database=appdb;User Id=appuser;Password=*****

Bu örnek şunu anlatır:

Uygulama 10.10.10.20 adresindeki veritabanı sunucusuna gider.

5432 portunu kullanır.

appdb isimli veritabanına bağlanır.

appuser kullanıcısı ile oturum açar.

Parola bilgisini kullanarak doğrulama yapar.

Yaygın varsayılan portlardan bazıları şunlardır:

Microsoft SQL Server genellikle TCP 1433 kullanır.

PostgreSQL genellikle TCP 5432 kullanır.

MySQL genellikle TCP 3306 kullanır.

Oracle Database genellikle TCP 1521 kullanır.

MongoDB genellikle TCP 27017 kullanır.

Redis genellikle TCP 6379 kullanır.

Elasticsearch ve OpenSearch HTTP API genellikle TCP 9200 kullanır.

Bu portlar varsayılan değerlerdir ve değiştirilebilir.

Ama burada önemli olan şudur:

Portun açık olması, veritabanı bağlantısının kesin çalışacağı anlamına gelmez. Port açık olabilir ama kullanıcı adı hatalı olabilir. Parola yanlış olabilir. Uygulama yanlış veritabanı adına bağlanıyor olabilir. Veritabanı kullanıcısının yetkisi olmayabilir. TLS zorunlu olduğu hâlde uygulama şifresiz bağlanmaya çalışıyor olabilir. Veritabanı yeni bağlantı kabul etmiyor olabilir. Sorgu çok uzun sürdüğü için timeout oluşuyor olabilir.

Bu yüzden veritabanı bağlantı problemlerinde hem network hem de uygulama tarafı birlikte kontrol edilmelidir.

Application Layer Problemlerinde Nereye Bakılmalı?

Application Layer'da problem olduğunda alt katmanlar tamamen sağlıklı olabilir.

Kablo bağlı olabilir. VLAN doğru olabilir. IP adresi doğru olabilir. Route bulunabilir. Port açık olabilir. TLS handshake tamamlanabilir.

Ama uygulama yine de çalışmayabilir.

Çünkü Layer 7'de artık uygulamanın dili, isteğin formatı, kimlik doğrulama bilgisi, yetki kontrolü, veri yapısı ve arka taraftaki bağımlı servisler devreye girer.

Bu yüzden Application Layer troubleshooting yaparken yalnızca "port açık mı?" diye bakmak yeterli değildir.

Trafiğin geçtiği topoloji de çok önemlidir.

Bir istek istemciden çıkıp doğrudan uygulama sunucusuna gitmeyebilir. Arada DNS, firewall, proxy, WAF, load balancer, API gateway, reverse proxy, uygulama sunucusu, cache, veritabanı veya mesaj broker olabilir. Bu yüzden problem yaşanan akışta sıradaki ürünün ne olduğu ve bu ürünün hangi katmanda karar verdiği bilinmelidir.

Örneğin kullanıcı 502 hatası görüyor olabilir. Bu hata uygulamadan değil, reverse proxy veya load balancer'dan dönüyor olabilir.

Kullanıcı 403 hatası görüyor olabilir. Bu cevap uygulamadan, WAF'tan veya API gateway'den üretilmiş olabilir. WebSocket bağlantısı kopuyor olabilir. Problem uygulamada değil, aradaki timeout ayarında olabilir. Login başarılı görünüyor olabilir ama kullanıcı sonraki istekte oturumdan düşüyor olabilir. Problem uygulama sunucuları arasında paylaşılmayan session bilgisi olabilir.

Bu yüzden Layer 7 tarafında şu sorular sorulmalıdır:

Alan adı doğru IP'ye çözülüyor mu? İstemci doğru protokolü kullanıyor mu? Doğru porta mı bağlanılıyor? Trafik hangi ürünlerden geçiyor? Sıradaki ürün ne? Bu ürün hangi katmanda karar veriyor? HTTP isteği doğru URL'ye mi gidiyor? Kullanılan HTTP metodu doğru mu? Header bilgileri doğru mu? Content-Type beklenen formatla uyumlu mu? Kimlik doğrulama bilgisi gönderiliyor mu? Kullanıcının yetkisi var mı? Dönen status code nedir? Bu cevabı uygulama mı, proxy mi, WAF mı, load balancer mı üretiyor? Backend servisi çalışıyor mu? Uygulama veritabanına erişebiliyor mu? Mesaj kuyruğunda birikme var mı? Loglar doğru şekilde geliyor ve parse ediliyor mu? Uygulama loglarında gerçek hata ne görünüyor?

Çünkü Application Layer'da problem varsa ağ tarafı tamamen sağlıklı görünse bile uygulamalar aynı dili konuşamadığı, istek yanlış formatta olduğu, kullanıcı yetkisiz olduğu veya bağımlı servislerden biri çalışmadığı için işlem tamamlanamayabilir.