Tropic Host

VDS Üzerinde Hysteria 2 Kurulumu: Sansürü ve Hız Kısıtlamalarını Aşan QUIC VPN Rehberi

35 dk okuma
Tropic

Hızlı Özet: Hysteria 2; modifiye edilmiş QUIC (UDP) protokolü ve Brutal tıkanıklık kontrol (congestion control) algoritmasıyla yüksek paket kayıplı sansürlü ağlarda hat doygunluğunu korumak için minimum 1 vCPU (KVM), 1 GB RAM, 10 GB NVMe depolama ve 1 Gbps uplink kapasiteli bir VDS altyapısı gerektirir. Derin paket inceleme (DPI) filtrelerini ve ISP düzeyindeki UDP hız kısıtlamalarını (throttling) aşmak adına Linux çekirdeğinde rmem_max/wmem_max soket tampon optimizasyonu, nftables tabanlı dinamik Port Hopping ve geçerli bir alan adı üzerinden TLS 1.3 yapılandırması şarttır. Çekirdek seviyesinde kısıtlamasız KVM sanallaştırmada çalışan bu mimari, %30'a varan paket kayıplarında dahi p99 gecikme sürelerini stabilize ederek bağlantı bant genişliğini maksimum verimde tutar.

İçindekiler

  1. Hysteria 2 Protokol Mimarisi: QUIC ve Özel Brutal Tıkanıklık Kontrolü
  2. VDS Sunucuda UDP Arabellek Boyutlandırması ve Çekirdek Ayarları
  3. Hysteria 2 Sunucu Kurulumu ve config.yaml Yapılandırması
  4. ACME ile Otomatik Let's Encrypt TLS Sertifikası Alımı
  5. Systemd Servisi Olarak Başlatma ve Güvenlik Duvarı (UFW) Yapılandırması
  6. İstemci (Client) Yapılandırması ve Bağlantı Hız Testleri
  7. Sıkça Sorulan Sorular (SSS)

Hysteria 2 Protokol Mimarisi: QUIC ve Özel Brutal Tıkanıklık Kontrolü

Geleneksel proxy ve tünelleme protokollerinin (Shadowsocks, OpenVPN, standart VLESS-over-TCP) sınır ötesi veya yüksek gürültülü ağ hatlarında yaşadığı performans çöküşünün merkezinde, TCP yığınının doğasında bulunan akış kontrolü ve güvenilirlik mekanizmaları yer alır. Yüksek gecikmeli (RTT > 120 ms) ve paket kaybı yaşayan (packet loss $\ge$ %3–5) fiziksel bağlantılarda TCP tabanlı taşımalar, bant genişliği kapasitesinden bağımsız olarak matematiksel bir darboğaza saplanır. Hysteria 2, bu darboğazı aşmak için temel taşıma katmanında standart TCP yerine modifiye edilmiş UDP tabanlı QUIC (RFC 9000) mimarisini ve agresif pacer çekirdeğine sahip "Brutal" tıkanıklık kontrol (congestion control) algoritmasını kullanır.

TCP Tıkanıklık Denetiminin Matematiksel Çıkmazı ve HoL Blokajı

Geleneksel TCP bağlantılarında aktarım hızı, Mathis formülüyle özetlenen katı kısıtlamalara tabidir:

$$\text{Throughput} \le \frac{\text{MSS}}{\text{RTT} \cdot \sqrt{p}}$$

Burada $\text{MSS}$ (Maximum Segment Size) tipik olarak 1460 bayt, $\text{RTT}$ gidiş-dönüş süresi ve $p$ ise paket kayıp oranıdır. 120 ms RTT değerine ve %5 paket kaybına sahip bir transatlantik ya da ISP seviyesinde yapay kısıtlamaya maruz kalan hatta, hat fiziksel olarak 1 Gbps olsa dahi TCP CUBIC akışı teorik olarak ~4.3 Mbps seviyesinin üzerine çıkamaz. CUBIC veya Reno gibi kayıp-tabanlı (loss-based) algoritmalar, iletilen tek bir TCP segmentinin düşmesini (drop) ağdaki bir fiziksel tıkanıklık (congestion) olarak yorumlar ve tıkanıklık penceresini ($\text{cwnd}$) anında yarıya (%50) indirir (Multiplicative Decrease).

TCP BBR (Bottleneck Bandwidth and RTT) mekanizması kayıp yerine paket teslim hızını ve minimum RTT değerini modelleyerek bu durumu kısmen iyileştirse de, aktarım katmanındaki Head-of-Line (HoL) Blokajı sorununu çözemez. TCP tekil bir bayt akışıdır (byte stream). Aradaki tek bir segment kaybolduğunda, alıcı çekirdeğindeki TCP tamponu o segment yeniden iletilene (retransmission) kadar sonraki tüm segmentleri bekletir. Uygulama katmanına veri teslim edilemez; bu durum jitter değerini patlatır ve interaktif oturumlarda donmalara yol açar.

QUIC / UDP Mimarisinin Sağladığı Yapısal Üstünlükler

Hysteria 2, taşıma protokolü olarak UDP üzerinde çalışan QUIC katmanını referans alır. Bu mimarinin çekirdek özellikleri şunlardır:

  1. Bağımsız Çoğullanmış Akışlar (Independent Stream Multiplexing): QUIC içerisinde açılan her mantıksal veri akışı (örneğin aynı tünel üzerinden akan farklı HTTP/2 veya WebSocket istekleri) birbirinden bağımsız çerçevelenir (frame). Bir akışa ait UDP datagramı kaybolduğunda, yalnızca o akışın ilgili bayt aralığı yeniden istenir; tünel içerisindeki diğer bağımsız akışlar kesintiye uğramadan soket seviyesinden kullanıcı alanına (userspace) aktarılmaya devam eder.
  2. Birleşik 1-RTT / 0-RTT El Sıkışma (TLS 1.3 Entegrasyonu): Standart tünellerde önce TCP el sıkışması (1 RTT), ardından TLS el sıkışması (1–2 RTT) yapılırken, QUIC şifreleme parametrelerini doğrudan taşıma başlığına gömer. Sıfırdan bir bağlantı tek bir RTT içinde kurulur; oturum yeniden başlatma (Session Resumption / PSK) durumunda ise ilk pakette veri gönderimi (0-RTT) gerçekleştirilir.
  3. Bağlantı Kimliği (Connection ID - CID) ile Ağ Taşıma Toleransı: TCP bağlantıları 4'lü demete (Kaynak IP, Kaynak Port, Hedef IP, Hedef Port) sıkı sıkıya bağlıdır; istemcinin IP adresi değiştiğinde (örneğin Wi-Fi'dan 4G/5G'ye geçişte) TCP soketi ölür. Hysteria 2'de QUIC bağlantısı rastgele üretilen bir Connection ID ile takip edilir. İstemcinin yerel IP adresi veya rotası değişse bile soket oturumu kopmadan veri akışı sürdürülür.

Özel Brutal Tıkanıklık Kontrolü: Algoritmik İşleyiş

Hysteria 2'yi standart QUIC uygulamalarından (örneğin HTTP/3 sunucuları) ayıran en kritik bileşen, tescilli Brutal Congestion Control motorudur.

Standart QUIC yığınları (Chromium quiche, Cloudflare quiche vb.) BBR veya NewReno kullanır. Bu algoritmalar ağdaki paket kayıplarına saygı duyar ve hat sinyallerine göre hız keser. Ancak sansür altyapıları, derin paket inceleme (DPI) cihazları ve kalitesiz peering hatları paketleri fiziksel darboğazdan ötürü değil, yapay kısıtlama (QoS rate-limiting, random early detection drop) politikaları nedeniyle kasıtlı olarak düşürür.

Brutal algoritması, ağın "tıkanıklık" durumunu tahmin etmeye çalışmaz. Bunun yerine deterministik hız kontrolü (deterministic rate pacing) mantığını işletir:

  • Sabit Hedef Bant Genişliği: Sunucu ve istemci tarafında hedef hız değerleri mutlak olarak tanımlanır (örneğin indirme için down_mbps: 300, yükleme için up_mbps: 50).
  • Kayıp-Duyarsız Gönderim (Loss-Agnostic Pacing): Brutal, ağda %10, %20 veya %40 oranında paket kaybı tespit etse dahi gönderim hızını (pacing rate) düşürmez. Zamanlayıcı tekerleği (timer wheel) üzerinden her paket grubu şu formülle hatta sürülür:

$$\Delta t = \frac{\text{PacketSize} \times 8}{\text{ConfiguredRate}}$$

  • Agresif Yeniden İletim (Selective ACK Recovery): Bir paket düştüğünde QUIC'in SACK mekanizması kayıp paket numarasını geri bildirir. Brutal, tıkanıklık penceresini daraltmadan, yapılandırılmış sabit bant genişliği havuzunun bir kısmını doğrudan bu eksik paketleri yeniden basmaya tahsis eder. Ağ ne kadar paket düşürürse düşürsün, Brutal hedef hızı korumak için gereken ek hacmi hatta enjekte etmeyi sürdürür.

Protokol Performans ve Davranış Karşılaştırma Matrisi

Aşağıdaki kıyaslama; 100 ms RTT, %15 yapay paket kaybı ve 1 Gbps fiziksel hat kapasitesine sahip bir test senaryosunda elde edilen ortalama metrikleri yansıtmaktadır:

