Kategori: Uncategorized

  • CCNA – Çalışma Günlüğüm #3

    Bu alanlar sırasıyla:

    Preamble: 10101010 şeklinde bir dizilime sahip olan 7 byte uzunluğunda bir alandır. Amaç alıcı tarafla senkronizasyon konusunda antlaşma sağlayabilmektir.

    SFD: Preamble alanının devamı olarak da düşünebiliriz. Preamble dizilimden farklı olarak 10101011 şeklinde tamamlanır. Burada amaç artık senkronizasyonu tamamladık, bu vakitten itibaren sana göndereceğim bitler data’ya ait bitlerdir, demektir.

    Source ve Destination: 6 + 6 toplamda 12 byte sahip alandır. İçlerinde MAC (Burned In Adress olarak da bilinirler) adreslerini barındırırlar.

    Type ~ Length: 2 byte uzunluğundadır. Frame’in uzunluğuna göre ne amaçla kullanılacağı belirlenir. Eğer frame 1536** byte’dan daha uzunsa bu alan paketin türünü (IPv4 – IPv6) gösterir, 1500 byte’dan az ise paketin boyutunu gösterir.

    IPv4, 0x0800 ile temsil edilir, bu decimal tabanda 2048’e karşılık gelir. 2048 burada bir etiket gibidir, üst katman 2048’i gördüğü anda bunun işlenecek bir IPv4 paketi olduğunu bilir. Aynı şekilde IPv6’da 0x86DD ile temsil edilir ve decimal değeri de 34525 eder. Yani üst katman 2048 gördüğünde IPv4, 34525 gördüğünde IPv6 işlemi yapar.

    FCS: 4 byte uzunluğundadır, döngüler üzerinde Cyclic Redundancy Check (CRC) algoritması çalıştırır.

    MAC adresleri dünya genelinde genellikle benzersizdir. Toplamda 6 byte uzunluğundadır, ilk 3 byte üretildiği şirketi belirtir (OUI). Kalan 6 byte cihaza özgüdür. MAC adresleri 12 hexadecimal karakterden oluşur.

    Switch’ler tablo tutarlar, gelen isteklerin içerisinden kaynak MAC’leri alıp geldikleri arayüz ile ilişkilendirirler, böylece gelecek yeni paketler için de bir yol haritası çizerler. Buna dinamik MAC denir. Hedef adresinin nerede olduğunu bilmedikleri paketlerde, paketin geldiği arayüz hariç her yerden paketi gönderirler. Bilinmeyen Unicast Frame = Flood

    Not: Cisco switch’lerde mac adres tablosunda yer alan dinamik mac’ler eğer 5 dakika boyunca onlar hakkında bir işlem olmazsa tablodan silinirler. (agging – yaşlandırma)

    Premble ve SFD alanları genellikle ethernet header’ın bir parçası kabul edilmez, yani header aslında source, destination ve type alanlarından oluşur. Data haricinde L2’de eklenen kısım header 14 byte ve trailer 4 byte’tan 18 byte eder.

    Bir ethernet frame’in minimum boyutu 64 byte’dır. 18 byte’ı L2 bilgisi olduğunu varsaydığımızda minimum data için 46 byte gerekir. 46 byte’tan küçük bir veri gönderilemez, eğer gönderilirse veri (padding) yapılır. (0 ile doldurulur)

    Bizler bir ağda iletişim kurarken yalnızca MAC’lerden yararlanmayız. Bİr paket dış bir ağa gideceği vakit mutlaka IP adreslerine ihtiyaç duyarız. Temelde kullandığımız IP adresleri 32 bittir. ARP (Adress Resolution Protocol, bilgisayarların MAC adresleri aracılığıyla IP adreslerini öğrenebilmelerini sağlayan bir protokoldür. ARP iki farklı mesajdan oluşur, ARP request ve ARP reply.

    MAC adresini öğrenmek isteyen taraf request gönderir, MAC’e sahip taraf da reply gönderir ve bu şekilde işlem başlar. Request broadcast (FFFF.FFFF.FFFF) olarak gönderilir, reply unicast olarak gönderilir.

    ICMP de benzer çalışır. ICMP Echo Request ve ICMP Echo Reply bölümlerinden oluşur. PING atabilmek için kullandığımız bu protokolde öncelikle MAC aracılığıyla karşı tarafın IP’sini öğrenmek için ARP Request gönderilir ve MAC öğrenilir ardından ICMP süreci işlemeye başlar.

    Jeremy’s it lab’de bulduğum bir ccna çalışmasını cevaplamak istiyorum.

    Eğer PC1, PC3’e ping atarsa ağ üzerinden hangi mesajlar gönderilir ve bu mesajları hangi cihazlar alır?Ping işlemini başlatın ve cevabınızı doğrulamak için Packet Tracer’ın “simulation mode” (simülasyon modu) özelliğini kullanın.

    • Cevap: PC1, PC3’e ping attığında (bunun ilk defa gerçekleştiğini kabul ediyorum) öncelikle SW1’e ARP Request paketi iletilir, SW2 bu paketi F0/1 arayüzü hariç diğer arayüzlerden flood eder. Paketin gittiği diğer SW2 ise bunu aynı şekilde geldiği arayüz hariç diğer arayüzlere flood eder. Yani PC1 hariç diğer tüm bilgisayarlar bu request’i alır. Sadece PC3 ARP reply gönderir, bu bilinen unicast yayını olarak kabul edilir ve doğrudan PC1’e ulaşır. ARP tamamlandıktan sonra ICMP Echo Request atılır, PC3 yolunu izler ve PC3’ten reply alınarak işlem tamamlanır.

    Ağ trafiği oluşturmak ve switch’lerin ağdaki tüm PC’lerin MAC adreslerini öğrenmesini sağlamak için ping’leri kullanın.

    • Cevap: Tek tek bilgisayarlara girip ping atarak bu işlemi tamamlayabiliriz. Bunun haricinde simülasyon modunu açıp birkaç defa ileriye almak da işimizi görecektir.

    Her bir PC’nin MAC adresini belirlemek için switch’ler üzerinde “show” komutlarını kullanın.

    • Cevap: Tek tek her bir switch’e gidip ayrıcalıklı yürütme moduna geçip “show mac address-table” yazıyorum, bitiyor.

    Her bir switch’in MAC adres tablosundaki dinamik MAC adreslerini temizleyin.

    • Cevap: Her bir switch’e girip ayrıcalıklı yürütme moduna geçip “clear mac address-table dynamic” yazıyorum ve çalışmayı tamamlıyorum.


  • CCNA – Çalışma Günlüğüm #1

    Bilgisayar ağları, düğümlerin ortak kaynakları paylaşmasına olanak tanıyan dijital telekomünikasyon ağlarıdır. Burada düğümden kastımız ağı oluşturan temel bileşenlerdir: router, switch, firewall, server, client … (Server ve client son nokta (end point – end hosts) olarak adlandırılır.

    Client, server tarafından sunulan hizmete erişim sağlayan her türlü cihaz olabilir. Zaman zaman istemci ve sunucu yer değiştirebilir, yani istemci tarafı sağladığı hizmete göre bir anda sunucu olarak da adlandırılabilir. Örneğin, airdrop kullanarak arkadaşınızın telefonuna veri aktardığınızda sizin telefonunuz server karşı taraf ise client olur.

    Switch: LAN (Local Area Network) içerisinde düğümlerin birbirlerine bağlanabilmeleri için kullanılan aracı bir cihazdır. Genellikle 24’ten fazla giriş noktası (port) barındırırlar. Doğrudan internete gidemezler. Cisco Catalyst serisi örnek olarak verilebilir.

    Router: Ağlar arası veri iletişimini sağlayan yegane cihazlardır. Switch’lere nazaran daha az giriş noktası barındırırlar. Cisco ISR serisi örnek olarak verilebilir.

    Firewall: İnternet ağlarına gelen ve giden trafiği filtrelememize olanak sağlayan cihazlardır. Router ile internet arasına veya switch ile router arasına yerleştirebiliriz. Trafiğin akışını firewall içerisinde kurallarla yapılandırarak kontrol edebiliriz. Next Generation firewall’larda IDS-IPS gibi ek savunma sistemleri de barındırılır. Bu tür firewall’lara örnek olarak Cisco ASA ve Firepower serileri verilebilir. Firewall’lar nerede bulunduklarına bağlı olarak ikiye ayrılırlar:

    • Network Firewall: Donanımsal olarak bulunan doğrudan ağdaki trafiği filtreleyen cihazlardır.
    • Host-based Firewall: Yazılımsal olarak doğrudan end point cihazlarda bulunan ve cihaza gelen trafiği filtreleyen cihazlardır.

    Not: Network firewall bulunsa dahi pratikte doğru bir savunma için her cihazda host-based firewall’da bulunması önerilmektedir.

    Packet Tracer’da oluşturduğum basit bir ağ diyagramı.

    Bahsettiğimiz ağ cihazlarının birbirleriyle iletişim kurması Ethernet standartları çerçevesinde gerçekleşir. Ethernet standartları ağ cihazları arasındaki iletişimi belirleyen kurallar bütünü olarak da isimlendirilebilir.

    Ethernet standartları IEEE 802.3 koduyla belirtilmiştir. IEEE (Elektrik ve Elektronik Mühendisleri Enstitüsü) standartları belirleyen kurumdur. Fiziksel ve yazılımsal bileşenler üzerine standartlar belirleyebilir, bu standartlar sayesinde ağ cihazları sorunsuz şekilde haberleşmeyi sağlayabilirler.

    Ağ dünyasında hızlar bit’ler ile ölçülür. Disklerde ölçümler bayt’lar üzerinden yapılır. Bir bayt 8 bitten oluşur.

    • 1 Kilobit: 1.000 bit
    • 1 megabit: 1.000.000 bit
    • 1 gigabit: 1.000.000.000 bit
    • 1 terabit: 1.000.000.000.000 bit
    HızBilinen ismiIEEE StandartResmi ismiMaks uzunluğu
    10 MbpsEthernet802.3i10BASE-T100 m
    100 MbpsFast Ethernet802.3u100BASE-T100 m
    1 GbpsGigabit Ethernet802.3ab1000BASE-T100 m
    10 Gbps10 Gig Ethernet802.3an10GBASE-T100 m

    Ethernet standartlarında kullanılan bakır kablolar UTP (Unshielded Twisted Pair), Korumasız Bükümlü Çift kablolardır. Korumasız kelimesi tellerin elektriksel parazitlenmeye karşı savunmasız olmasından kaynaklanır.

    UTP Kablolar RJ-45 (Registered Jack) adı verilen sonlandırıcı bir konnektör ile biterler.

    Not: 10BASE-T ve 100BASE-T 8 kablonun tamamını da kullanmazlar. 1-2 ve 3-6 no’lu kabloları iletim ve geri alım için kullanırlar. 1000BASE-T ve 10GBASE-T tüm kabloları kullanılırlar. Kullandıkları çiftler sırasıyla 1-2, 3-6, 4-5, 7-8’dir. Bu çiftler Tx veya Rx diye adlandırılmazlar, hem alıcı hem de verici rolünü alırlar. Bu sayede 10BASE-T ve 100BASE-T’ye nazaran çok daha yüksek hızlara çıkabilirler.

    Not: Switch’ler 1-2 no’lu pinleri Rx (alıcı), 3-6 no’lu pinleriyse Tx (verici) olarak kullanır. Switch dışındaki bilgisayar ve router gibi son nokta cihazları ise bunun tam tersini (1-2 Tx, 3-6 Rx) uygularlar.

    Farklı kablo çiftlerinin kullanılmasındaki yegane sebep Full Duplex (aynı anda veri iletimi ve alımı yapılabilmesi) içindir.

    Eğer bir cihaz Switch’le bağlantı kuruyorsa Straight-through (Düz kablo) kullanır. Eğer bir switch başka bir switch’e bağlanıyorsa Crossover (Çarpraz) kablo kullanır. Yani tüm ağ cihazlarında geçerli olmak üzere eğer iki tarafta da aynı pinler kullanılıyorsa Crossover, farklı pinler kullanılıyorsa Straight-through kablo kullanılır. Ancak yeni nesil birçok ağ cihazı beraberinde Auto MDI-X özelliğiyle beraber gelir. Bu özellik cihazlar arasında istediğiniz kabloyu kullanmanıza olanak tanır.

    UTP kablolar LAN için yeterli sayılabilir fakat kıtalar arası kablolama da sınıfta kalacaktır. Bundan ötürü uzun mesafeli kablolama için iyi bir seçenek olan fiber-optik kablolar tercih edilir.

    Fiber kabloları router’a takmak için SFP Adı verilen bir modül kullanılır. SFP’ye fiber konnektörü takılır ve iletim bu sayede gerçekleştirilir.

    Small Form-factor Pluggable (SFP)

    Fiber kablolama da her bir kablonun içerisinde iki ayrı tel bulunur. Bunlar anlaşılabileceği üzere Tx ve Rx telleridir. Tx karşı tarafın Rx pinine, Rx’de karşı tarafın Tx pinine bağlıdır.

    Fiber kabloların yapısında,

    1. Fiberglas çekirdeği. Veri bu kısımdan aktarılır.
    2. Işığı yansıtan kaplama (cladding)
    3. Fiberglasın kırılmasını önleyen tampon
    4. Kablonun dış kılıfı

    Fİberoptik kablolarda kendi içlerinde ikiye ayrılırlar.

    • MMF (Multi-mode)
    • SMF (Single-mode)

    Ortadaki kısım çekirdeği, mavi kısım ise kaplamayı ifade eder.

    Single-mode (alttaki) çok küçük bir çekirdeğe sahip olduğu için ışık kırılmadan uzun mesafeler boyunca ilerleyebilir. Multi-mode kablolar daha kısa mesafelerde tercih edilir, single-mode kablolara nazaran daha ucuzdur. Çünkü single-mode kablolarda Lazer tabanlı vericiler tercih edilirken multi-mode kablolalarda LED tabanlı ucuz vericiler kullanır.

    Resmi adıIEEE StandartHızKablo tipiMaks uzunluğu
    1000BASE-LX802.3z1 GbpsSingle-mode ve Multi-modeMM: 550m
    SM: 5km
    10GBASE-SR802.3ae10 GbpsMulti-mode400m
    10GBASE-LR802.3ae10 GbpsSingle-mode10 km
    10GBASE-ER802.3ae10 GbpsSingle-mode30 km

    Kullandığım packet tracer sürümünde soldan sağa doğru düz kablo, çarpraz kablo, single-mode fiber ve multi-mode fiber Connections bölümünden seçilebiliyor.

    Oluşturduğum packet tracer simülasyonunda end point cihazlar ile switch’ler arasında düz kablo, switchleri kendi aralarında çarpraz kablo, switch’leri router’a bağlarken çarpraz kablo, router’ları bağlarken mesafeyi göz önüne alarak, R1-R2 arasında UTP (çarpraz kablo), R4-R3 arasında multi-mode fiber ve R1-R3 arasında single-mode fiber kablo kullandım.

    Son olarak,

    Özellik UTP (Bakır) Fiber-Optik
    Maliyet Daha düşük maliyet. RJ45 portları ve ekipmanları ekonomiktir. Daha yüksek maliyet. SFP portları ve modülleri (özellikle SMF) pahalıdır.
    Maksimum Mesafe Kısa mesafe (~100m sınırına sahiptir). Çok daha uzun mesafeleri destekler (kilometrelerce).
    Gürültü / Parazit (EMI) Elektromanyetik parazitlere (EMI) karşı savunmasızdır. Işık sinyali kullandığı için EMI parazitlerinden tamamen yalıtılmıştır.
    Güvenlik (Sinyal Sızıntısı) Kablo dışına zayıf bir sinyal yayar, bu durum sinyalin kopyalanma riskini doğurur. Kablo dışına herhangi bir sinyal sızdırmaz, bu nedenle dinlenmesi imkansızdır.

    şeklinde karşılaştırabiliriz.


  • NGINX ile Layer 7 Load Balancing

    Yük dengeleme algoritmaları büyük web sunucularının verimliliğini yönetebilmek için inanılmaz derece de önemli bir araçtır. Bu algoritmalar sayesinde sunucuların verimliğini arttırabilmenin yanı sıra güvenliğini de sağlayabiliriz. Bu alanda kullanabileceğimiz iki dominant web sunucu bulunuyor. İlki OSS ve Plus versiyonlarıyla sunulan NGINX diğeri ise tamamen açık kaynak olan Apache2 web sunucusu.

    Yazımda Nginx ile yapılandırmayı dökümantasyon üzerinden ilerleyerek açıklayacağım. İlerleyen yazılarımda NGINX’te olmayan özellikleri hangi ek araçları kullanarak ekleyebileceğimizi anlatacağım.

    İlk olarak load balancing’in genel mantığını, Layer 7 load balance uygulamalarının neler olduğunu, uygulamaların nasıl çalıştığını vb. anlatacağım.

    Yük Dengeleyici Algoritmaların Mantığı

    Yük dengeleyici algoritmalar temelde statik ve dinamik olarak ayrılıyorlar. Statik algoritmalar isminden de anlaşılacağı üzere gelen bağlantıları önceden belirtilen kurala bağlı olarak back-end sunuculara aktarıyor. Dinamik algoritmalar duruma, koşullara vb. etkenlere göre istemcinin istediği adrese ulaşabilmesinde farklı back-end sunucuları tercih edebiliyorlar.

    Statik Load Balancing Algoritmaları

    Statik algoritmalar 2 başlık altında incelenebilir.

    • Round Robin ve Weighted Round Robin
    • Hash Algoritmaları

    Hash algoritmaları farklı şekillerde olabilir. Örneğin, IP hash, generic hash ve consistent hashing.

    Round Robin ~ Weighted Round Robin

    Round Robin NGINX’te varsayılan olarak sunulur. Her isteği sıradaki sunucuya gönderir.

    Özel bir konfigürasyon gerektirmez. Konfigürasyon dosyasının içeriğine kullanacağımız back-end sunucularının adreslerini girip kapatırız, ardından diğer tüm yöntemlerde de yapacağımız gibi NGINX’i yeniler ve işlemi tamamlarız.

    Örnek olarak şunu uygulayabiliriz:

    Öncelikle ana yapıdan bahsedeyim. Kullandığım ortamda 2 Debian 1 adet Rocky makine kullanacağım. Debian makinelerden birini Load Balancer olarak konfigure edeceğim. Diğer makinelerin de /var/www/html/index.html dosyalarını uygulamamızı ayırt edecek şekilde BACKEND-1 DEBİAN ve BACKEND-2 ROCKY olarak işaretleyeceğim.

    • BACKEND-1 DEBİAN makineye ait IP: 192.168.216.234
    • BACKEND-2 ROCKY makineye ait IP: 192.168.216.20

    Sonrasında load balancer makinemize gidip /etc/nginx/conf.d/lb.conf dosyasını oluşturup içerisine şu ayarı yapalım.

    • proxy_pass, gelen isteğin hangi sunucuya iletileceğini belirler.
    • proxy_set_header, NGINX’in değiştirdiği ya da göndermediği bazı HTTP header’larını back-end’e iletmek için kullanılır.

    Sunucuyu yeniledikten sonra göreceğimiz muhtemel görünüm,

    gibi olacaktır. Başlangıçta üç defa Debian sunucuya giden istekler sonrasında bir Debian bir Rocky olarak sıralı gitmeye başladı. Başarılı şekilde Round robin algoritması tamamlandı.

    Buna ek olarak konfigürasyon dosyasında sunucuların güçlerine bağlı olarak weighted (ağırlık katsayısı) da belirtebiliriz.

    Mesela az önce oluşturduğumuz lb.conf içerisinde şu değişikliği yaparsak,

    Bu sefer isteklerimiz muhtemel olarak 5 e 1 olarak dağılım gösterecek.

    Deneyelim,

    Görüldüğü üzere ağırlık Rocky makinenin üzerinde oldu.

    Hash Algoritmaları

    Hash algoritmaları temel matematiğinde hash % back-end sayısı yatar.

    Hash, IP hashing özelinde IP adresinin 19216811 (192.168.1.1) şeklinde yazılıp back-end sayısına göre modunun alınmasına göre belirlenir. Bu da aynı IP’nin her geldiğinde aynı sunucuya gitmesini sağlar.

    Generic hashing, verilen herhangi bir değeri hash’leyip ona göre sunucu atamasını yapar. Bu değerler,

    • $request_uri
    • $remote_addr ( ip hashing’e benzeyebilir bu şekilde)
    • $http_x_forwarded_for
    • $cookie_jsessionid

    … gibi olabilirler.

    Consistent Hashing, diğerlerinden farklı bir probleme parmak basıyor. Diğer hashing algoritmalarında back-end sunucu sayısı değiştiğinde ortalık karışabilirdi. Consistent algoritması buna yönelik olarak,

    1. Bir m değeri belirlenip 2m2^m ile toplam uzay belirlenir.
    2. Elimizdeki node’lar (back-end sunucuları) rastgele dağılım göstererek bu uzaya yerleştirilir.
    3. Key değerini hash’leyip uzay içerisinde değere saat yönünde en yakın sunucuya bağlantı sağlanır.

    Dağılım bu şekilde yapıldığında çok daha küçük bir grup sunucuların eklenmesinden veya çıkartılmasından etkilenir .(diğer hashing algoritmalarına nazaran). Bu beraberinde bazı problemleri de getirir. Mesela, rastgele dağılım yapıldığı için kimi Node çok büyük bir alanı kaplayabilir ve bizim matematiğimize ters düşebilir. Bu durumda,

    Consistent hashing, virtual node denen bir kavram ile birlikte gelir. Normaldeki Node’lara eş yeni sanal Node’lar üretilir ve aralıklara dağıtımlar yapılır. Bu şekilde gelen hash değerin dengesiz gitmesi önlenir.

    Bunu denemek istersek,

    (ip adreslerim yazıyı farklı zamanlarda yazdığım ve yeni lab’lar kurduğum için farklılık gösteriyor)

    lb.conf dosyamızı düzenlememiz ve consistent parametresini eklememiz yeterlidir. NGINX kendi özelinde default olarak her bir sunucuya 160 virtual node ataması yapar (Nginx Plus kullanıyor olsaydık bu varsayılan değeri değiştirebilirdik).

    Not: Weighted parametresini de ekleyip konfigürasyonu yaptığımızda yeni oluşturulacak sanal node’lar o orana göre üretilir.

    Dinamik Load Balancing Algoritmaları

    Dinamik algoritmalar 2 başlık altında incelenebilir.

    • Least Connections (en az bağlantı ~ kullandığımız OSS sürümü itibariyle statik olarak da sayılabilir.)
    • Random with Two Choices

    Least connections, pratikte sunuculardaki toplam bağlantı sayılarını kontrol ederek bağlantı sayısı en az olan sunucuya yeni isteği gönderir. Uygulaması da OSS sürümde de desteği olduğu için oldukça kolaydır.

    İlk önce lb.conf dosyamıza ait bu kısmı şu şekilde güncelliyoruz:

    Ardından nginx sunucumuzu yeniden başlatıp curl ile istemci sunuculardan eşzamanlı (sunuculardan tek tek curl atarsak bu algoritmayı tam olarak denemiş olmayız) istek attığımızda karşımıza çıkan durum hemen hemen şunun gibi olacak.

    Eş zamanlı istek atmak için şu komutu kullanalım.

    bash
    user@linux:~$ seq 1 50 | xargs -n1 -P10 -I{} curl -s http://192.168.216.130 > sayim.txt
    user@linux:~$ less sayim.txt

    Herhangi bir Weighted katsayısı belirtilmediği için iki sunucuda hemen hemen eşit dağılım göstermiş.

    Bir diğer dinamik algoritmamız olan Random with Two Choices, temelde back-end saydığımız tüm sunucular arasından 2 sunucu seçip bağlantı sayısı az olana yeni isteği gönderir.

    Algoritmayı uygulamak için lb.conf dosyamıza şu değişiklikleri yapalım:

    Dosyayı kaydettikten sonra nginx’i her zamanki gibi restart edip başarılı bir şekilde konfigürasyonu yapalım. Ben elimdeki 2 back-end sunucuyu buraya yazdım, bu çok sağlıklı bir örnek olmadı. Bunun yerine 3’ten fazla sunucuyla bu denemeleri yapmak daha doğru olurdu.

    Sunucu Sağlık Kontrolleri

    Back-end sunucuların olası çökme veya yavaşlama durumlarına karşı bir takım sağlık kontrolleri bulunduruluyor. Bunlar da kendi içerisinde dinamik ve statik olarak ikiye ayrılıyor. Kullandığımız nginx open source sürümü yalnızca iki adet statik sağlık kontrolünü destekliyor. Bunlar,

    • max_fails: İsteklerin maksimum kaç defa 5xx hatası alacağını belirleyen parametre. Yeterince hata alındığında sunucuyu down ederiz.
    • fail_timeout: Sunucunun ne kadar süre down olacağını belirleriz.

    ikisini birlikte kullanırız. Örneğin,

    Geriye kalan aktif sağlık kontrollerinin tamamı Nginx Plus sürümünde bulunuyor.

    Son olarak Nginx’in worker process çalışma mantığından bahsetmek istiyorum.

    Genel olarak NGINX çalışma yapısında, bir MASTER cpu çekirdeği kadar worker’ı hizmete açar. Client’lardan gelen istekleri worker’lar kabul eder ve kendi verilerine göre back-end sunuculara iletirler. Normal şartlar altında bu işleyiş sorunsuz çalışabilir ancak yük dengeleme algoritması kuruyorsak worker’lar birbirleriyle haberleşemediği durumlarda bazı kötü sonuçlar doğurur. Bu kötü sonuçları engellemek için NGINX’te zone kavramı sunulmuştur.

    Zone, worker’ların birbirleri arasında veri paylaşımı yapabileceği alanlardır. Yani paylaşımlı bellek alanıdır. Bu paylaşımlı bellek alanında,

    • Fail timeout sayaçları
    • Load balancing sayaçları
    • Weight bilgisi (runtime state olarak)
    • Fail state (down / up durumu)
    • Her backend için aktif connection sayısı

    Zone’u aktif etmek için lb.conf dosyasında,

    ayarını yapmamız yeterlidir. Oluşturduğumuz zone 64 kb boyutunda bir alan kapsıyor.

    Özetle,

    • Active health check
    • Runtime API (reload’suz upstream ekleme/çıkarma, weight değiştirme)
    • Slow start
    • Gelişmiş monitoring dashboard

    gibi pek çok özellik OS sürümünde bulunmayıp yalnızca plus sürümünde bulunuyor. Bu da profesyonel manada bir load balancing algoritmasının yapılmasını ciddi derecede zorlaştırıyor. Bu durumu çözebilmek için,

    1. Nginx Plus satın alabiliriz 🙁
    2. 3.taraf modülleri indirip nginx’e entegre edebiliriz
    3. Openresty kullanarak LUA programlama diliyle Nginx’i Plus sürümünden de ileriye taşıyabiliriz.
    4. Haproxy gibi farklı load balancer sunucularını tercih edebiliriz.

  • Web (HTTP) Servis Yönetimi | LKD #4

    Bir önceki yazıda yaptığımız Virtual Host yapılandırmasını bu sefer de Debian Nginx makinesinde tekrarlayacağız.

    Debian NGINX Virtual Hosting

    Öncelikle ayarları yapacağımız /etc/nginx/sites-available dizinin altına gidip 2 yeni dizin oluşturalım. Ben bir önceki denememdeki isimleri koruyarak yeni dizinleri oluşturuyorum.

    kamp.linux.org.tr
    linux.org.tr

    Sonraki aşamada available dizininde kurduğumuz ayarların uygulanabilir olması için enable’a taşımamız gerekecek. Bunun için dosyalara sembolik linkleme yapıyoruz.

    bash
    user@linux:~$ sudo ln -s /etc/nginx/sites-available/kamp.linux.org.tr /etc/nginx/sites-enabled/
    bash
    user@linux:~$ sudo ln -s /etc/nginx/sites-available/linux.org.tr /etc/nginx/sites-enabled/

    Bu komutları girdikten sonra yapmamız gereken tek işlem /etc/hosts dosyasını düzenlemek olacak.

    /etc/hosts
    127.0.0.1 localhost
    ::1 localhost
    ip_adresiniz linux.org.tr kamp.linux.org.tr

    Bu işlemi yaptıktan ve sistemi restart ettikten sonra curl ile denemelerimizi yapıyoruz.

    Başarılı bir şekilde tamamladık.

    Debian NGINX WordPress Ayaklandırma

    Şimdi bir NGINX sunucunda sıfırdan bir WordPress sitesi kuracağız. Siteyi kurarken PHP-FPM ve MariaDB kullanacağız. MariaDB kurmamız, wordpress MySQL kullanıyor olsa bile, MariaDB ve MySQL’in tamamen uyumlu olarak çalışmasından geliyor.

    İlk olarak paketleri indirerek başlayalım.

    bash
    user@linux:~$ sudo apt install nginx mariadb-server php-fpm php-mysql php-curl php-gd php-intl php-mbstring php-soap php-xml php-xmlrpc php-zip -y

    Paketler indikten sonra MariaDB’ye gidip root olarak oturum açalım.

    Ardından veritabanında sırasıyla aşağıdaki ayarları yapıp veritabanından çıkış yapalım.

    bash — MariaDB
    user@linux:~$ sudo mysql -u root -p
    MariaDB [(none)]> CREATE DATABASE wordpress_db DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
    MariaDB [(none)]> CREATE USER ‘wp_admin’@’localhost’ IDENTIFIED BY ‘SeninSifren123!’;
    MariaDB [(none)]> GRANT ALL PRIVILEGES ON wordpress_db.* TO ‘wp_admin’@’localhost’;
    MariaDB [(none)]> FLUSH PRIVILEGES;
    MariaDB [(none)]> EXIT;

    Bir sonraki aşamada wordpress’i sunucumuza kurmak için wordpress’ten latest.zip dosyasını indirelim.

    bash — wget
    user@linux:~$ wget https://wordpress.org/latest.zip

    Dosyayı tmp dizinine çekip orada zip’ten çıkartalım.

    bash — unzip
    user@linux:~$ unzip latest.zip

    Elde ettiğimiz wordpress dizinini /var/www altına taşıyalım.

    bash — cp
    user@linux:~$ sudo cp -a /tmp/wordpress/. /var/www/wordpress/

    WordPress kullanıcı ve grubumuzu düzenleyelim.

    bash — chown
    user@linux:~$ sudo chown -R www-data:www-data /var/www/wordpress

    Bunu yaptıktan sonra WordPress, varsayılan olarak wp-config-sample.php adında bir örnek dosya ile gelir. Biz bunu asıl ayar dosyamıza kopyalıyoruz: wp-config.php

    bash — cp
    user@linux:~$ sudo cp wp-config-sample.php wp-config.php

    Dosya içerisindeki bilgileri kendi veritabanımıza göre düzenleyip kaydedip çıkalım.

    Bu işlemi de tamamladıktan sonra sistemimizi yeniden başlatıp tarayıcıdan adresimize (localhost) gidelim.

    Başarılı bir şekilde wordpress sitemizi ayaklandırdık. Karşılaşabileceğimiz sorunlara karşı daima İngilizce kurulum yapmamız öneriliyor.

    Bu noktada Doruk Hoca belli noktalardaki problemlere değindi, wordpress sitemize nasıl dosya yükleyeceğimiz, dosya boyutunu nasıl arttıracağımız gibi…

    Bu problemi çözmek için yaptığımız araştırmalardan sonra sunucuda kullanılan PHP-FPM uygulama sunusunda yer alan bir kısıtlama sonucu oluştuğunu belirledik.

    Bu durumu çözmek için ilgili uygulama sunucusunun nasıl çalıştığını ve hangi kaynakta konfig edilebildiğini belirledik, bu adres /etc/php/8.1/fpm/php.in .

    Düzenlememiz gereken iki yer olduğunu keşfettik.

    İlki , post_max_size değişkeniydi. Tek seferde ne kadar veri göndereceğimizi belirleyen bir değişken. Bunu 64M olarak güncelledim.

    Diğeri ise, yüklenecek maksimum dosya boyutunu belirleyen upload_max_filesize değişkeniydi, bunu da 64m olarak güncelledim.

    İkisi de güncelleyip php servisini yeniden başlattığımda problemin çözüldüğünü, yeni boyutun 64M olduğunu gördük ve sorunu çözdük.

    Burada farklı kurulumlarda farklı problemler çıktığını, bu problemlerin de ilk gün anlatılan istemci-sunucu modelinin bir parçası olduğunu anlıyoruz. Örneğin web sunucusu tarafında dosya boyutu için 16M belirlenmiş olsun. Biz php uygulama sunucusunda boyutu kaç yaparsak yapalım aktarılabilecek maksimum veri 16M olacaktır.

    Reverse Proxy

    İnternet ağlarının filtrelenmesi, bazı sitelerin kısıtlanması, yük dengelenmesi vb. birçok noktada kullandığımız ters proxy aslında istemci ve sunucu mimarisinin bir nevi yer değiştirmesidir.

    İstemciler bir sunucuya gitmek istediklerinde onları doğrudan o siteye götürmek yerine araya bir “aracı sunucu” koyarak istemcinin muhattabını aracı sunucu olarak belirleriz.

    Bunu güvenlik,

    • Saldırganlara karşı IP adresini doğrudan göstermeme
    • Rate limit (Olası ddos saldırılarına karşı IP başına bir deneme hakkı koyma işi)
    • Firewall katmanı

    cache (önbellek) alma ,çok sık tıklanan sayfaları hafızaya atmak, SSL sertifikası doğrulama yükünü ara sunucuya verip sunucuları bu yükten kurtarmak gibi amaçlarla kullanabiliriz.

    Normal proxy sunucularından farkı görünüşte istemciyi değil sunucuyu korumasıdır.

    Forward Proxy yani bizim normal bildiğimiz proxy de istemci tarafın ip adresi gizlenir, yasaklı siteler filtrelenir… gibi işler yapılır.

    ÖzellikForward ProxyReverse Proxy
    Gizlenen TarafİstemciSunucu
    İşlevİnternete çıkarİnterneti filtreler
    AyarlamaKullanıcı kendi yaparKullanıcının durumdan haberi olmaz
    Örnek kullanımFiltrelemeLoad balancing (yükdengeleyici)

    Başta Doruk ve Gökhan hocalarım olmak üzere kampta emeği geçen herkese teşekkür ederim.


  • Web (HTTP) Servis Yönetimi | LKD #3

    SSL sertifikaları web sitelerine istemcilerin güvenle giriş ve veri aktarımı yapmasını olanak sağlayan aracılardır. SSL temelde iki temel işlevi yerine getirir.

    • Şifreleme
    • Kimlik doğrulama

    Bu işlevleri yerine getirecek SSL sertifikalarının güvenilir sertifika otoriteleri tarafından imzalanması gerekir. Bu bir nevi kefil olma işlemidir. Sertifika otoritelerinin güvenilir olup olmadığına da pratikte web tarayıcılar karar verirler.

    Süreç nasıl işliyor?

    1. İstek Oluşturulur: Sunucu tarafında bir sertifika imzalama isteği (CSR) üretilir.
    2. Otoriteye Gönderim: Bu istek doğrulanmak üzere otoriteye iletilir.
    3. İmzalama: Otorite, kendi anahtarıyla isteği imzalayıp sunucuya geri verir.
    4. Güncelleme: SSL sertifikası sunucuya yüklenerek aktif edilir.

    SSL sertifikaları otoriteler tarafından çok çok fazla ücretlere yenilenebiliyor, yani yenilenebiliyordu. Günümüzde çoğu web sitesi Let’s Encrypt‘in sunduğu SSL hizmeti sayesinde ücretsiz olarak sertifika alıp güncelleyebiliyorlar.

    Let’s Encrypt siteyi doğrulamak için iki basit yöntem kullanıyor.

    • Web sitesinde kendilerinin oluşturduğu bir html sayfasını yayınlayıp sitenin size ait olduğunu doğrulamanız
    • DNS kaydına sitenin size ait olduğunu doğrulayan bir ifade bırakmanız.

    Kullandığı yöntemlerle de günümüzdek sertifika otoritelerinin büyük bir bölümüne kıyasla çok daha yüksek bir güvenlik sağlayabiliyor.

    Let’s Encrypt ürettiği sertifikaları 90 günlük olarak sağlıyor, 90 günün sonunda otomatik olarak yenilemenize imkan sağlıyor (bu da sertifika otoritelerinin sağlamadığı bir hizmettir). Diğer sertifika otoritelerinden alınan sertifikaların ise belirlenen süre sonunda kullanıcı tarafından elle yeniden doğrulanması ve sisteme manuel olarak tanımlanması gerekmekte :/

    HostName Değişimi

    Web sunucularını yönetirken IP adreslerini kullanmak yerine doğrudan isimlerle çalışmayı tercih edebiliriz. Bu işlemi tek komutla gerçekleştirebiliriz.

    Hostname’i değiştirmek için,

    bash
    user@linux:~$ hostnamectl set-hostname vermek_istediginiz_isim

    komutunu yazıyoruz ardından doğrulamak için,

    bash
    user@linux:~$ hostname -f

    komutunu girip doğru şekilde uygulandığını görüyoruz.

    Bu adresi kullanabilmek için /etc/hosts dosyasına da aşağıdaki düzenlemeyi yapmamız gerekiyor.

    Not: Döngüsel ip (127.0.0.1) ‘i kapattım. Sebebi hata almamdı 🙁 Şöyle ki, aynı hostname birden fazla ip adresi ile çakışmamalıymış, bu bize hata getirirmiş…

    Ayrıca bu işlemi yaptıktan sonra sistemi yeniden başlatmakta fayda var. Çünkü kimi uygulamalar hostname kullanarak çalışıyor olabilir, tek tek hangi uygulama kullanıyor araması yapmaktansa sistemi yeniden başlatıp doğru değerlerle çalışmalarını sağlayabiliriz.

    Sistemi yeniden başlatmasak da hostname güncellenmiş olacaktır.

    SSL Sertifikalarının Üretimi

    2 farklı sistemde ve 2 farklı web sunucusunda toplamda 4 adet SSL sertifikasının nasıl üretildiğine bakalım ve aradaki farkları inceleyelim.

    • Debian Apache
    • Debian Nginx
    • Rocky Apache
    • Rocky Nginx

    Debian Apache2 SSL

    İlk aşamada kullanacağımız openssl paketlerinin bulunup bulunmadığına bakalım.

    bash
    user@linux:~$ which openssl

    Benim sistemimde ” /usr/bin/openssl “‘de bulunuyordu. Bulunmasaydı,

    bash
    user@linux:~$ sudo apt install openssl -y

    İlk önce openssl’i kullanarak key’i üretelim. Alan adlarına /etc/hosts dosyasına yazdığımız alan adımızı gireceğiz. Key’i üretmeden önce /etc/apache2/certs adında bir dizin oluşturup oraya gidelim. Çünkü az sonra gireceğimiz komut bulunduğu dizinde crt ve key üretecektir.

    bash
    user@linux:~$ openssl req -x509 -nodes -newkey rsa:2048 -keyout verdigimiz_alan_adi.key -out verdigimiz_alan_adi.crt

    İlgili dizine gidip kontrol edelim.

    Şimdi ürettiğimiz sertifikayı sitemize uygulamak için ” /etc/apache2/sites-available “dizinine gidip ” 000-default.conf ” dosyasında değişiklikleri yapalım.

    Bu işlemden sonra dosyayı kaydedip kapatalım. Bir hata yaptık mı kontrol etmek için,

    bash
    user@linux:~$ apache2ctl -t

    Syntax OK ” çıktısını aldıysak devam edebiliriz. Portları dinleyelim.

    bash
    user@linux:~$ ss -tulnp

    En alt satırda 443’ün de dinlendiğini görüyoruz, sitemizi kontrol edelim.

    Başarılı şekilde SSL sertifikamız sitemize uygulandı.

    Rocky Apache2 SSL

    Sertifikayı üretmek için gerekli paketleri indirelim.

    bash
    user@rocky:~$ sudo dnf install mod_ssl -y

    Ardından paketleri listeleyelim.

    bash
    user@rocky:~$ rpm -ql mod_ssl

    Sertifikamızı doğrulamak için,

    bash
    user@rocky:~$ curl https://localhost

    Bu uyarı sertifikanın dünyaca tanınan bir otorite tarafından değil, bizim tarafımızdan oluşturulduğunu gösterir mahiyette bir uyarı.

    Biz oluşturduğumuz SSL sertifikasını web sitesine uygulamakta başarılı olduk.

    Biz Debian dağıtımında Rocky’e nazaran daha fazla uğraştık bunun sebebi, Rocky sunucularında sscg aracı sayesinde çok hızlı bir şekilde sunucuyla birlikte SSL sertifikası üretebiliyor olmamızdır.

    Rocky Nginx SSL

    Burada farklı olarak işimizi kolaylaştırmak için bir Apache2 paketi olan mod_ssl’i kuracağız.

    bash
    user@rocky:~$ sudo dnf install mod_ssl -y

    Kurduktan sonra inen paketleri listelediğimizde /usr/libexec/httpd-ssl-gencerts inceliyoruz ve otomatik olarak SSL sertifikaları üretmemize yarayan bir script olduğunun farkına varıyoruz.

    Scriptini çalıştırmadan önce içerisine bir göz atalım, oluşturacağı key ve crt dosyalarını nereye koyuyormuş ona bakalım.

    Burada gördüğümüz üzere,

    • crt dosyası, /etc/pki/tls/certs/localhost.crt
    • key dosyası, /etc/pki/tls/private/localhost.key

    konumlarında bulunuyorlar.

    Scripti çalıştıralım.

    bash
    user@rocky:~$ sudo /usr/libexec/httpd-ssl-gencerts

    Sonrasında nginx.conf dosyamızın içine gidip SSL ayarlarını aktif edelim.

    bash
    user@rocky:~$ sudo systemctl stop firewalld

    Not: Firewall açık kalmış olabilir. Hata almamak için kapatıyoruz.

    Curl kullanarak veya tarayıcı üzerinden denemesini yaptığımızda, başarılı bir şekilde SSL sertifikamızı uyguladığımızı görüyoruz.

    Debian Nginx SSL

    Openssl’in kurulu olup olmadığını kontrol edelim.

    bash
    user@linux:~$ which openssl

    Benim sistemimde kuruluydu.

    /etc/nginx altında certs adında bir dizin oluşturuyoruz. Ardından oraya gidiyoruz.

    openssl ile sertifikayı üretiyoruz.

    bash
    user@linux:~$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout mehmet.myguest.org.key -out mehmet.myguest.org.crt

    /sites-available/default dosyasını açıp değişiklikleri uygulayalım,

    return 301 https://$host$request_uri; satırıyla yapılacak tüm bağlantıları https’e yönlendirdik. Bu da http://site ile yapılacak bağlantıların da https olacağını gösterir.

    curl ile denemeyi yaptığımızda,

    301’i gördük.

    Başarıyla ürettiğimiz tüm SSL sertifikalarını da sitelerimize uygulamış olduk.

    Virtual Hosting

    Aynı IP üzerinde birden fazla hosting barındırabiliriz buna da ” virtual hosting ” deriz. Bunu oluşturmak için ilk önce Debian Apache makinemizde /etc/httpd/conf.d yolu altında iki adet virtual host dosyası oluşturuyorum.

    kamp.linux.org.tr.conf
    linux.org.tr.conf

    Ardından /var/www/kamp ve /var/www/linux’a gidip burada varlığını belirttiğimiz dosyaları oluşturalım.

    /var/www/kamp/index.html

    Merhaba kamp

    /var/www/linux/index.html

    Merhaba linux

    Bunları da tamamladıktan sonra /etc/hosts dosyasına gidip sanal hostlarımızı kaydedelim.

    Curl ile deneyelim,

    Virtual hosting yapılandırmasını başarıyla tamamladık.

    Bazı detaylar,

    • IP adresi ile curl atmaya çalıştığımızda,

    gördüğümüz üzere ilk eklediğimiz .conf dosyasının host’u çalışıyor.

    Konumuzla çok alakası yok ancak bilgisayar dns çözümlemesi yaparken neden önce /etc/hosts dosyasına bakar sorusunun cevabı,

    burada yer alan /etc/nsswitch.conf dosyasıdır.

    Devamını okumak için…


  • Web (HTTP) Servis Yönetimi | LKD #2

    Web sunucularının tarihi 90’lara dayanır. O dönemde en popüler web sunucusu, Rob McCool tarafından geliştirilen NCSA HTTPd çekiyordu. Ancak 1994’te McCool projeyi bırakıp Netscape’e geçince, sunucu yazılımı bir anda sahipsiz kaldı.

    NCSA HTTPd desteğini yitirince, topluluk bu kodu patch’leyerek (yamalayarak) “A Patchy Server” yani Apache’yi ortaya çıkardı ve zamanla bu yapı dev bir vakfa dönüştü. Apache 1’den Apache 2’ye geçiş sürecinde sistem çok yavaşlayınca, bu hantallığa tepki olarak yüksek performanslı Nginx doğdu; ancak zamanla Nginx de benzer karmaşık modülleri ve yenilikleri bünyesine katarak o da yavaşlamaya başladı. Günümüzde rekabet sürüyor.

    İlk önce Debian ve Rocky makinelerimize Nginx kurarak başlayalım.

    Kurulum Aşaması

    Paketleri yüklemek için 2 farklı seçeneğimiz bulunuyor:

    • Doğrudan üreticinin deposundan son sürümü indirip kurabiliriz.
    • Kullandığımız dağıtımın paket depolarında bulunan sürümü indirip kullanabiliriz, bunun dezavantajı daima güncel sürümün paket depolarında bulunamaması olabiliyor.

    Kullanacağımız yönteme göre dosyaların kurulumları, konfigürasyonları farklılık gösterebilir.

    Güvenliği, kullanılabilirliği düşündüğümüzde doğru tercih paket deposunu tercih etmek olacaktır.

    Sürümlerde,
    Stable sürüm (çift haneliler) uzun süre destek verilen sürümlerdir. (LTS ile aynı mantıkta)
    Mainline sürüm (tek haneliler) şu anda test edilen sürümlerdir. (LTS olmayanlar)

    Dikkat, burada Apache ve Nginx sunucularında bir port çakışmaması yaşanmaması adına Apache kurduğumuz sanal makinenin aksine yeni bir sanal makineye Nginx kuracağız.

    Debian NGİNX Kurulumu

    Güncellemeleri yaparak başlıyoruz.

    bash
    user@linux:~$ sudo apt update && sudo apt upgrade -y

    Kurulum öncesinde kuracağımız Nginx sürümünü öğrenmek için,

    bash
    user@linux:~$ apt info nginx

    yazarak

    çıktısını alıyoruz. Bu şekilde indirilecek sürümü, bağımlılıkları… öğrenebiliyoruz. (Ben daha önce indirdiğim için çıktı farklı olacaktır.)

    bash
    user@linux:~$ sudo apt install nginx -y

    Kurulan paketleri listelemek için:

    bash
    user@linux:~$ dpkg -L nginx

    Burada service dosyalarını göremedik çünkü, Nginx’in servis dosyası, paket parçalama stratejisi gereği ortak dosyaları içeren nginx-common paketiyle birlikte gelir ve genellikle /lib/systemd/system/nginx.service yolunda bulunur.

    Rocky NGİNX Kurulumu

    Kuracağımız paketler hakkında bilgi almak için aşağıdaki komutu çalıştıralım.

    bash
    user@rocky:~$ dnf info nginx

    Kurmak için,

    bash
    user@rocky:~$ sudo dnf install nginx -y

    Çalıştıralım. Ardından kurduğumuz sunucunun durumunu kontrol etmek için komutları çalıştıralım.

    bash
    user@rocky:~$ sudo systemctl start nginx
    user@rocky:~$ sudo systemctl enable nginx
    user@rocky:~$ rpm -ql nginx
    user@rocky:~$ _

    Apache Ayar Dosyaları

    Rocky

    Rocky ile başlayalım. Kurulumlar /etc/httpd altında.

    Burada ve farklı kurulumlarda .d dosyaları, ana konfigürasyon dosyasına (örneğin nginx.conf) dokunmadan, dışarıdan uygulama veya modül bazlı ayarların bir klasör içine ayrı dosyalar halinde atılmasına olanak tanıyarak sistem yönetimini kolaylaştırır.

    httpd.conf Dosyası

    Web servisine ait ana ayarların yapıldığı dosyadır.

    Burada kök dizinimiz /etc/httpd olarak belirlenmiş, yani konfigürasyonun ilerleyen aşamasında tam yolu verilmeden tanımlanan bütün dizinlerin yeri burası olacaktır.

    Yönettiğimiz tüm servisleri yeni bir kullanıcı oluşturarak yönetiriz. Bu kullanıcı tek bir servisten sorumlu olmalıdır. Aksi taktirde çeşitli erişim ve güvenlik problemleri yaşanabilir. Örneğin Apache servisiyle MySQL servisi için tek bir kullanıcı belirlersek ilerleyen aşamalarda farklı dosyalarda güvenlik ile ilgili problemler baş gösterebilir.

    <Directory>, ile birer blok tanımı yaparız. Directory’nin yanında yazan index’te geçerli ayarları tanımlar. Eğer yanında özel bir index belirtmezsek bu ayarlar tüm dizinlerde geçerli olacak şekilde yapılandırılır.

    İndex belirttiğimizde, örneğin:

    Bu blok “/var/www”de geçerlidir. Özetle, bu yapı dizin bazlı özel ayarlamalar yapmamıza imkan sağlar.

    Burada da belirtilen, AllowOverride temelde şu anlama gelir, Apache’nin ana konfigürasyon dosyasındaki ayarların, web dizinleri içindeki .htaccess dosyaları tarafından geçersiz kılınıp kılınamayacağını belirleyen bir yapıdır. “None” ve “All” olmak üzere 2 seçeneği vardır.

    • AllowOverride None, ile .htaccess dosyaları tamamen yok sayılır. Tüm konfigürasyonlar ana dosyalardan yapılır.
    • AllowOverride All, ile .htaccess dosyaları konfigürasyon dosyalarında bulunan ayarları yok sayıp kendi kurallarını uygulatırlar.

    Dökümantasyonda .htaccess dosyalarının performansı düşürdüğüne ve bu sebepten bu yapı yerine directory kullanmanın avantajlı olduğuna dair bir not var. Bunun sebebi sunucu, her dosya isteğinde (bir resim, bir HTML sayfası vb.) o dizine ve tüm üst dizinlere bakıp .htaccess dosyası var mı diye kontrol eder. Bu da her “tık” için fazladan disk okuma işlemi demektir.

    Buradaki FollowSymLinks ifadesi sembolik bağlantılara izin verildiğini gösterir.

    Sembolik bağlantılar işimize nerede yarıyor:

    Kısaca bu ayar, bir dosya veya dizin asıl yerinde olmasa bile, sembolik bir bağ aracılığıyla ona erişilmesini sağlar. Bazı dezavantajları da bulunur, bu sebepten kapatılması da bazı sistem yöneticileri tarafından tercih edilebilir. Özellikle paylaşımlı sunucu ortamlarında, saldırganların sistem dosyalarına erişmesini engellemek için bu özellik devre dışı bırakılır veya kısıtlanır.

    Burada istemci için bir karşılama dosyası belirliyoruz. Web sitesine giriş yapıldığında ilk açılacak dosyayı bu ayarla belirleriz.

    Bu kısımda log’ların ne formatta tutulacağı belirlenir. access.log da başarılı ya da başarısız tüm loglar bulunur.

    Burada access.log tutmak için 2 farklı seçeneğimiz bulunuyor common ve combined. Combined farklı olarak Referer ve User-Agent bilgisi de tutar.
    Bu bilgilerin tutulması 5651 sayılı kanuna uyulması için önemlidir.

    Log level warn, Hangi durumlarda hata uyarısı verilir şeklinde.
    Possible values include kısmı derecelendirme içerir. En önemli durum en sondadır. Mesela error seçildiğinde error, crit, alert ve emerg loglanır.

    Referer, istemcinin hangi web sayfasından geldiğini söyler. Mesela farklı bir site üzerinden geldiyse referer bunu doğrudan belirtir. Eğer aynı sitede farklı bir sayfadan geldiyse referer, sayfayı da ekleyerek bunu belirtir.

    User-Agent, istemcinin kullandığı cihaza ait bazı bilgileri içerir. Örneğin,

    Mozilla/5.0 (iPhone; CPU iPhone OS 17_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Mobile/15E148 Safari/604.1 “.

    Referer ve User-Agent bilgisi tarayıcıda saklanır. Buna bağlı olarak kullanıcı tarafından değiştirilebilir, bu sebepten sunucu tarayıcıdan gelen bilgilere güvenmemelidir.

    alias_module sayesinde sunucunun dosya sistemindeki fiziksel bir klasörü, web sitesindeki sanal bir yola eşlemesi mümkün olur. Örneğin,

    Alias kullanarak sunucuya şunu dersin: “Ziyaretçi /resimler yoluna gitmek isterse, onu ana web klasörümün dışındaki /mnt/depo/gorseller klasörüne yönlendir.”.

    Sunucuya hangi çeşit dosyayı ne şekilde açacağını söyleyen bir rehberdir. Mesela,

    Sunucu, .Z, .gz veya .tgz uzantılı bir dosya gönderirken tarayıcıya “Bu bir sıkıştırılmış arşiv dosyasıdır” etiketini yapıştırır. Bu sayede tarayıcı, dosyayı bir metin gibi açmaya çalışmak yerine düzgün bir şekilde indirir veya uygun programla açar.

    Hangi hata mesajında hangi sayfa gösterilecek kısmıdır. İlgili hatalar için http return kodları kullanılır.

    Konfigürasyonun son satırında da conf.d’yi konfigürasyon dosyasına uygulatıp kapatıyoruz.

    Debian Apache2

    Apache2 kurulumu /etc/apache2 dizini altında bulunur.

    Burada ilk olarak dikkatimizi available-enabled çiftleri çekiyor.

    Available klasörleri tüm olası yapılandırma dosyalarının tutulduğu bir kütüphane görevi görürken, Enabled klasörleri sunucunun o an aktif olarak kullandığı yapılandırmaları belirtir. Enabled kısmındaki dosyalar sembolik linkler ile Available’dan bağlanmıştır.

    Burada Debian tabanlı dağıtımlarda kullanabileceğimiz, işimizi kolaylaştıran birkaç komut vardır.

    • a2enconf: Genel sunucu ayarlarını aktif etmek için kullanılır.
    • a2disconf: Genel sunucu ayarlarını inaktif hale getirmek için kullanılır (Sembolik bağlantı siler)
    • a2enmode: Modülü aktif eder.
    • a2dismode: Modülü inaktif eder.
    • a2ensite: Web sitesini yayına alır.
    • a2dissite: Web sitesini yayından alır.

    Sembolik bağlantıları düzenlemek için bu komutları kullanabiliriz. Syntax ” komut ilgili_dosya ” şeklindedir.

    Apache konfigürasyonunda genel yapı şu şekilde,

    userdir.conf dosyasında da her kullanıcı için özel bir kişisel web alanı açan ayarları içeren yapıdır. Ancak günümüzde pek tercih edilen bir yapı değildir.

    ports.conf dosyasında da Apache’nin hangi portları dinleyeceğini ve hangi IP adreslerinden gelen isteklere yanıt vereceğini belirleyen dosyadır.

    apache2.conf
    • Timeout 300 : Sunucunun bir isteği tamamlamak için bekleyeceği maksimum süredir. Eğer 5 dakikanın sonunda veri alışverişi olmazsa sunucu bağlantıyı koparır.
    • KeepAlive On : Aynı istemcinin (örneğin bir tarayıcı) birden fazla isteği (resimler, CSS dosyaları vb.) tek bir bağlantı üzerinden göndermesine izin verir.
    • MaxKeepAliveRequests 100 : Tek bir “KeepAlive” bağlantısı üzerinden yapılabilecek maksimum istek sayısını belirler. Burada 100 olarak ayarlanmış; yani bir bağlantı üzerinden 100 dosya alındıktan sonra bağlantı kapatılır ve yenisi açılır. Sınırsız yapmak için 0 verilebilir.
    • KeepAliveTimeout 5 : Sunucunun, mevcut bir bağlantıyı kapatmadan önce yeni bir istek gelmesi için bekleyeceği süredir (saniye). Eğer kullanıcı 5 saniye boyunca yeni bir şeye tıklamazsa veya bir dosya istemezse, sunucu bağlantıyı sonlandırır.

    Bu ayar, sunucunuza bağlanan ziyaretçilerin log dosyalarına nasıl kaydedileceğini belirler:

    • Off (Kapalı): Ziyaretçiler sadece IP adresleri ile kaydedilir
    • On (Açık): Sunucu, her IP adresinin hangi alan adına (hostname) ait olduğunu bulmak için bir DNS sorgusu yapar ve ismi kaydeder

    Bu kısımda Apache HTTP sunucusunda düzenli ifadeler (regex) kullanarak ismi “.ht” ile başlayan hassas yapılandırma dosyalarına (örn. .htaccess, .htpasswd) HTTP protokolü üzerinden gelen tüm istemci taleplerini “403 Forbidden” yanıtıyla reddeder.

    Görseldeki LogFormat satırlarında yer alan bazı önemli ifadelerin karşılıkları şunlardır:

    • %h (Remote Host): İsteği gönderen istemcinin IP adresidir.
    • %l (Remote Logname): İstemcinin kimliği (genelde - olarak görünür).
    • %u (Remote User): Eğer HTTP kimlik doğrulaması yapılmışsa kullanıcı adı.
    • %t (Time): İsteğin alındığı zaman damgası.
    • %r (First line of Request): İsteğin ilk satırı (Örn: GET /index.html HTTP/1.1).
    • %>s (Status): Sunucunun döndüğü durum kodu (Örn: 200, 404).
    • %O (Bytes Sent): Başlıklar (headers) dahil olmak üzere gönderilen toplam bayt miktarı.
    • %{Referer}i: İstemcinin bu sayfaya hangi adresten geldiğini gösteren “Referer” başlığı.
    • %{User-Agent}i: İstemcinin kullandığı tarayıcı ve işletim sistemi bilgisi.
    • %v: İsteğin yapıldığı sunucun adı (Virtual Host).
    • %p: İsteğin geldiği port numarası.

    Debian NGINX

    Kurulumlar /etc/nginx altında bulunur.

    NGİNX.conf

    gzip on; : Aktif edildiğinde, sunucu HTML, CSS ve JavaScript gibi metin tabanlı dosyaları sıkıştırarak gönderir.

    Bu ayarlar, Nginx web sunucusunun modüler bir yapıda çalışmasını sağlayarak farklı klasörlerdeki yapılandırma dosyalarını otomatik olarak ana ayarların içine dahil eder.

    Bu yapı sayesinde birden fazla web sitesini tek bir sunucu üzerinden canlandırabiliriz.

    Rocky NGINX

    Kurumlar /etc/nginx altında bulunur.

    Sunucunun ağ trafiği kapasitesini belirler; bu ayara göre her bir işlemci çekirdeği (worker) aynı anda en fazla 1024 bağlantıyı yönetebilir.

    Yani eğer sunucunda 1 tane worker process (işlemci çekirdeği) çalışıyorsa, aynı anda en fazla 1024 bağlantı kabul edilebilir. 1025. kişi gelirse, sunucu “meşgul” yanıtı döner veya bağlantıyı reddeder.

    Log Formatı

    Varsayılan web sunucusu tanımlanır. Hem ıpv4 hem de ıpv6 için ayarlar kabul edilir.

    Devamını okumak için…


  • Web (HTTP) Servis Yönetimi | LKD #1

    Web (HTTP) Servis Yönetimi | LKD #1

    4-8 Şubat 2026 tarihleri arasında Linux Kullanıcıları Derneği tarafından düzenlenen Mustafa Akgül Özgür Yazılım Kış Kampı’nda Web (HTTP) Servis Yönetimi’nde Doruk Fişek ve Gökhan Çuryan hocalarımdan aldığım ders notlarımdır.

    İstemci – Sunucu Mimarisi

    Web dünyası temelde istemci – sunucu arasındaki karşılıklı taleplere dayanır.

    1. İstemci (Client) Katmanı

    İstemci, sunucudan hizmet talep eden taraftır.

    Örnekler: Chrome, Mozilla Firefox, Brave tarayıcıları veya komut satırı aracı olan curl.

    Çalışan Teknolojiler: HTML, CSS, JavaScript (React, Svelte gibi kütüphaneler bu katmanda yer alır).

    2. Sunucu (Server) Katmanı

    Sunucu, hizmet sunan ve gelen isteklere geri dönüt (response) veren taraftır. Örneğin; Nginx, Apache…

    Örnekler: Nginx, Apache.

    Görev: Gelen talebi doğrudan yanıtlar veya ek bir uygulama sunucusu aracılığıyla çalıştırır.

    Protokol: İstemci ve sunucu arasındaki iletişimi sağlayan kurallar bütünüdür. Web servislerinin temel dili HTTP protokolüdür.

    3. Uygulama Sunucusu Katmanı

    İş mantığının yürüdüğü ve sunucuda çalışan teknolojilerin barındığı katmandır.

    Çalışan Teknolojiler: Java, PHP, Node.js, Python (Django).

    Java için Tomcat, Python için WSGI (Gunicorn/Uvicorn) protokolü kullanılan yapılara ek olarak; PHP tarafında PHP-FPM, Ruby için Puma örnek olarak verilebilir.

    4. Servis Katmanı

    Servisler, uygulamanın temel fonksiyonlarını yerine getirmesini sağlarlar. Örnek olarak DNS, DHCP, veritabanları (MsSQL, PostgreSQL, MySQL…) verilebilir.

    Katmanlar Arası İletişim ve Veri Transferi

    Unix Socket

    Aynı sunucu üzerindeki iki farklı sürecin (örneğin Nginx ile bir Python uygulaması) haberleşmesi için kullanılan bir IPC (Inter-Process Communication) metodudur. Hızından ötürü öncelikli tercih edilse de, tüm uygulamalar bunu kullanmak zorunda değildir. Mesela JAVA uygulamaları genellikle Unix Socket yöntemini tercih etmez.

    HTTP Request Metotları (GET vs. POST)

    İki web sayfası arasındaki değişkenleri aktarmak istesek iki farklı yöntem ile bunu yapabiliriz.

    • GET: Değişkenler URL yapısına (Örn: .../gonder.html?i=8&j=8) eklenir. Tekrar bakılmak istenen isteklerde (bookmark, geçmiş) tercih edilir ancak bir uzunluk sınırı vardır. HTTPS kullanımında URL’deki ana adres açıkta giderken, parametreler şifrelenir.

    Not: Alan adının şifrelenmeden gönderilmesinin nedeni; sunucu, aynı IP üzerindeki birden fazla site arasından hangisinin SSL sertifikasını kullanacağını seçebilmektir. Bundan ötürü de alan adı “plaintext” (açıkça) gönderilir.

    • POST: Veriler GET metodundan farklı olarak bir “body” (gövde) bölümüyle gönderilir. Uzunluk sınırı yoktur ve tarayıcı geçmişinde saklanmasını istemediğimiz (şifre, form verisi vb.) durumlarda tercih edilir.
    ÖzellikGETPOST
    Veri YeriURL’deBody’de
    GüvenlikDaha az (loglar, tarayıcı geçmişi)Daha iyi (body’de gizli)
    Uzunluk SınırıVarYok (pratikte sunucuya bağlı sınırlanabilir)
    Geçmişte saklanırEvetHayır
    Kullanım amacıVeri ÇekmeVeri Gönderme / İşlem gerçekleştirme
    Session ve Cookie İlişkisi

    Session, sunucuda tutulan kullanıcı verisidir; Cookie ise bu veriye ulaşmamızı sağlayan istemci tarafındaki bilgilerdir. Amacımız, kullanıcının kimliğini sayfalar arası geçişlerde ve sonraki ziyaretlerde korumaktır.

    1. Ziyaret: Kullanıcı siteye gelir.
    2. Kimlik Tanımlama: Sunucu, bu kullanıcı için benzersiz bir Session ID üretir.
    3. Depolama: Bu ID, kullanıcının tarayıcısına bir Cookie (Çerez) olarak gönderilir
    4. Hatırlama: Kullanıcı sayfayı her değiştirdiğinde, tarayıcı bu Cookie’yi sunucuya geri gönderir. Sunucu da “Tamam, bu o kullanıcı” diyerek kişiyi tanır.

    Kurulum Aşaması

    Kurulumları iki farklı sanal makine üzerinden yürüteceğiz. İlki Debian, diğeri ise RedHat tabanlı Rocky Linux.

    Sanal makineleri oluştururken daima İngilizce kurulum yapmamız gerekmekte. Türkçe’de eğitimde de üstünde durduğumuz “Turkish I-İ dotting problem” gibi problemler sebebiyle kurulumları İngilizce yapmamız büyük önem teşkil ediyor.

    Her iki dağıtımı da grafik arayüzü olmadan minimal paketlerle kurmamız gerekli. İki sanal makinede de Apache Web sunucusunu kaldıracağız.

    Debian

    İlk aşama da makinedeki paketleri güncellememiz gerekli. Aksi taktirde kurulum aşamasında farklı hatalar alabiliriz.

    bash
    user@linux:~$ sudo apt update && sudo apt upgrade -y

    İkinci aşama da Apache Web sunucusunun kurulumunu yapıyoruz.

    bash
    user@linux:~$ sudo apt install apache2 -y

    Kurduğumuz servisin durumunu aşağıdaki komutlarla kontrol edebilmekteyiz.

    “Status” ile servisin çalışıp çalışmadığını kontrol ediyoruz.

    bash
    user@linux:~$ sudo systemctl status apache2

    Karşımıza çıkacak muhtemelen satırlar şöyle olacaktır:

    Bunun dışında servisin çalışmadığını veya “enable” modda olmadığını görürsek sırasıyla,

    bash
    user@linux:~$ sudo systemctl start apache2

    ve

    bash
    user@linux:~$ sudo systemctl enable apache2

    komutlarını girerek apache servisinin başlamasını ve sistemi yeniden başlattığımızda otomatik olarak onun da yeniden başlamasını sağlıyoruz.

    Servisin çalıştığını doğrulamak adına Host (ana bilgisayar) üzerinden kurduğumuz sunucumuza curl ile istek atabiliriz veya hali hazırda açık portları şu şekilde listeleyebiliriz:

    bash
    user@linux:~$ss -tulnp

    şeklinde çıktı almamız muhtemeldir.

    Eğer kurduğumuz servisin dosyalarını toplu bir şekilde görmek istersek,

    bash
    user@linux:~$ dpkg -L apache2

    komutunu girmemiz yeterlidir.

    Rocky Linux

    Burada Apache web servisinin paket adı httpd. Bunu kuruyoruz.

    bash — rocky linux httpd
    [user@rocky ~]# sudo dnf install httpd -y

    Not: Debian’dan farklı olarak kurulumu yaptıktan sonra httpd servisi otomatik olarak başlamıyor ve enable modda olmuyor. Bunun için servisi manuel olarak enable moda almamız gerekiyor.

    Bir diğer yapmamız gereken işlem diğer bilgisayarlardan erişimi sağlamak adına firewall’a kural eklemektir. Bunun için,

    bash
    [user@rocky ~]# sudo firewall-cmd --list-all

    yazdığımız kodun çıktısında firewall’ın engellediği protokolleri görebiliriz. Hemen kendi uygulamamıza diğer makinelerden erişim sağlamak için,

    bash
    [user@rocky ~]# sudo firewall-cmd --add-service=http

    komutunu girer ve “Success” çıktısını alıp başarılı bir şekilde tamamlarız.

    Kurulan dosyaların listesine erişmek için,

    bash
    [user@rocky ~]# rpm -ql httpd

    komutunu girip

    çıktısını alıyoruz.

    Devamını okumak için…


  • Network Kablo ve Cihazlar | CCNA #1

    CCNA sertifikasyon sürecinin ilk adımında bir ağı oluşturan kablo ve aygıtlardan bahsedeceğim.

    Network Kabloları

    Bakır kablolar, kurulum kolaylığı, maliyet avantajı ve elektrik akımına karşı yüksek iletkenlikleri sayesinde günümüzde en yaygın tercih edilen kablo tipidir. Türkiye’deki ağ altyapılarının büyük çoğunluğunda da bu avantajları nedeniyle bakır kablolar kullanılmaktadır.

    Yaygın olarak kullanılan bakır kablo tipleri şunlardır:

    Cat5 Türü Kablolar: Standart 8 kablonun 2’li sarmallar halinde sarılarak kullandığı tiptir. En fazla 100Mbps hıza ulaşabilir. Cat5e türü ile daha yüksek bağlantı hızları sağlanabilir.

    Cat6 Türü Kablolar: Cat5’ten farklı olarak kablolarda oluşan manyetik alanın birbirlerini etkilememesi için ek bir plastik ayraç kullanılır.

    Cat7 Türü Kablolar: Cat6’dan farklı olarak her bir çiftte muhafaza kullanılır. Bu türe ait bazı kablolarda dış etmenlere karşı da muhafaza bulunabilir.

    Cat8 Türü Kablolar: Cat7’den farklı olarak her bir çiftte kullanılan muhafaza daha sağlam olarak düzenlenmiştir. 2000 Mhz destekler. 30 metreye kadar 40Gbps hızı destekleyebilir.

    Not: Bakır kablolar uzun mesafeli veri aktarımı için uygun değildir. Maksimum verim için 100 metreye dek kullanılmalıdırlar.

    Network cihazlarının bağlantılarını sağlamak için düz ve çarpraz kablolar kullanılır. Temelde düz kablolar farklı türdeki cihazları (switch-router, bilgisayar-switch), çarpraz kablolar ise aynı tipteki cihazları (switch-hub, router-router) bağlamak için kullanılır.

    Düz kablolarda diziliş şu şekildedir:

    Çarpraz kablolarda farklı olarak diziliş şu şekildedir:

    Düz kablo, iki farklı cihazı (bilgisayar-switch gibi) birbirine bağlamak için her iki ucunda aynı pin dizilimini (T568B-T568B) kullanırken; çapraz kablo, iki benzer cihazı (bilgisayar-bilgisayar gibi) doğrudan haberleştirmek için bir uçtaki iletim pinlerini diğer uçtaki alım pinlerine bağlayacak şekilde farklı dizilimler (T568B-T568A) kullanır. Buna bağlı olarak da çarpraz kablolar veri çakışmasını önlemek için dizilimi 1-3 ve 2-6 olarak değiştirirler.

    Fiber Kablolar

    Kıtalar arası internet bağlantısının sağlanması gibi uzun mesafeli ve yüksek bant genişliği gerektiren durumlarda fiber kablolar kullanılır. Core adı verilen saç teli kalınlığında optik kablolar içerir. 2 Core bir Cat 6 – Cat 7 işlevi görür. Bu da bizlere yüksek bant genişliği sağlar.

    Fiber kablolar singlemode ve multimode olarak iki türe ayrılır. Singlemode kablolar OS1 ve OS2 tiplerine sahiptir. Uzun mesafeli veri aktarımı için uygundurlar, 200 kilometreye kadar tek parçalı yapıya sahiptirler. Multimode kablolar ise OM1, OM2, OM3, OM4, OM5 tiplerine sahiptir. Tek parçada en büyük uzunluk 2 kilometredir. Singlemode kablonun çekirdek çapı multimode kabloya göre çok daha küçük olduğu için hızlı, az kayıplı, uzun mesafeli aktarım gerçekleştirilebilir.

    ÖzellikSinglemodeMultimode
    Çekirdek Çapı9 mikron50-62.5 mikron
    Işık KaynağıLazerLED veya VCSEL
    Mesafe Kapasitesi200 km+ (Çok uzun)2 km’ye kadar (Kısa)
    MaliyetKablo ucuz, cihazlar pahalıKablo pahalı, cihazlar ucuz

    TIA-598C standartlarına göre singlemode kablolar sarı, multimode kablolar ise turkuaz ya da turuncu renktedir.

    Fiber kablolarda yaygın olarak kullanılan konnektör tipleri LC, SC, MU, ST, FC, MTRJ’dir. Bunlar haricinde kullanılan 100’e yakın konnektör çeşidi bulunmaktadır. Hepsi aynı işi yerine getirirler.

    Network Aygıtları

    Ağ içerisinde verinin nasıl iletileceğine, yönlendirileceğine ve yönetileceğine dair kararları veren ağ aygıtları bulunmaktadır. Bunlar başlıca router, hub, switch, access points, ip kameralar, ip telefonlar ve firewall gibi cihazlardır.

    Router: Farklı networkler arasındaki iletişimi düzenlemek için kullanılırlar. Her bir portu farklı bir IP yapısında olmalıdır. NAT, DHCP, ACL gibi işlemleri de yapabilirler.

    Hub: Kendisine gelen veriyi ayırt etmeksizin tüm portlarına yayın yoluyla gönderen, günümüzde yerini switchlere bırakmış ilkel cihazlardır.

    Switch: kendisine gelen veriyi cihazların fiziksel adresleri olan MAC adreslerine göre filtreleyerek sadece ilgili hedef porta gönderen akıllı bir ağ cihazıdır. Kullanım amaçlarına göre çeşitli türleri vardır:

    • Layer 3 Switchler: Hem MAC hem de IP adresleriyle çalışabilen tiptir.
    • Yönetilemez (Unmanaged) Switchler: Herhangi bir konfigürasyon gerektirmeyen, “tak-çalıştır” mantığıyla çalışan en basit modellerdir.
    • Yönetilebilir (Managed) Switchler: Ağ trafiğini izlemenize, VLAN oluşturmanıza ve güvenlik ayarları yapmanıza olanak tanıyan profesyonel cihazlardır.
    • PoE (Power over Ethernet) Switchler: Bağlı olan IP telefon veya kamera gibi cihazlara veriyle birlikte elektrik gücü de sağlayan switchlerdir.
    ÖzellikHubSwitch
    OSI Katmanı1.katman (fiziksel)2.katman (veri bağlantısı)
    İletişim ŞekliHalf-duplexFull-duplex
    Çalışma MantığıBroadcastUnicast
    Collision DurumuVarYok
    Bant GenişliğiBant Genişliği/cihaz sayısıCihaz = toplam bant genişliği (her port için ayrıdır)
    GüvenlikDüşükYüksek

    Firewall: Ağa gelen ve ağdan giden trafiği belirli güvenlik kurallarına göre denetleyen, yetkisiz erişimleri engelleyerek ağı dış tehditlere karşı koruyan bir güvenlik bariyeridir. Yeni nesil Firewall tipleri (Next Generation Firewall) standart bir firewall’dan çok daha fazla işleve sahiptir. Örneğin:

    • Uygulama Denetimi (Application Awareness)
    • Derin Paket İnceleme (Deep Packet Inspection – DPI)
    • Entegre Saldırı Önleme Sistemi (IPS/IDS)
    • Kullanıcı Kimlik Doğrulama ve Kontrolü
    • Bulut Temelli Tehdit İstihbaratı
    • Gelişmiş Zararlı Yazılım Koruması (Advanced Malware Protection)

    gibi özelliklere sahiptir.


  • Asimetrik Algoritmalar

    Asimetrik algoritmalar, kriptografinin en temel taşlarından biridir ve internet üzerinde güvenli iletişim kurmamızı sağlayan en yaygın yapılardan biri olarak karşımıza çıkar.

    Bu yaklaşım, güvenliği basit ama güçlü bir fikir üzerine kurar: veriyi şifreleyen anahtar ile şifreyi çözen anahtar birbirinden farklıdır. Public Key (açık anahtar) ve Private Key (özel anahtar) verinin gizliliğini, doğruluğunu ve bütünlüğünü sağlar.

    Bu yapı günlük hayatta pek çok servisin temelinde yer alır. İnternet sitelerine güvenli erişimi mümkün kılan TLS, blokzincir tabanlı sistemlerde cüzdanlara erişim ve işlem yetkilendirme süreçleri, WhatsApp gibi uygulamalarda mesajların yalnızca doğru kişiler tarafından okunabilmesi ve daha birçok kritik mekanizma çalışırken asimetrik algoritmalardan faydalanır.

    Asimetrik algoritmaların gücü, açık anahtar bilgisi bilinse dahi buna karşılık gelen özel anahtara ulaşmanın matematiksel olarak pratikte mümkün olmamasına dayanır. Bu güvenlik, çözümü matematiksel açıdan son derece zor olan ve yüksek hesaplama maliyeti gerektiren problemlerin kullanılmasından kaynaklanır. Bu problemlerin günümüz işlem gücüyle çözülememesi, asimetrik algoritmaları güçlü ve güvenilir kılar.

    Asimetrik Algoritmalar Nasıl Çalışıyor?

    Asimetrik algoritmalar, güvenli iletişimi sağlamak için farklı operasyonlar kullanabilir. Verinin üçüncü taraflar tarafından okunmadan ve değiştirilmeden iletilmesini sağlamak amacıyla, pratikte üç temel operasyon ön plana çıkar.

    Bu üç temel operasyon; şifreleme (encryption), dijital imza (signatures) ve anahtar değişimi (key exchange) olarak karşımıza çıkar.

    • Şifreleme, verinin yalnızca yetkili taraflarca okunabilmesini sağlar.
    • Dijital imza, verinin kaynağını ve bütünlüğünü doğrular. İletim sürecinde üçüncü tarafların veriyi değiştirmediğini garantileriz.
    • Anahtar değişimi güvenli bir kanal yokken tarafların ortak bir gizli anahtar üzerinde uzlaşabilmesini mümkün kılar.

    Bu operasyonlar, tek bir algoritma yerine farklı asimetrik şifreleme algoritmaları tarafından yapılır.

    Not: Pratikte anahtar değişimi için RSA yerine, güvenlik avantajları nedeniyle Diffie–Hellman algoritması tercih edilir.
    Not 2: RSA, şifreleme, dijital imza ve anahtar değişimi işlemlerinin tamamını destekleyebilen tek asimetrik algoritmadır.

    1. Şifreleme

    Şifreleme operasyonlarının sürdürülmesinde RSA şifreleme algoritmasından yararlanılır.

    RSA’da, iletilecek veri alıcının açık anahtarı kullanılarak şifrelenir. Bu şekilde oluşturulan şifreli metin, yalnızca alıcıya ait özel anahtar ile çözülebilir.

    Bu yapı sayesinde açık anahtar üçüncü kişilerin eline geçse bile, şifrelenmiş veriye yetkisiz kişilerin erişmesi mümkün olmaz. RSA’nın şifreleme tarafındaki güvenliği, büyük asal sayılara dayanan matematiksel yapısından kaynaklanır ve açık anahtardan özel anahtara ulaşmayı pratikte imkansıza yakın hale getirir.

    RSA, büyük asal sayıların çarpanlara ayrılmasının zorluğuna dayanan matematiksel bir problem üzerine kuruludur.

    2. İmzalama

    Dijital imza, asimetrik şifreleme algoritmalarının şifrelemeden farklı bir kullanım alanıdır ve temel amacı gizlilik değil, kimlik doğrulama ve veri bütünlüğü sağlamaktır. Bu yapıda, gönderilecek veri alıcının açık anahtarıyla değil, gönderenin özel anahtarı ile imzalanır.

    Oluşturulan bu imza, verinin gerçekten ilgili kişi tarafından üretildiğini ve iletim sırasında üçüncü kişiler tarafından değiştirilmediğini kanıtlar. Alıcı ise, gönderene ait açık anahtar yardımıyla imzayı doğrulayarak verinin bütünlüğünü ve kaynağını kontrol eder.

    Bu adımda mesajın tamamı doğrudan imzalanmaz, bunun yerine önce bir hash fonksiyonundan geçirilerek sabit uzunlukta bir metin özeti üretilir. Bunun nedeni, dijital imzanın büyük veriler üzerinde doğrudan uygulanmaya pek elverişli olmamasıdır.

    Ardından, metin özeti Private Key ile imzalanarak mesaj ile birlikte alıcı tarafa gönderilir. Alıcı taraf aldığı mesajı Public Key ile doğrular.

    Bu şekilde mesajın iletim süresince farklı kişiler tarafından değiştirilmediği ve bütünlüğünü koruduğu doğrulanır.

    Not: Bu kısımda şifrelemeden farklı olarak mesajın kendisi değil, mesajdan üretilen özet Private Key ile imzalanır ve bu imza Public Key ile doğrulanır. Çünkü burada amaç gizlilik değil, verinin doğruluğunun ve bütünlüğünün karşı tarafa kanıtlanmasıdır.

    3. Anahtar Değişimi

    Anahtar değişimi, iki tarafın aralarında güvenli bir iletişim kanalı yokken ortak bir gizli anahtar oluşturabilmesini sağlamak için yapılır. İnternet gibi açık ağlarda bir anahtarın doğrudan gönderilmesi, üçüncü kişilerin bu anahtarı ele geçirmesine yol açabilir. Bu nedenle tarafların, anahtarı açıkça paylaşmadan aynı gizli değere ulaşabilecekleri bir yönteme ihtiyaç duyulur. Anahtar değişimi algoritmaları, bu ihtiyacı karşılayarak güvenli iletişimin başlatılmasını mümkün kılar.

    Günümüzde anahtar değişimi operasyonları çoğunlukla Diffie–Hellman algoritması kullanılarak gerçekleştirilir.

    Bu örnekte Ali ve Ayşe, ortak açık değer x üzerinden kendi gizli değerlerini kullanarak sırasıyla xᶜ ve xᵈ ifadelerini üretir ve bu değerleri açık kanal üzerinden paylaşır. Mete bu değerleri görebilmesine rağmen, c ve d gizli olduğu için Ali ve Ayşe’nin ulaştığı ortak anahtarı hesaplayamaz.

    Bu sayede güvenli olmayan ortamlarda dahi üçüncü kişilerin verileri okuması engellenmiş olur.

    Bu yazıda asimetrik algoritmaların temel çalışma mantığını ve güvenli iletişimdeki rolünü ele almaya çalıştım. Okuduğunuz için teşekkür ederim.


  • RSA Algoritması – Basit Mantığıyla Anlatım

    RSA algoritması, günümüzde şifreleme ve kriptoloji alanında yaygın olarak kullanılan asimetrik algoritmalardan biridir. Doğru şekilde yapılandırıldığında, veri güvenliği açısından son derece güçlü bir koruma sağlar ve güvenli iletişimin temelini oluşturur.

    RSA, 1977 yılında Ron Rivest, Adi Shamir ve Leonard Adleman tarafından geliştirilmiş; adını da geliştiricilerinin soyadlarının baş harflerinden almıştır. Tanıtıldığı günden bu yana, modern kriptografinin yapı taşlarından biri haline gelmiş ve birçok güvenlik sisteminde standart olarak kullanılmaya devam etmiştir.

    RSA algoritması; HTTPS gibi güvenli web protokollerinde, dijital imza sistemlerinde ve anahtar paylaşımı gerektiren pek çok güvenlik mekanizmasında aktif olarak kullanılmaktadır. Özellikle güvenli iletişim kurulması gereken ortamlarda, tarafların birbirine gizli bilgileri güvenle aktarabilmesini sağlar.

    RSA Nasıl Çalışıyor?

    RSA, bir çeşit asimetrik şifreleme algoritması olduğu için iki farklı anahtar ile çalışır: Public Key (açık anahtar) ve Private Key (özel anahtar). Bu anahtarlar matematiksel olarak birbiriyle ilişkilidir ancak açık anahtardan özel anahtara ulaşmak, pratikte mümkün değildir. Çünkü RSA, ilk bakışta basit görünen ancak ciddi hesaplama gücü gerektiren bir matematiksel mantık üzerine kuruludur.

    Bir örnek üzerinden adım adım açıklayalım.

    1.adım: Ayşe ( alıcı taraf) iki adet asal sayı seçer.

    p=13,q=17p = 13, q = 17 seçilmiş olsun.

    2.adım: n=p.qn=p.q değeri hesaplanır.

    13x17=22113 x 17 = 221

    3.adım: Bu aşamada seçtiğimiz iki asal sayı ile Euler Totient (φ) fonksiyonunun değerini hesaplıyoruz.

    φ(n)=(p1)(q1)=1216=192φ(n)=(p−1)(q−1)=12⋅16=192

    4.adım: e değeri seçeriz. ee değeri 1<e<φ(n) 1 < e < φ(n) kuralına uymalı ve φ(n) ile aralarında asal olmalıdır. Ayşe burada ee değerini seçer.

    Bizim örneğimiz için e değeri 7 olsun. Bu değer ile birlikte karşı tarafa gönderilecek olan Public Key (açık anahtar) değeri oluşmuş oldu.

    Public Key: (221,7)(221, 7)

    5.adım: Şimdi açık anahtarın çözülebilmesi için bir Private Key (özel anahtar) oluşturuyoruz.

    de1(mod192)d⋅e≡1(mod192)

    7d=1(mod192)7d=1(mod192)

    Öklit algoritmasını kullanarak d değerini buluruz. Bu işlemi yapmak için 192.k+7d=1192.k + 7d = 1 işlemini uygularız.

    d değerini bulmak için 192 / 7 işlemini sıfır kalanını verene dek sürdürürüz.

    192=27.7+3192 = 27 .7 + 3

    7=2.3+17 = 2.3 + 1

    3=3.1+03 = 3.1 + 0 (Bu satır algoritmayı durdurduğu için hesaplarımıza dahil etmeyeceğiz).

    Buradan: EBOB(192,7)=1EBOB(192,7) = 1 sonucunu elde ederiz.

    Bu da 192k+7d=1192k + 7d = 1 işleminde k ve d’nin birer tam sayı olduğunun ispatı olur.

    Şimdi yaptığımız işlemleri geriye doğru açıp d’nin değerini bulalım.

    1=73.21 = 7 – 3.2

    1=7(19227.7).21 = 7 – (192 – 27.7).2

    1=7192.2+54.71 = 7 – 192.2 + 54.7

    1=192.(2)+55.71 = 192.(-2) + 55.7

    Buradan k=2k = -2 ve d=55d = 55 buluyoruz.

    Bu sayede sadece Ayşe’de bulunan Private Key değerini 55 olarak buluyoruz.

    6.adım: Ali, Ayşe’ye göndereceği mesajı şifreler.

    M (Mesaj) = 30 olsun, C de M’nin şifreli hali.

    CMe(modn)C≡M^e(modn) işlemini uygulayıp mesajı şifreleyelim.

    307=C(mod221)30^7 = C(mod221)

    30730^7 değeri çok büyük bir sayıya tekabül ettiği için modüler üs alma yöntemi kullanarak devam edeceğiz.

    301=3030^1 = 30

    302=90030^2 = 900

    900/221=16900 / 221 = 16

    Yani 30230^2 için kalan değeri 16 olur. 30430^4 değeri için 16x16=25616×16 = 256 ve buradan da 256/221=35256/221 = 35 değeri bulunur.

    307=301.302.304=30.16.35 30^7 = 30^1.30^2.30^4 = 30.16.35

    307351630(mod221)30^7≡35⋅16⋅30(mod221)

    C = 4 olarak şifrelenir.

    7.adım: Ayşe kendisine gelen şifreli mesajı çözer.

    Mesajı çözmek için MCd(modn)M≡C^d(modn) işlemini yapmamız gerekir.

    C = 4

    d = 55

    M , bilmiyoruz onu arıyoruz.

    n = 221

    cdc^d çok büyük bir değere tekabül ettiği için modüler üs alma yöntemini kullanarak işlemi yapalım.

    41 ≡ 4

    42 ≡ 16

    44 ≡ 16×16 ≡ 35

    48 ≡ 35×35 ≡ 120

    416 ≡ 120×120 ≡ 35

    432 ≡ 35⋅35 ≡ 120

    455 = 432.416.44.42.41

    455=120×35×35×16×4 = 9,408,000

    9,408,000(mod221) = 30

    İşlemler sonucunda gizli mesajın 30 olduğu öğrenilir.

    Özetle…

    Öncelikle iki asal sayı seçerek n ve φ(n) değerlerini hesapladık. Ardından açık anahtar e için uygun bir değer belirledik ve Öklid Algoritması kullanarak bu değerin modüler tersini bulup özel anahtar d’yi elde ettik.

    Daha sonra bir mesajı (M) alıp, RSA’nın şifreleme formülü olanCMe(modn)C \equiv M^e \pmod{n}ifadesiyle şifreledik. Bu işlem sırasında büyük sayılarla uğraşmamak için modüler üs alma yöntemini kullandık.

    Şifreleme sonucunda elde edilen şifreli metni (C) bu kez özel anahtar (d) ileMCd(modn)M \equiv C^d \pmod{n}formülünü kullanarak çözdük ve başlangıçta gönderilen mesajın eksiksiz şekilde geri geldiğini gördük.

    RSA’nın arkasındaki matematiği somut bir örnekle görmek, algoritmanın nasıl çalıştığını anlamayı çok daha kolaylaştırıyor.
    Bu yazının, RSA’yı yalnızca bir formül değil, çalışan bir sistem olarak görmenize yardımcı olmasını umuyorum.
    Okuduğunuz için teşekkürler.