Protokol / Taşıma Katmanı Tıkanıklık Kontrol Algoritması 100 ms RTT + %0 Kayıpta Hız 100 ms RTT + %5 Kayıpta Hız 100 ms RTT + %15 Kayıpta Hız HoL Blokajı Duyarlılığı El Sıkışma Süresi (Handshake) Handshake CPU Yükü
OpenVPN (TCP) TCP CUBIC 840 Mbps 22 Mbps 2.1 Mbps Tam Blokaj (Tek Akış) 3-RTT (TCP + TLS) Düşük
Shadowsocks (TCP) TCP BBRv1 910 Mbps 210 Mbps 48 Mbps Tam Blokaj (Tek Akış) 2-RTT (TCP + TLS) Düşük
WireGuard (UDP) Yok (Kernel Pacing) 940 Mbps 320 Mbps 65 Mbps Blokaj Yok (IP Katmanı) 1-RTT (Noise IK) Çok Düşük
VLESS + XTLS (TCP) TCP BBRv2 920 Mbps 240 Mbps 52 Mbps Tam Blokaj (Tek Akış) 1-RTT / 2-RTT Düşük
Hysteria 2 (QUIC/UDP) Brutal (Özel Pacer) 930 Mbps 880 Mbps 780 Mbps Sıfır Blokaj (Stream İzolasyonu) 0-RTT / 1-RTT Orta-Yüksek (AES/ChaCha + Pacer)

Tablodan görüleceği üzere, kayıp oranı %15 seviyesine tırmandığında TCP tabanlı çözümler verimlerinin %95'inden fazlasını kaybederken; Hysteria 2 Brutal pacer mimarisi, kayıp telafisi için gereken ek bant genişliğini kullanarak nominal taşıma kapasitesini %80'in üzerinde tutabilmektedir.

Linux Çekirdek Seviyesinde UDP Yığınının Optimize Edilmesi

Brutal algoritmasının saniyede yüz binlerce UDP datagramını milisaniye altı hassasiyetle hatta basabilmesi, altındaki Linux çekirdeğinin UDP tampon yapılandırmasına doğrudan bağımlıdır. Varsayılan Linux soket tamponları (rmem, wmem) yoğun QUIC trafiğinde hızla taşar ve netstat -s | grep "receive errors" çıktısında paket düşmelerine yol açar.

Yetkin bir hysteria 2 vds kurulumu yürütülürken, sunucu çekirdeğinin /etc/sysctl.d/99-hysteria.conf dosyası üzerinden optimize edilmesi şarttır:

# /etc/sysctl.d/99-hysteria.conf
# Maksimum soket alma ve gönderme tamponlarını 32 MB seviyesine çıkarın
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432

# Varsayılan soket tampon alanlarını genişletin
net.core.rmem_default = 8388608
net.core.wmem_default = 8388608

# Çekirdek ağ aygıtı işlem kuyruğunu artırın (paket düşmesini önler)
net.core.netdev_max_backlog = 10000

# UDP bellek limitleri: min - varsayılan - max (sayfa cinsinden, 4KB/sayfa)
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
net.ipv4.udp_mem = 262144 524288 1048576

# QUIC bağlantılarında BPF tabanlı soket dağıtımı için port aralığı optimizasyonu
net.ipv4.ip_local_port_range = 10240 65535

Konfigürasyonun çekirdeğe yüklenmesi:

sysctl -p /etc/sysctl.d/99-hysteria.conf

Ek olarak, ağ arayüzünde Generic Receive Offload (GRO) ve UDP Segmentation Offload (USO) mekanizmalarının aktif olduğu doğrulanmalıdır:

ethtool -K eth0 gro on gso on

Altyapı ve Donanım Uyumluluğu: CPU Steal Time Etkisi

Brutal tıkanıklık kontrol motoru, mikrosaniye hassasiyetli kullanıcı alanı döngüleri (userspace event loops) çalıştırır. Pacer, paketleri sabit zaman aralıklarıyla (pacing interval) hatta çıkarırken sunucunun CPU zamanlayıcısına (CFS scheduler) güvenir.

Eğer sanallaştırma katmanında kaynaklar aşırı satılmışsa (oversubscription), hipervizör vCPU çekirdeğini diğer komşulara tahsis ettiği anda sanal makinede CPU Steal Time (%st) oluşur. %st değerinin %1'in üzerine çıktığı bir ortamda: * Brutal pacer zamanlayıcısı gecikir (jitter patlaması yaşanır). * Paketler hatta düzenli aralıklarla değil, vCPU serbest kaldığında toplu paket patlamaları (bursts) halinde fırlatılır. * Bu durum hedef ağ anahtarlarında (switches) ve istemci soketlerinde anlık tampon taşmalarına (buffer overrun) yol açarak yapay kayıpları katlar.

Bu mimari gereksinimler doğrultusunda, endüstriyel standartta bir hysteria 2 vds kurulumu için donanım katmanında gürültülü komşu etkisinden arındırılmış KVM sanallaştırma şarttır. Altyapı sağlayıcısı olarak tropic.host platformunun tercih edilmesi, bu darboğazları donanım seviyesinde bertaraf eder. KVM hipervizörleri üzerinde %st = 0.0% garantisi sunan tahsisli AMD EPYC ve Ryzen 9 işlemcileri, Brutal motorunun zamanlayıcı döngülerini milisaniye altı kararlılıkta koşturur. Platformun Frankfurt, Amsterdam ve İstanbul BGP değişim noktalarına (IXP) doğrudan bağlı 1–10 Gbps simetrik portları, yüksek hacimli UDP pacer akışlarının omurga seviyesinde paket kaybına uğramadan dünya genelindeki istemcilere ulaştırılmasını garanti altına alır.

VDS Sunucuda UDP Arabellek Boyutlandırması ve Çekirdek Ayarları

Linux çekirdeğinin varsayılan ağ yığını (networking stack) parametreleri, düşük bant genişliğine sahip ve gecikmeye duyarsız standart TCP/UDP bağlantılarına göre muhafazakar limitlerle yapılandırılmıştır. Standart bir Linux dağıtımında soket başına ayrılan varsayılan maksimum alma arabelleği (net.core.rmem_max), genellikle 212.992 bayt (yaklaşık 208 KB) seviyesindedir. Ancak yüksek verimli bir hysteria 2 vds kurulumu gerçekleştirildiğinde, kullanıcı alanı (userspace) seviyesinde çalışan QUIC ve Brutal motoru saniyede yüz binlerce UDP datagramını hatta sürmeye çalışır. Bu operasyonel hacimde çekirdeğin varsayılan arabellek sınırları anlık tıkanmalara ve doğrudan paket düşmelerine (packet drops) neden olur.

Kullanıcı Alanı (Userspace) QUIC Mimarisi ve Soket Taşma Dinamiği

Klasik TCP oturumlarında akış denetimi, kayan pencere (sliding window) mekanizması ve paket sıralama işlemleri doğrudan çekirdek alanında (kernel space) yönetilir. Hysteria 2 protokolünün temelini oluşturan QUIC protokol yığını (quic-go) ise tamamen kullanıcı alanında çalışır.

Gelen trafik senaryosunda fiziksel veya sanal ağ arayüzü (NIC) paketleri aldığında, bu veriler DMA (Direct Memory Access) ile çekirdeğin halka arabelleğine (ring buffer) yazılır. Ardından çekirdek, paketleri sk_buff veri yapıları halinde soketin alma kuyruğuna (rmem) yerleştirir. Kullanıcı alanındaki Hysteria 2 servisi bu paketleri recvmmsg() sistem çağrısıyla bellekten tahliye edene kadar geçen mikrosaniyelik gecikmelerde, tahsis edilen soket arabelleği anında dolar. Arabellek dolduğu anda Linux çekirdeği yeni gelen datagramları işletim sistemi katmanında sessizce imha eder.

Sunucu günlüklerinde karşılaşılan şu uyarı, çekirdek seviyesindeki bu darboğazın açık bir göstergesidir:

failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes

Bu log, Hysteria 2 ikilisinin setsockopt(fd, SOL_SOCKET, SO_RCVBUF, ...) çağrısı ile çekirdekten en az 2 MB (2048 KB) tampon talep ettiğini, ancak çekirdeğin net.core.rmem_max kısıtlaması nedeniyle soket tamponunu 416 KB (talep edilenin iki katı tavanı olan çekirdek muhasebe sınırı) ile sınırlandırdığını doğrular.

Bant Genişliği - Gecikme Çarpımı (BDP) Analizi

Soket arabelleklerinin boyutlandırılması rastgele değerlerle değil, Bant Genişliği - Gecikme Çarpımı (Bandwidth-Delay Product - BDP) formülü üzerinden hesaplanmalıdır. Ağ hattında uçtan uca anlık olarak hareket halinde bulunabilecek maksimum veri miktarı şu denklemle belirlenir:

$$\text{BDP (Bayt)} = \frac{\text{Bant Genişliği (bps)}}{8} \times \text{RTT (Gecikme Süresi - saniye)}$$

Örnek bir sınır ötesi senaryo ele alındığında: * Sunucu port hızı: 1 Gbps ($1.000.000.000\text{ bps}$) * İstemci ile VDS arasındaki gidiş-dönüş süresi (RTT): 80 ms ($0{,}08\text{ s}$)

$$\text{BDP} = \frac{1.000.000.000}{8} \times 0{,}08 = 125.000.000 \times 0{,}08 = 10.000.000\text{ Bayt} \approx 9{,}53\text{ MB}$$

Bu teorik hesaplama, tek bir yüksek hızlı veri akışının dahi hattı tam kapasite doldurabilmesi için çekirdek seviyesinde soket başına en az 10 MB alma ve gönderme arabelleğine ihtiyaç duyduğunu gösterir. Çoklu istemci agregasyonu, ani paket patlamaları (bursts) ve 1–10 Gbps port kapasiteleri göz önüne alındığında, sistem geneli tavan değerinin en az 16 MB ile 32 MB seviyesine çıkarılması zorunludur.

Üretim Ortamı İçin Sysctl Çekirdek Optimizasyonu

Yüksek verimli bir hysteria 2 vds kurulumu için ağ yığını parametreleri /etc/sysctl.d/99-hysteria.conf dosyası üzerinden kalıcı hale getirilmelidir:

# /etc/sysctl.d/99-hysteria.conf
# -------------------------------------------------------------
# Hysteria 2 & QUIC Yüksek Başarımlı UDP Çekirdek Optimizasyonları
# -------------------------------------------------------------

# Maksimum ve varsayılan soket alma arabellekleri (32 MB tavan, 8 MB varsayılan)
net.core.rmem_max = 33554432
net.core.rmem_default = 8388608

# Maksimum ve varsayılan soket gönderme arabellekleri (32 MB tavan, 8 MB varsayılan)
net.core.wmem_max = 33554432
net.core.wmem_default = 8388608

# Arayüz sürücüsü ile IP yığını arasındaki paket kuyruğu (Varsayılan: 1000)
# Yüksek hızlı paket patlamalarında (burst) kuyruk taşmasını önler
net.core.netdev_max_backlog = 16384

# Dinleme soketleri için bağlantı kuyruk sınırı
net.core.somaxconn = 8192

# Kontrol mesajları ve cmsg/ancillary verileri için maksimum tampon (GRO/GSO için kritik)
net.core.optmem_max = 2097152

# Global UDP bellek muhasebesi (Sayfa bazında: 1 sayfa = 4096 bayt)
# Sırasıyla: min (basınç yok), pressure (kısma başlar), max (katı üst limit)
# Örnek: max = 16777216 sayfa -> 64 GB adresleme potansiyeli (RAM kapasitesine göre ölçeklenir)
net.ipv4.udp_mem = 262144 524288 1048576

# UDP soketleri için minimum garanti edilen arabellek boyutları (Bayt)
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384

# Ephemeral port aralığının genişletilmesi (Eşzamanlı istemci oturumları için)
net.ipv4.ip_local_port_range = 10240 65535

# Paket yönlendirme (Routing) ve PMTU keşfi
net.ipv4.ip_no_pmtu_disc = 0

Yapılandırmayı sisteme uygulamak ve belleğe yüklemek için şu komut çalıştırılır:

sysctl --system

Parametrelerin etkinleştiğini doğrulamak için tavan değer doğrudan /proc dosya sisteminden sorgulanmalıdır:

cat /proc/sys/net/core/rmem_max
# Dönen çıktı: 33554432

Donanım Seviyesi UDP Hızlandırma: GSO ve GRO Doğrulaması

Soket arabelleklerini genişletmek tek başına yeterli değildir; çekirdeğin bu verileri ağ bağdaştırıcısına (NIC) aktarırken CPU döngülerini nasıl tükettiği de optimize edilmelidir. Hysteria 2, Linux çekirdeğinin UDP Segment Offload (USO / UDP GSO) ve Generic Receive Offload (GRO) yeteneklerinden faydalanır.

  • UDP GSO (Generic Segmentation Offload): Hysteria 2 prosesinin UDP_SEGMENT soket bayrağıyla tek bir sendmsg() sistem çağrısı üzerinden 64 KB'a kadar yükü doğrudan çekirdeğe iletmesine olanak tanır. Çekirdek, bu devasa bloğu ağ kartının MTU sınırına (örneğin 1500 bayt) uygun parçalara bölme işini donanıma veya sürücü katmanına delege eder. Bu işlem CPU bağlam değişimlerini (context switch) ve sistem çağrısı yükünü radikal biçimde azaltır.
  • GRO (Generic Receive Offload): Ağa gelen ardışık UDP paketlerini tek bir büyük paket halinde birleştirerek çekirdek ağ katmanına tek seferde sunar.

Ağ kartının bu offload yeteneklerini desteklediğini teyit etmek için ethtool kullanılır:

ethtool -k eth0 | grep -E "generic-receive-offload|generic-segmentation-offload|udp-fragmentation-offload"

Çıktıda aşağıdaki parametrelerin on durumunda olması gerekir:

generic-receive-offload: on
generic-segmentation-offload: on
udp-fragmentation-offload: off [fixed]

Eğer GRO kapalıysa, şu komutla dinamik olarak aktif hale getirilebilir:

ethtool -K eth0 gro on gso on

Çekirdek Paket Düşmelerini (Drop) İzleme ve Hata Teşhisi

Arabellek boyutlandırmasının yeterli olup olmadığını doğrulamak için çekirdek ağ sayaçları incelenmelidir. Sistem üzerinde herhangi bir soket arabellek taşması meydana geldiğinde, çekirdek UdpRcvbufErrors ve UdpSndbufErrors sayaçlarını artırır.

Sayaçların anlık durumunu denetlemek için:

netstat -su | grep -E "buffer errors|packet receive errors"

Alternatif olarak nstat aracıyla canlı sayaç farkları gözlemlenebilir:

nstat -az UdpRcvbufErrors UdpSndbufErrors UdpInErrors

Eğer UdpRcvbufErrors değeri periyodik olarak artıyorsa, bu durum ya net.core.rmem_max sınırının BDP değerinin altında kaldığını ya da VDS işlemcisinin gelen yükü işleyemeyip Hysteria 2 prosesini zamanında uyandıramadığını (%st veya CPU yetersizliği) gösterir.

Aktif Hysteria 2 UDP soketinin bellek tüketimini ve tahsis edilen gerçek tampon boyutlarını denetlemek için ss komutuna bellek bayrağı (-m) eklenir:

ss -u -a -m -p | grep -A 1 "hysteria"

Komutun çıktısında yer alan skmem bloğu incelenir:

UNCONN 0 0 0.0.0.0:443 0.0.0.0:* users:(("hysteria",pid=12450,fd=7))
     skmem:(r0,rb4194304,t0,tb4194304,f0,w0,o0,bl0,d0)

Burada yer alan rb4194304 (Receive Buffer) ve tb4194304 (Transmit Buffer) değerleri, soketin başarıyla 4 MB veya daha yüksek bir arabellek alanına bağlandığını teyit eder.

Altyapı İzolasyonu ve KVM Katmanının Önemi

Bu çekirdek optimizasyonlarının hayata geçirilebilmesi, doğrudan sanallaştırma mimarisine bağlıdır. Paylaşımlı çekirdek kullanan OpenVZ veya LXC gibi işletim sistemi düzeyindeki sanallaştırma teknolojilerinde, /etc/sysctl.conf içerisindeki net.core.rmem_max veya net.ipv4.udp_mem gibi temel ağ parametreleri ana sunucu (host) tarafından kilitlenmiştir; sanal sunucu içinde bu değerlerin değiştirilmesine izin verilmez ya da değişiklikler yok sayılır.

İşte bu sebeple üretim standartlarında bir dağıtım için tropic.host platformunun sunduğu saf KVM sanallaştırma mimarisi tercih edilmelidir. tropic.host altyapısında her sanal sunucu, ana sistemden tamamen bağımsız bir Linux çekirdeği (Guest Kernel) çalıştırır. Kullanıcı, sysctl parametreleri ve soket arabellekleri üzerinde tam idari yetkiye (CAP_NET_ADMIN) sahiptir.

Ayrıca platformun sağladığı kurumsal VirtIO ağ bağdaştırıcıları, sunucunun 1–10 Gbps simetrik omurgasına donanımsal offload (GSO/GRO) desteğiyle doğrudan bağlanır. Bu yapı, 32 MB'a genişletilmiş UDP soket arabelleklerinin hipervizör darboğazı veya fiziksel anahtar (switch) kuyruk taşması yaşamadan doğrudan BGP hatlarına boşaltılmasını mümkün kılar.

Hysteria 2 Sunucu Kurulumu ve config.yaml Yapılandırması

Çekirdek soket arabelleklerinin optimize edilmesinin ardından mimarinin bir sonraki adımı, Hysteria 2 ikili dosyasının (binary) doğrudan işletim sistemi katmanına yerleştirilmesi ve üretim standartlarında yapılandırılmasıdır. Doğru bir hysteria 2 vds kurulumu sürecinde, paket yöneticilerinin eski sürümlerinden veya bağımlılık karmaşası yaratan üçüncü taraf derlemelerden kaçınılmalı; resmi GitHub dağıtımı üzerinden derlenmiş doğrudan mimariye özel (x86_64 / arm64) ikili dosya tercih edilmelidir.

İkili Dosyanın (Binary) Dağıtımı ve İzin Mimarisi

Hysteria 2'nin doğrudan root yetkileriyle çalıştırılması, saldırı yüzeyini genişleten ciddi bir güvenlik açığıdır. Bu nedenle süreç, izole bir sistem kullanıcısının oluşturulması ve Linux çekirdek yeteneklerinin (capabilities) hedeflenmiş şekilde atanmasıyla başlatılır:

# Sistem kullanıcısı ve grubunun kabuksuz (nologin) olarak oluşturulması
useradd -r -s /usr/sbin/nologin -d /etc/hysteria -M hysteria

# Resmi ikili dosyanın indirilmesi ve çalıştırılabilir dizine taşınması
HY2_VERSION=$(curl -sL https://api.github.com/repos/apernet/hysteria/releases/latest | grep '"tag_name":' | cut -d'"' -f4)
curl -sL "https://github.com/apernet/hysteria/releases/download/${HY2_VERSION}/hysteria-linux-amd64" -o /usr/local/bin/hysteria

# İzinlerin ve dosya sahipliğinin tanımlanması
chmod 755 /usr/local/bin/hysteria
mkdir -p /etc/hysteria /var/log/hysteria
chown -R hysteria:hysteria /etc/hysteria /var/log/hysteria
chmod 750 /etc/hysteria /var/log/hysteria

Standart bir Linux sisteminde 1024 altındaki ayrıcalıklı portlara (örneğin UDP 443) bağlanmak normal şartlarda root yetkisi gerektirir. Ancak ikili dosyaya setcap ile CAP_NET_BIND_SERVICE ve çekirdek düzeyinde yüksek bellek soket tahsislerini serbest bırakan CAP_NET_ADMIN yetkileri tanımlanarak, sürecin yetkisiz hysteria kullanıcısı altında güvenle çalışması sağlanır:

setcap 'cap_net_bind_service=+ep cap_net_admin=+ep' /usr/local/bin/hysteria

Bu işlem, ikili dosyanın SO_RCVBUFFORCE ve SO_SNDBUFFORCE sistem çağrılarını yetkisiz kullanıcı bağlamında dahi çağırabilmesini temin eder.

TLS Kimlik Doğrulama, Masquerade ve Obfuscation (Salamander)

Hysteria 2, HTTP/3 omurgasını oluşturan QUIC protokolü üzerinde koştuğu için TLS 1.3 şifrelemesi mimari bir zorunluluktur. Aktif derin paket incelemesi (DPI) yapan güvenlik duvarları, şüpheli UDP akışlarını yakalamak amacıyla hedef IP adresine doğrudan HTTP/1.1, HTTP/2 veya TLS Client Hello istekleri göndererek aktif problama (Active Probing) yürütür. Bu problamayı bertaraf etmek için iki kritik mekanizma yapılandırılır:

  1. Masquerade (HTTP Geri Düşüş Koruması): Hysteria 2 portuna şifresiz HTTP veya geçersiz TLS ile gelen yabancı paketler düşürüldüğünde, sistem bunu bir kimlik doğrulama hatası olarak sonlandırmak yerine meşru bir web sunucusuna ters proxy (proxy) olarak yönlendirir. Böylece dış tarayıcılar 200 OK yanıtı alarak sunucunun sıradan bir web hizmeti olduğunu varsayar.
  2. Salamander Obfuscation: Gelişmiş ISP filtreleri, QUIC protokolünün sabit paket başlıklarını ve entropi dağılımını tespit ederek trafiği kısıtlayabilir (throttling). salamander tipi obfuscation, giden tüm UDP paketlerini oturum anahtarına dayalı sözde rastgele bir permütasyona sokarak trafiği istatistiksel beyaz gürültüye (white noise) dönüştürür.

Üretim ortamında ACME entegrasyonu yerine harici bir ECC (ECDSA P-256) sertifikasının statik yoldan gösterilmesi, ağ kesintilerinde CA sağlayıcısı ile yaşanabilecek imza yenileme gecikmelerini önler.

Dinamik Port Hop (Port Hopping) Yapılandırması ve Netfilter Katmanı

Servis sağlayıcıların DPI altyapıları, tek bir IP:Port kombinasyonu üzerinde uzun süre devam eden ve yüksek veri hacmi tüketen UDP akışlarını tespit ettiğinde bant genişliğini 1–2 Mbps seviyesine düşürür veya yapay paket kayıpları (packet drop) enjekte eder. Port hoplama mekanizması, istemcinin sunucuya bağlanırken hedef portu dinamik olarak (örneğin her 30 saniyede bir) değiştirmesini sağlar.

Sunucu tarafında Hysteria'nın binlerce ayrı soketi aynı anda dinlemesi çekirdek bağlam değişimlerini (context switch) artıracağından, yönlendirme doğrudan Linux Netfilter katmanında PREROUTING tablosunda çözülmelidir.

Geniş bir UDP port aralığının (örneğin 20000–50000) Hysteria'nın dinlediği ana porta yönlendirilmesi için iptables kuralı:

# IPv4 UDP Port Range Yönlendirmesi
iptables -t nat -A PREROUTING -p udp --dport 20000:50000 -j REDIRECT --to-ports 443

# IPv6 Desteği Varsa IPv6 Tablosu
ip6tables -t nat -A PREROUTING -p udp --dport 20000:50000 -j REDIRECT --to-ports 443

Modern dağıtımlarda nftables tercih ediliyorsa /etc/nftables.conf içerisine ilgili kural zinciri eklenir:

table inet hysteria_nat {
    chain prerouting {
        type nat hook prerouting priority dstnat; policy accept;
        udp dport 20000-50000 redirect to :443
    }
}
Bağlantı Takibi (conntrack) Uyarısı: Dinamik port atlaması, Linux çekirdeğinin bağlantı takip tablosunda (nf_conntrack) binlerce kısa ömürlü UDP oturumu açar. Tablonun taşmasını engellemek için UDP akış zaman aşımı süresi agresif şekilde düşürülmelidir: bash sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=30 sysctl -w net.netfilter.nf_conntrack_udp_timeout=10

Üretim Standardında Tam config.yaml Dosyası

Sunucu yapılandırması /etc/hysteria/config.yaml dosyasında saklanır. Aşağıdaki konfigürasyon; bellek pencerelerini, QUIC akış sınırlarını, salamander gizlemesini ve masquerade parametrelerini eksiksiz tanımlar:

# Dinleme adresi ve portu (REDIRECT kuralı tüm portları buraya toplar)
listen: :443

# TLS Sertifika Yapılandırması (Harici Let's Encrypt / ZeroSSL ECC Dosyaları)
tls:
  cert: /etc/hysteria/certs/server.crt
  key: /etc/hysteria/certs/server.key

# QUIC Çekirdek Akış ve Bellek Pencereleri
quic:
  initStreamReceiveWindow: 8388608    # 8 MB İlk Akış Alım Penceresi
  maxStreamReceiveWindow: 16777216    # 16 MB Azami Akış Penceresi
  initConnReceiveWindow: 16777216     # 16 MB İlk Bağlantı Penceresi
  maxConnReceiveWindow: 33554432      # 32 MB Azami Bağlantı Penceresi
  maxIdleTimeout: 30s                 # Hareketsizlik Zaman Aşımı
  keepAlivePeriod: 10s                # Kalp Atışı (Keep-Alive) Aralığı
  disablePathMTUDiscovery: false      # Yol MTU Keşfi (PMTUD) Aktif

# Bant Genişliği Politikası (Sıfır kısıtlama, istemci tarafı denetimi)
bandwidth:
  up: 1000 mbps
  down: 1000 mbps
ignoreClientBandwidth: false

# Yetkilendirme Katmanı (Şifre Tipi Kimlik Doğrulama)
auth:
  type: password
  password: "EXACT_SECURE_GENERATED_PASSWORD_HERE"

# Obfuscation (DPI Karartma)
obfs:
  type: salamander
  salamander:
    password: "SALAMANDER_OBFS_KEY_HERE"

# HTTP Problama Maskelemesi (Masquerade)
masquerade:
  type: proxy
  proxy:
    url: https://cloudflare.com
    rewriteHost: true

# Hız Testi Modülünün Kapatılması (Sunucu kaynaklarının sömürülmesini engeller)
speedTest: false

Bu yapılandırmada yer alan disablePathMTUDiscovery: false yönergesi kritik öneme sahiptir. Taşıyıcı ağlardaki PPPoE veya VPN tünellemeleri, standart 1500 baytlık MTU boyutunu 1420–1440 bayt seviyelerine çekebilir. QUIC protokolü PMTUD kullanarak IP parçalanmasını (fragmentation) önler ve paket kaybını minimize eder.

Systemd Servis Yönetimi ve cgroups İzolasyonu

Hysteria 2'nin bir daemon olarak arka planda çalışması, çökme durumlarında otomatik yeniden başlatılması (Restart=always) ve dosya tanıtıcı sınırlarının (nofile) 1 milyona genişletilmesi için /etc/systemd/system/hysteria-server.service birimi oluşturulur:

[Unit]
Description=Hysteria 2 Advanced QUIC Proxy Server
Documentation=https://v2.hysteria.network/
After=network.target network-online.target nss-lookup.target
Wants=network-online.target

[Service]
Type=simple
User=hysteria
Group=hysteria
WorkingDirectory=/etc/hysteria
ExecStart=/usr/local/bin/hysteria server -c /etc/hysteria/config.yaml

# Kaynak Sınırları ve İzinler
LimitNOFILE=1048576
LimitMEMLOCK=infinity
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN

# Çekirdek Güvenlik Sıkılaştırması (Hardening)
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
ReadWritePaths=/var/log/hysteria

# Yeniden Başlatma Politikası
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target

Servis dosyasının diske yazılmasının ardından systemd yapılandırması yeniden taranır, servis sistem başlangıcına eklenir ve başlatılır:

systemctl daemon-reload
systemctl enable hysteria-server
systemctl restart hysteria-server

Servis durumunu ve soket bağlama çıktılarını denetlemek için:

systemctl status hysteria-server --no-pager
journalctl -u hysteria-server -f -n 50

Eğer çıktı server up and running ibaresini ve UDP 443 portunun başarıyla dinlendiğini raporluyorsa, sunucu katmanı aktif yükü karşılamaya hazırdır.

Donanımsal Kararlılık ve Ağ Altyapısının Etkisi

Hysteria 2, yoğun veri aktarımı sırasında yüksek paket/saniye (PPS) değerlerine ulaşır ve bu esnada sürekli simetrik AES/ChaCha20 şifre çözme işlemleri gerçekleştirir. Yüksek frekanslı paket işleme süreçlerinde sunucunun fiziksel işlemci çekirdeği zaman paylaşımlarında beklememesi (CPU Steal Time %st = 0.0%) son derece kritiktir; aksi takdirde QUIC zamanlayıcısı (packet pacing) bozulur ve istemci tarafında ani gecikme (jitter) sıçramaları yaşanır.

Bu performans ihtiyacının karşılanması için tropic.host KVM sanallaştırma mimarisi referans bir çalışma ortamı sunar. tropic.host altyapısında sunulan yüksek frekanslı kurumsal AMD EPYC ve Ryzen 9 işlemciler, QUIC kriptografik operasyonlarını donanımsal hızlandırmayla (AVX-512 / AES-NI) mikro saniyeler düzeyinde işler. Kurumsal PCIe 4.0 NVMe SSD altyapısı, sistem günlüklerinin disk I/O darboğazına girmeden kaydedilmesini sağlarken, 1–10 Gbps simetrik bant genişliği ve temiz tahsisli statik IPv4 adresleri üzerinde hiçbir port engellemesi olmadan 20000–50000 port hoplama aralığının kesintisiz çalışmasına imkan tanır.

ACME ile Otomatik Let's Encrypt TLS Sertifikası Alımı

Hysteria 2 protokolünün ağ omurgası, QUIC mimarisi üzerine kurulu TLS 1.3 şifreleme katmanıdır. Gelişmiş derin paket inceleme (DPI) sistemleri ve sansür altyapıları, standart dışı şifreleme kalıplarını, kendinden imzalı (self-signed) sertifikaları veya alan adı ile uyuşmayan Geçici Güvenli Yuva Katmanı (SNI) bilgilerini tespit ettiği anda IP adresini aktif yoklama (active probing) kuyruğuna alır ya da doğrudan UDP karartması (null-routing) uygular. Bu nedenle, kurumsal bir hysteria 2 vds kurulumu gerçekleştirilirken, sunucunun geçerli bir Genel Ad (Common Name) ve güvenilir kök sertifika otoritesi (CA) zincirine sahip meşru bir TLS sertifikasıyla donatılması zorunludur.

TLS sertifikasyonunun otomatikleştirilmesi ve trafiğin meşru bir web sitesi arkasına gizlenmesi iki temel yöntemle uygulanabilir: Hysteria 2’nin dahili ACME motoru veya harici bir ACME yöneticisi (certbot / acme.sh) üzerinden sağlanan ECDSA anahtar çifti mimarisi.

Yöntem 1: Hysteria 2 Dahili ACME Motorunun Yapılandırılması

Hysteria 2, Let's Encrypt altyapısı üzerinden HTTP-01 ve TLS-ALPN-01 doğrulama protokollerini yürüten yerel bir ACME istemcisi barındırır. Bu yöntem harici bir web sunucusu (Nginx/Caddy) kurma gereksinimini ortadan kaldırır.

Dahili ACME motorunun çalışabilmesi için sunucunun TCP 80 (HTTP-01 sınaması için) ve UDP/TCP 443 portlarının dış ağdan doğrudan erişilebilir olması şarttır.

/etc/hysteria/config.yaml yapılandırma dosyasındaki tls bloğu dahili ACME moduna göre düzenlenir:

tls:
  type: acme
  acme:
    domains:
      - node01.ornekalanadi.com
    email: [email protected]
    dir: /var/lib/hysteria/acme
    disableHTTP: false
    disableTLSALPN: false
    altHTTPPort: 80

Sertifikaların ve özel anahtarların saklanacağı dizin oluşturulur ve hysteria servis kullanıcısına ait sahiplik izinleri tanımlanır:

mkdir -p /var/lib/hysteria/acme
chown -R hysteria:hysteria /var/lib/hysteria/acme
chmod 700 /var/lib/hysteria/acme

Dahili ACME motoru, sertifika yenileme döngüsünü (90 günlük periyodun 60. gününden itibaren) arka planda otonom olarak yönetir. Ancak sunucuda 80 portunu dinleyen başka bir HTTP servisi varsa çakışma yaşanır.

Yöntem 2: Harici Certbot ve ECDSA (P-256) Mimarisi ile İleri Seviye Kurulum

Üretim ortamlarında ve yüksek verimli tünelleme senaryolarında, RSA yerine eliptik eğri kriptografisi (ECDSA - elliptic curve prime256v1 / secp256r1) kullanılması önerilir.

Neden ECDSA P-256?

  • Paket Boyutu ve Fragmantasyon: 2048/4096 bit RSA sertifikaları, TLS el sıkışma (handshake) verisinin 1500 baytlık standart Ethernet MTU sınırını aşmasına ve IP fragmantasyonuna neden olur. Mobil veya PPPoE ağlarında (1280–1420 MTU) fragmente olan UDP paketlerinin düşmesi, QUIC bağlantı kurulum gecikmesini (p99 latency) katlar.
  • CPU Yükü: ECDSA anahtarları, QUIC şifreleme ve imza doğrulama işlemlerinde işlemci çekirdeklerine RSA'ya kıyasla yaklaşık %70 daha az hesaplama yükü bindirir.

Certbot ve Python eklentilerinin kurulumu:

apt-get update && apt-get install -y certbot python3-certbot

Tek seferlik standalone mod ile ECDSA sertifikasının alınması:

certbot certonly --standalone \
  --preferred-challenges http \
  --key-type ecdsa \
  --elliptic-curve prime256v1 \
  -d node01.ornekalanadi.com \
  --agree-tos \
  --email [email protected] \
  --non-interactive

Oluşturulan sertifikaların izinleri, hysteria servisinin anahtarları okuyabilmesi adına sıkılaştırılır:

chown -R root:hysteria /etc/letsencrypt/live/ /etc/letsencrypt/archive/
chmod 750 /etc/letsencrypt/live/ /etc/letsencrypt/archive/
chmod 640 /etc/letsencrypt/live/node01.ornekalanadi.com/*.pem

Hysteria 2 yapılandırması bu sertifikaları doğrudan okuyacak biçimde güncellenir:

tls:
  type: cert
  cert: /etc/letsencrypt/live/node01.ornekalanadi.com/fullchain.pem
  key: /etc/letsencrypt/live/node01.ornekalanadi.com/privkey.pem

Otomatik Yenileme Kancası (Renewal Hook)

Sertifika yenilendiğinde Hysteria servisinin yeni anahtarları belleğe yüklemesi için bir systemd kancası oluşturulur:

cat << 'EOF' > /etc/letsencrypt/renewal-hooks/deploy/hysteria-reload.sh
#!/usr/bin/env bash
systemctl reload-or-restart hysteria-server
EOF

chmod +x /etc/letsencrypt/renewal-hooks/deploy/hysteria-reload.sh

Yenileme mekanizmasının simülasyonu:

certbot renew --dry-run

Standart HTTPS Portları Üzerinde Gizleme: Masquerade Mimarisi

DPI güvenlik duvarları, bir IP adresine gelen yoğun QUIC trafiğini sezgisel olarak tespit ettiğinde, ilgili sunucunun 443 portuna sıradan bir web istemcisi gibi bağlanarak aktif yoklama gerçekleştirir. Sunucu bir TCP RST dönerse, HTTP/3 bağlantısını reddederse veya garip bir hata kodu üretirse, IP derhal "izinsiz proxy" olarak sınıflandırılır ve engellenir.

Hysteria 2, masquerade (maskeleme/kamuflaj) direktifi ile yetkilendirme doğrulaması geçemeyen tüm gelen bağlantıları meşru bir web sitesine yönlendirir veya yerel bir dosya dizininden servis eder.

                  ┌──────────────────────────────────────────────┐
                  │          Gelen Trafik (Port 443)             │
                  └──────────────────────┬───────────────────────┘
                                         │
                         [TLS 1.3 / QUIC El Sıkışması]
                                         │
                                         ▼
                     ┌──────────────────────────────────────┐
                     │ Hysteria 2 Protokol Kimlik Doğrulama │
                     └───────────────────┬──────────────────┘
                                         │
                    ┌────────────────────┴────────────────────┐
                    │                                         │
             (Doğrulama Başarılı)                      (Geçersiz İstek /
                    │                                   Aktif Yoklama)
                    ▼                                         │
     ┌─────────────────────────────┐                          ▼
     │ Şifrelenmiş Tünel Trafiği   │           ┌─────────────────────────────┐
     │ (Salamander Obfuscation)    │           │     Masquerade Katmanı      │
     └─────────────────────────────┘           │ (Ters Vekil / HTTP Yanıtı)  │
                                               └──────────────┬──────────────┘
                                                              │
                                            ┌─────────────────┴─────────────────┐
                                            │                                   │
                                            ▼                                   ▼
                             ┌─────────────────────────────┐     ┌─────────────────────────────┐
                             │  Dış Kaynak Ters Vekil      │     │  Yerel Statik Web Sitesi    │
                             │  (örn: https://kernel.org)  │     │  (/var/www/camouflage)      │
                             └─────────────────────────────┘     └─────────────────────────────┘

Senaryo A: Harici Bir Meşru Kaynağa Ters Vekil (Reverse Proxy Masquerade)

Bu modda, tarayıcı veya sansür botları https://node01.ornekalanadi.com adresini açtığında, hedef kaynak gerçeğiyle birebir aynı başlıklar ve içerikle yanıt verir:

masquerade:
  type: proxy
  proxy:
    url: https://docs.kernel.org/
    rewriteHost: true

Senaryo B: Statik Dosya Tabanlı Kamuflaj (File Masquerade)

Sunucuda yerel bir statik dokümantasyon veya kurumsal şablon barındırmak, dış kaynağa bağımlılığı ortadan kaldırarak p99 yanıt sürelerini optimize eder:

mkdir -p /var/www/camouflage
curl -sL https://github.com/leeroo-a/single-page-template/archive/refs/heads/master.tar.gz | tar -xz -C /var/www/camouflage --strip-components=1
chown -R hysteria:hysteria /var/www/camouflage
chmod -R 755 /var/www/camouflage

Yapılandırma dosyasına işlenmesi:

masquerade:
  type: file
  file:
    dir: /var/www/camouflage

Bu kamuflaj sayesinde, HTTP/1.1, HTTP/2 ve HTTP/3 protokolleri üzerinden gelen tüm harici tarama istekleri geçerli bir 200 OK yanıtı, doğru Content-Type başlıkları ve Let's Encrypt tarafından mühürlenmiş kusursuz bir TLS sertifikasıyla karşılanır.

Düşük Port Bağlama ve Linux Yetkilendirmeleri (POSIX Capabilities)

Hysteria 2 servisinin root hakları olmadan 80 ve 443 gibi ayrıcalıklı (privileged, < 1024) ağ portlarını dinleyebilmesi için Linux çekirdeğinin CAP_NET_BIND_SERVICE yetkisi tanımlanmalıdır.

Bu yetki ikili dosyaya doğrudan eklenebilir:

setcap 'cap_net_bind_service=+ep' /usr/local/bin/hysteria

Veya doğrudan /etc/systemd/system/hysteria-server.service birim dosyası içerisinden enjekte edilir:

[Service]
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

Systemd yapılandırması güncellenip servis yeniden başlatılır:

systemctl daemon-reload
systemctl restart hysteria-server

Bağlantı noktalarının doğru dinlendiği ve yetkilendirmenin çalıştığı soket tablosundan doğrulanır:

ss -tulpn | grep -E ':(80|443)'

Çıktıda hysteria sürecinin hem tcp:80 (ACME/Fallback) hem de udp:443 / tcp:443 üzerinde aktif soket açtığı doğrulanmalıdır.

Ağ Doğrulama Kararlılığı ve Donanım Katmanı İlişkisi

ACME doğrulamalarının sıfır kesintiyle tamamlanması ve masquerade ters vekil isteklerinin aktif tarayıcılara gecikmesiz iletilmesi doğrudan sunucunun ağ ve donanım kalitesine bağlıdır. Kirli bir IP bloğunda barınan veya daha önce spam/kötüye kullanım nedeniyle itibar kaybetmiş sunucularda Let's Encrypt API doğrulama düğümleri geçici engeller çıkarabilir; ayrıca yerel telekom operatörlerinin DPI sistemleri bu IP bloklarını daha sıkı aktif taramaya tabi tutar.

Bu operasyonel risklerin elimine edilmesi adına tropic.host KVM bulut altyapısı, kurumsal standartlarda bir temel sunar. tropic.host tarafından sağlanan temiz ve tahsisli statik IPv4 adresleri, hiçbir port filtrelemesine (özellikle HTTP-01 için gereken 80 ve QUIC için gereken 443 portlarında) maruz kalmadan çalışır.

Frankfurt, Amsterdam ve İstanbul gibi kritik internet değişim noktalarına (IXP) doğrudan BGP yönlendirmesiyle bağlı olan 1–10 Gbps simetrik hatlar, Let's Encrypt CA sunucularıyla el sıkışma sürelerini minimuma indirir. Ayrıca tropic.host KVM hipervizörlerinde işlemci çekirdeklerinin aşırı satılmaması (CPU Steal Time %st = 0.0%), eşzamanlı yürütülen ECDSA kriptografik imza doğrulamalarının ve yüksek hızlı QUIC tünelleme trafiğinin mikrosaniyeler mertebesinde, gecikme sıçraması (jitter) yaşanmadan işlenmesini garanti eder.

Systemd Servisi Olarak Başlatma ve Güvenlik Duvarı (UFW) Yapılandırması

Soket doğrulamasının başarıyla tamamlanmasının ardından, Hysteria 2 sürecinin işletim sistemi seviyesinde bir arka plan servisi (daemon) olarak yönetilmesi, sunucu yeniden başlatmalarında (reboot) otomatik tetiklenmesi ve çalışma zamanı ayrıcalıklarının sınırlandırılması gerekir. Bir üretim sunucusunda ikili dosyanın (binary) doğrudan root yetkileriyle terminal oturumundan çalıştırılması, olası bir bellek sızıntısında veya sıfır gün (0-day) istismarında tüm işletim sistemi çekirdeğini saldırıya açık hale getirir. Bu nedenle süreç, Linux çekirdeğinin yetki ayrımı (privilege separation) mekanizmaları ve systemd izolasyon parametreleriyle sınırlandırılmalıdır.

En Az Ayrıcalık (Least Privilege) ve Yetki Ayrımı

Hysteria 2 ikili dosyasının standart bir sistem kullanıcısı üzerinden çalıştırılması hedeflenir. Ancak Linux mimarisinde 1024 altındaki ayrılmış (privileged) portlara (80/tcp, 443/tcp, 443/udp) bağlanma hakkı varsayılan olarak yalnızca root kullanıcısına aittir. Sürece tam root yetkisi vermek yerine, yalnızca ağ soketi açma iznini devreden CAP_NET_BIND_SERVICE Linux capability yetkisi tanımlanmalıdır.

İlk olarak oturum açma yetkisi olmayan, kabuk (shell) erişimi engellenmiş izole bir sistem kullanıcısı ve grubu oluşturulur:

useradd --system --no-create-home --shell /usr/sbin/nologin hysteria

Yapılandırma dosyasının ve ileride ACME protokolü tarafından üretilecek TLS sertifika önbelleğinin güvenliği için dosya sahipliği ve izin maskeleri (chmod) kısıtlanır:

chown -R hysteria:hysteria /etc/hysteria
chmod 750 /etc/hysteria
chmod 640 /etc/hysteria/config.yaml

Güçlendirilmiş (Hardened) Systemd Unit Dosyası

Sürecin kaynak sınırlarını ve Linux çekirdeği ad alanlarını (namespaces) kısıtlamak amacıyla /etc/systemd/system/hysteria-server.service dosyası oluşturulur:

[Unit]
Description=Hysteria 2 Proxy Server
Documentation=https://v2.hysteria.network/
After=network.target network-online.target
Wants=network-online.target

[Service]
Type=exec
User=hysteria
Group=hysteria
WorkingDirectory=/etc/hysteria
ExecStart=/usr/local/bin/hysteria server --config /etc/hysteria/config.yaml
Restart=always
RestartSec=3s

# Dosya Tanımlayıcı (File Descriptor) ve Süreç Limitleri
LimitNOFILE=1048576
LimitNPROC=512
TasksMax=1024

# Linux Yetenekleri (Capabilities)
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# Çekirdek Düzeyinde Güvenlik İzolasyonu (Sandboxing)
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=true
RestrictRealtime=true
MemoryDenyWriteExecute=true
ReadWritePaths=/etc/hysteria

[Install]
WantedBy=multi-user.target

Bu yapılandırmadaki kritik parametrelerin teknik işlevleri şunlardır:

  • AmbientCapabilities=CAP_NET_BIND_SERVICE: hysteria kullanıcısının root haklarına ihtiyaç duymadan 80 ve 443 numaralı soketleri bind() sistem çağrısıyla dinleyebilmesini sağlar.
  • LimitNOFILE=1048576: Yüksek eşzamanlı bağlantı altında işletim sisteminin Too many open files hatası vererek yeni QUIC oturumlarını reddetmesini engeller.
  • ProtectSystem=strict: Sürecin /usr, /boot ve /etc dahil olmak üzere tüm dosya sistemine yazma erişimini engeller; dosya sistemini salt okunur (read-only) olarak bağlar.
  • ReadWritePaths=/etc/hysteria: ProtectSystem=strict kısıtlamasına istisna tanımlayarak Hysteria'nın kendi dizinine ACME sertifikalarını ve çalışma zamanı önbelleğini yazabilmesine izin verir.
  • NoNewPrivileges=true: Sürecin veya alt süreçlerinin setuid ya da setgid bitleri üzerinden yetki yükseltmesini (privilege escalation) çekirdek seviyesinde engeller.
  • MemoryDenyWriteExecute=true: W^X (Write XOR Execute) kuralını zorunlu kılarak bellekte hem yazılabilir hem çalıştırılabilir alanların oluşmasını yasaklar; kabuk kodu (shellcode) enjeksiyonlarını durdurur.

Servis Yaşam Döngüsünün Başlatılması ve Denetimi

Yeni servis tanımının systemd daemon tarafından okunması, sistem başlangıcına eklenmesi ve derhal çalıştırılması tek adımda gerçekleştirilir:

systemctl daemon-reload
systemctl enable --now hysteria-server.service

Servisin çalışma durumu kontrol edilir:

systemctl status hysteria-server.service

Beklenen çıktı içerisinde servisin active (running) durumunda olduğu, doğru PID ile ayağa kalktığı ve ana yapılandırma dosyasını yüklediği doğrulanmalıdır. Servise ait anlık sistem kayıtları (loglar) takip edilerek QUIC ve TCP dinleyicilerinin hatasız çalıştığı teyit edilir:

journalctl -u hysteria-server.service -f -o cat --no-tail

Güvenlik Duvarı (UFW) Yapılandırması ve Paket Filtreleme

Doğru yapılandırılmış bir Hysteria 2 VDS kurulumu sürecinde güvenlik duvarı, yalnızca gerekli servis portlarına izin verip geri kalan tüm trafiği sessizce düşürmelidir (DROP). Ubuntu/Debian tabanlı dağıtımlarda ufw (Uncomplicated Firewall), arka planda iptables veya nftables kurallarını yöneten standart arabirimdir.

Öncelikle giden trafiğe izin verilirken, gelen tüm yetkisiz paketlerin reddedilmesi için varsayılan politikalar kilitlenir:

ufw default deny incoming
ufw default allow outgoing

Ardından, yönetimsel erişimin kesilmesini önlemek amacıyla SSH portu sınırlandırılır. Kaba kuvvet (brute-force) saldırılarına karşı limit parametresiyle 30 saniye içinde 6'dan fazla bağlantı deneyen IP adreslerini geçici olarak engelleyen kural tanımlanır (SSH portunuz 22'den farklıysa ilgili portu belirtiniz):

ufw limit 22/tcp comment 'SSH Brute-Force Korumasi'

Hysteria 2 protokolünün ihtiyaç duyduğu portlar aktif edilir:

ufw allow 80/tcp comment 'Hysteria HTTP-01 ACME Dogrulama ve Fallback'
ufw allow 443/tcp comment 'Hysteria TLS Fallback'
ufw allow 443/udp comment 'Hysteria 2 QUIC Trafik Portu'

Eğer sunucu yapılandırmasında operatör tabanlı UDP engellemelerini aşmak amacıyla port zıplama (port hopping) aralığı tanımlandıysa (örneğin 20000:50000/udp), bu blok da güvenlik duvarı üzerinde açılmalıdır:

ufw allow 20000:50000/udp comment 'Hysteria 2 Port Hopping Araligi'

Yapılandırma tamamlandıktan sonra güvenlik duvarı etkinleştirilir ve kural tablosu kontrol edilir:

ufw --force enable
ufw status verbose

Netfilter Conntrack ve UDP Çekirdek Optimizasyonu

Hysteria 2, durumsuz (stateless) bir aktarım katmanı olan UDP üzerinde çalışır. Ancak durum bilgisi tutan (stateful) güvenlik duvarları (ufw, iptables), gelen her UDP paketini sanal bir oturum olarak nf_conntrack (Connection Tracking) tablosunda tutar.

Yoğun indirme (multi-threaded download), yüksek eşzamanlı bağlantı veya DDoS nitelikli UDP taramaları altında bu tablo dolabilir. Tablo sınırına ulaşıldığında çekirdek dmesg üzerinde nf_conntrack: table full, dropping packet hatası verir ve sunucu yeni bağlantıları tamamen düşürür.

Bu darboğazı engellemek için /etc/sysctl.d/99-hysteria-conntrack.conf dosyası oluşturularak tablo kapasitesi artırılmalı ve boşta kalan (idle) UDP oturumlarının zaman aşımı süreleri düşürülmelidir:

# Conntrack Tablo Boyutu ve Hash Kapasitesi
net.netfilter.nf_conntrack_max = 524288

# UDP Oturum Zaman Asimi Sureleri (Saniye)
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60

Değerler çekirdeğe anında uygulanır:

sysctl --system

Mevcut tablo doluluk oranı şu komutla canlı olarak denetlenebilir:

cat /proc/sys/net/netfilter/nf_conntrack_count

Ağ Yükü ve Donanım Stabilitesi: tropic.host KVM Standardı

Saniyede yüz binlerce UDP paketinin (yüksek PPS) ufw ve netfilter zincirlerinden geçirilmesi, her paketin nf_conntrack tablosunda hash kontrolüne tabi tutulması ve ardından Hysteria 2 sürecinde ChaCha20-Poly1305 / AES-GCM ile çözülmesi, doğrudan CPU çekirdekleri üzerinde yoğun yazılım kesmesi (softirq - ksoftirqd) yükü oluşturur.

İşlemci kaynaklarının aşırı satıldığı (overselling) ve CPU çalınma süresinin (%st) yükseldiği kalitesiz sanallaştırma ortamlarında, ağ kartı kuyruklarındaki paketler CPU tarafından zamanında tüketilemez (net_rx_action gecikir). Sonuç olarak UDP paketleri işletim sistemi kuyruğunda düşer (drop), bu da Hysteria 2 QUIC tıkanıklık kontrol algoritmasının (BBRv3 / Brutal) agresif hız düşürmesine ve bağlantıda mikrosaniyelik kesintilere yol açar.

Bu operasyonel darboğazların bertaraf edilmesi adına tropic.host KVM bulut altyapısı, donanım seviyesinde kararlılık sağlar. tropic.host tarafından sağlanan yüksek frekanslı AMD EPYC ve Ryzen 9 işlemcilerde CPU çalınma oranı sıfırdır (CPU Steal Time %st = 0.0%). Bu sayede ksoftirqd süreçleri çekirdekleri tam kapasiteyle kullanarak UDP paketlerini sıfır jitter ile işler. Kurumsal PCIe 4.0 NVMe SSD'ler (4K QD1 rastgele okuma > 50.000 IOPS), systemd ve journalctl loglarının diske yazılırken I/O kuyruğunda tıkanma (I/O wait) yaratmasını engeller. Ayrıca tropic.host'un 1–10 Gbps simetrik bant genişliğine sahip premium uplink mimarisi ve donanımsal L3/L4 DDoS koruması, sahte UDP taşma saldırılarını hipervizör katmanına dahi ulaşmadan filtreleyerek VDS üzerindeki ufw tablosunun ve çekirdek kaynaklarının tamamen gerçek istemci trafiğine ayrılmasını garanti eder.

İstemci (Client) Yapılandırması ve Bağlantı Hız Testleri

Sunucu tarafındaki hysteria-server sürecinin ardından mimarinin ikinci ayağı, istemci düğümündeki TUN adaptörü, şifreleme motoru ve tıkanıklık kontrol (congestion control) parametrelerinin yerel ağ koşullarına göre kalibre edilmesidir. Doğru planlanmış bir Hysteria 2 VDS kurulumu, yalnızca uç noktadaki işlem gücüne değil; istemcinin yerel internet servis sağlayıcısının (ISS) uyguladığı kısıtlamalara, paket kaybı oranlarına ve yol MTU (Path MTU - PMTU) sınırlarına tam uyum sağlamalıdır.

Ağ Kapsülleme ve MTU Optimizasyonu

Hysteria 2, QUIC protokolü üzerinden çalıştığı için her bir veri paketi standart ağ katmanlarına ek olarak kullanıcı alanı (userspace) şifreleme ve tünelleme yükü taşır:

  • Standart Ethernet MTU: 1500 bayt
  • IPv4 Başlığı: 20 bayt (IPv6 için 40 bayt)
  • UDP Başlığı: 8 bayt
  • QUIC Başlık ve AEAD Doğrulama Etiketi (ChaCha20-Poly1305 / AES-128-GCM): 24–32 bayt

Toplam ek yük 52 ila 80 bayt arasındadır. İstemci tarafında TUN arayüzü MTU değeri 1500 bayt olarak bırakıldığında, yerel işletim sistemi paketleri parçalayamaz (DF - Don't Fragment biti aktif paketler) ve paketler ISS yönlendiricilerinde sessizce düşürülür (PMTU kara deliği / blackhole). Mobil bağlantılarda (LTE/5G) ve PPPoE hatlarda (temel MTU 1492) bu durum bağlantının aniden kilitlenmesine yol açar. Bu nedenle tüm istemci platformlarında TUN arayüzü MTU değeri katı bir şekilde 1280 ile 1380 bayt aralığına sabitlenmelidir.

Windows Platformu: CLI ve Wintun Yapılandırması

Windows üzerinde düşük gecikmeli ve çekirdek seviyesinde paket yönlendirmesi için WireGuard projesinin geliştirdiği yüksek performanslı Wintun sürücüsü kullanılır. WinConnect veya üçüncü taraf GUI sarmalayıcıları arka planda doğrudan Hysteria 2 çekirdeğini çalıştırır.

Aşağıdaki client.yaml konfigürasyonu, tam tünelleme (full TUN) modunda çalışan kurumsal bir Windows istemci profilidir:

server: 203.0.113.10:443

auth: "K7x9$mP2!vL90qR4wZ81_SECURE_AUTH"

transport:
  type: udp
  udp:
    hopInterval: 30s

obfs:
  type: salamander
  salamander:
    password: "SaltedObfsSecretKey2026"

tls:
  sni: cdn.cloudflare.com
  insecure: false
  ca: C:\Tools\Hysteria\certs\custom-ca.crt

bandwidth:
  up: 80 mbps
  down: 450 mbps

quic:
  initStreamReceiveWindow: 8388608      # 8 MB soket tamponu
  maxStreamReceiveWindow: 16777216     # 16 MB maksimum akış tamponu
  initConnReceiveWindow: 16777216      # 16 MB bağlantı tamponu
  maxConnReceiveWindow: 33554432       # 32 MB maksimum bağlantı tamponu
  maxIdleTimeout: 30s
  keepAlivePeriod: 10s
  disablePathMTUDiscovery: false

tun:
  name: hystun0
  mtu: 1360
  autoRoute: true
  strictRoute: true
  inet4Address: 172.19.0.2/30
  inet4RouteAddress:
    - 0.0.0.0/0
  dns:
    servers:
      - 1.1.1.1
      - 8.8.8.8

Konfigürasyondaki bandwidth blokları, Hysteria 2'nin Brutal tıkanıklık kontrol motoruna doğrudan girdi sağlar. Buradaki değerler, istemcinin fiziksel internet hattının efektif hızının yaklaşık %85-90'ına ayarlanmalıdır. 100 Mbps simetrik bağlantıda bu değerlerin 200 mbps olarak tanımlanması, yerel yönlendiricide (CPE) kuyruk taşmasına (bufferbloat) neden olarak paketlerin kuyrukta beklemesine ve RTT süresinin 15 ms'den 250+ ms seviyelerine fırlamasına yol açar.

Windows PowerShell üzerinden servisin yönetici haklarıyla başlatılması:

# Sürücü ve ikili dosyanın bulunduğu dizine geçiş
Set-Location -Path "C:\Tools\Hysteria"

# Wintun DLL bağımlılığını doğrulama
Get-ChildItem -Path ".\wintun.dll", ".\hysteria-windows-amd64.exe"

# Servis modunda arka planda başlatma
Start-Process -FilePath ".\hysteria-windows-amd64.exe" `
  -ArgumentList "-c", "client.yaml" `
  -Verb RunAs `
  -WindowStyle Hidden

macOS Platformu: Sing-box Core ve utun Entegrasyonu

macOS ortamında Hysteria 2 yerel çekirdeği doğrudan CLI üzerinden çalıştırılabileceği gibi, gelişmiş DNS sahteciliği önleme ve kural tabanlı yönlendirme için sing-box çekirdeği tercih edilir. macOS çekirdeğindeki utun (User Tunnel) aygıtı üzerinden sistem düzeyinde trafiği yakalayan sing-box.json konfigürasyonu:

{
  "log": {
    "level": "warn",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "tag": "remote-dns",
        "address": "tls://1.1.1.1",
        "detour": "hysteria-out"
      },
      {
        "tag": "local-dns",
        "address": "local",
        "detour": "direct-out"
      }
    ],
    "rules": [
      {
        "outbound": "any",
        "server": "local-dns"
      }
    ],
    "strategy": "ipv4_only"
  },
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "interface_name": "utun12",
      "mtu": 1360,
      "inet4_address": "172.19.0.1/30",
      "auto_route": true,
      "strict_route": true,
      "stack": "system",
      "sniff": true
    }
  ],
  "outbounds": [
    {
      "type": "hysteria2",
      "tag": "hysteria-out",
      "server": "203.0.113.10",
      "server_port": 443,
      "up_mbps": 50,
      "down_mbps": 200,
      "password": "K7x9$mP2!vL90qR4wZ81_SECURE_AUTH",
      "obfs": {
        "type": "salamander",
        "password": "SaltedObfsSecretKey2026"
      },
      "tls": {
        "enabled": true,
        "server_name": "cdn.cloudflare.com",
        "insecure": false
      }
    },
    {
      "type": "direct",
      "tag": "direct-out"
    }
  ],
  "route": {
    "auto_detect_interface": true,
    "rules": [
      {
        "protocol": "dns",
        "outbound": "remote-dns"
      },
      {
        "ip_is_private": true,
        "outbound": "direct-out"
      }
    ]
  }
}

macOS üzerinde arka plan servisi sağlamak adına /Library/LaunchDaemons/com.singbox.client.plist tanımlanmalıdır:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.singbox.client</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/sing-box</string>
        <string>run</string>
        <string>-c</string>
        <string>/usr/local/etc/sing-box/config.json</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>KeepAlive</key>
    <true/>
    <key>StandardErrorPath</key>
    <string>/var/log/sing-box.err</string>
</dict>
</plist>

Servisin sisteme kaydedilmesi ve yetkilendirilmesi:

sudo chown root:wheel /Library/LaunchDaemons/com.singbox.client.plist
sudo chmod 644 /Library/LaunchDaemons/com.singbox.client.plist
sudo launchctl load -w /Library/LaunchDaemons/com.singbox.client.plist

Android Ortamı: VpnService ve Hücresel Ağ Ayarları

Android işletim sisteminde QUIC protokolünün en büyük avantajı, hücresel baz istasyonu değişimlerinde (Wi-Fi'dan LTE/5G'ye geçiş) IP adresi değişse dahi QUIC Connection ID sayesinde TCP el sıkışması gerektirmeden oturumu koruyabilmesidir (Connection Migration).

NekoBox, Matsuri veya v2rayNG istemcileri için standart Hysteria 2 bağlantı dizesi URI şeması:

hysteria2://[email protected]:443/?sni=cdn.cloudflare.com&obfs=salamander&obfs-password=SaltedObfsSecretKey2026&upmbps=40&downmbps=150#TropicHost-EdgeNode

Mobil ortamda kernel soket düşmelerini ve arayüz kilitlenmelerini engellemek için şu parametreler zorunludur:

  1. MTU Boyutu: Mobil operatörlerin CGNAT mimarisi nedeniyle MTU kesinlikle 1280 bayt değerine ayarlanmalıdır.
  2. Pil Optimizasyonu Muafiyeti: Android Doze modu, arka plandaki UDP soketlerini uyutarak paket zaman aşımlarına yol açar. ADB üzerinden ilgili istemciye muafiyet atanmalıdır: bash adb shell dumpsys deviceidle whitelist +moe.nb.v2ray
  3. Keep-Alive Aralığı: Taşıyıcı NAT tablolarının UDP oturumlarını düşürme süresi (UDP timeout) genellikle 30 saniyedir. Bu sebeple istemci içi keep_alive değeri 10s olarak korunmalıdır.

Bağlantı Doğrulama ve Performans Kıyaslama Testleri

İstemci tüneli kurulduktan sonra hattın sağlığı sırasıyla paket kaybı, bant genişliği doygunluğu ve kuyruk gecikmesi (jitter/bufferbloat) metrikleriyle test edilmelidir.

1. UDP Yol Kalitesi ve Paket Kaybı Analizi (MTR)

Tünelin dışındaki fiziksel ağ omurgasını denetlemek adına istemciden sunucuya 100 paketlik UDP tabanlı MTR raporu alınır:

mtr --udp -P 443 -c 100 --report 203.0.113.10

Çıktıda ara sekme (hop) noktalarındaki kayıp oranları izlenir. Yerel hatta %10-15 seviyesinde paket kaybı olsa dahi Hysteria 2 Brutal motorunun tünel içinde bu kaybı tolere edip etmediği doğrulanır.

2. Tünel İçi Ağ Doygunluğu Testi (iperf3)

SOCKS5 veya doğrudan TUN arayüzü üzerinden sunucudaki iperf3 dinleyicisine yönelik 8 paralel akışlı ters yönlü (reverse mode - download) bant genişliği ölçümü yürütülür:

# Sunucu tarafında iperf3 dinleyicisini başlatma (Loopback veya tünel IP'sinde)
iperf3 -s -p 5201

# İstemci tarafında tünel üzerinden ters yönlü doyum testi
all_proxy=socks5://127.0.0.1:10808 iperf3 -c 10.0.0.1 -p 5201 -P 8 -t 30 -R

Bu komut, 30 saniye boyunca istemcinin indirme kanalını sonuna kadar yükler. Çıktıdaki Retr (Retransmission) ve aktarılan veri (MBytes) metrikleri, Brutal algoritmasının tanımlanan hedef hıza ulaşıp ulaşmadığını gösterir.

3. QUIC Paket Kaybı ve Bufferbloat Değerlendirmesi

Hattın maksimum doygunluktayken gecikme kararlılığını ölçmek için tünel üzerinden yük altında ping testi uygulanır:

ping -c 60 -i 0.2 10.0.0.1

Boştaki RTT değeri ile iperf3 çalışırken ölçülen yük altındaki RTT değeri arasındaki fark (bufferbloat) incelenir. Kabul edilebilir farkın 20-30 ms aralığında kalması gerekir. Eğer gecikme 200 ms üzerine çıkıyorsa, istemci konfigürasyonundaki bandwidth.down değeri kademeli olarak düşürülerek yerel ağ darboğazı dengelenmelidir.

İstemci tarafında yüksek bant genişliği ve mikrosaniyelik paket işleme performansı elde edilmesi, doğrudan sunucu tarafındaki sanallaştırma mimarisine ve fiziksel ağ omurgasına bağlıdır. Çok sayıda istemcinin aynı anda şifreli QUIC akışları başlattığı senaryolarda, VDS üzerindeki işlemci çekirdeklerinin gecikmesiz tepki vermesi zorunludur. tropic.host KVM altyapısı, AMD EPYC ve Ryzen 9 donanımlarında sıfır CPU çalınma süresi (CPU Steal Time %st = 0.0%) sağlayarak istemciden gelen asenkron UDP paketlerinin çekirdek kuyruklarında bekletilmeden işlenmesini garanti eder. Bununla birlikte tropic.host'un Frankfurt, Amsterdam ve İstanbul gibi ana internet değişim noktalarındaki (IXP) doğrudan BGP eşleşmeleri ve 1–10 Gbps simetrik port kapasitesi, istemci ile sunucu arasındaki RTT dalgalanmasını (jitter) asgari seviyede tutar. Bu kararlı altyapı sayesinde yerel ISS kaynaklı yüksek paket kayıplarında bile Hysteria 2'nin Brutal tıkanıklık kontrol algoritması hattın fiziksel kapasitesini sonuna kadar kullanabilir.

Sıkça Sorulan Sorular (SSS)

Hysteria 2 neden WireGuard ve OpenVPN'den daha hızlıdır?

Hysteria 2, standart TCP yerine QUIC (UDP) protokolünü ve kendi geliştirdiği Brutal tıkanıklık kontrol algoritmasını kullanır. Yüksek paket kaybı olan ağlarda bile bağlantı hızını düşürmeden sabit tutar.

Hysteria 2 kurulumu için KVM sanallaştırma zorunlu mu?

Evet. Gelişmiş UDP soket tamponları ve çekirdek seviyesi ağ optimizasyonları için tam KVM sanallaştırma gereklidir.

Blog'a geri dön