Discord Engeli Linux'ta Nasıl Aşılır?

Discord Türkiye’de Ekim 2024’ten beri erişime kapalı. Fedora yüklü dizüstümde masaüstü programı bu yüzden hiç açılmıyordu: simgeye tıklayınca “İlerleme — Downloading Discord” yazan küçük bir pencere açılıyordu ve ilerleme çubuğu hiç dolmuyordu. Program açılıp “bağlanamadım” bile demiyordu; kendini indiremediği için hiç başlamıyordu.

Ne yaptım: Discord’u Cloudflare WARP üzerinden çalıştırdım. WARP, Cloudflare’in ücretsiz ve veri sınırı olmayan VPN hizmeti. Ama bütün bilgisayarı VPN’e almadım — bunu özellikle istemedim.

Kurulumun kapsamı şöyle:

• VPN yalnızca Discord açıkken çalışıyor; Discord kapanınca kendiliğinden kapanıyor.
• VPN yalnızca Discord’un içinde geçerli. Tarayıcı, sistem güncellemeleri, Docker, bankacılık — hepsi normal bağlantıdan gidiyor.
• Bilgisayarın geri kalanında hiçbir ayar değişmiyor: sistem DNS’i, yönlendirme tablosu ve güvenlik duvarı aynı kalıyor.
• Discord kapanınca geride ağ alanı, tünel ya da kural kalmıyor; hepsi siliniyor.

Bunu Linux’un ağ alanı (network namespace) özelliğiyle yaptım. Nasıl yaptığımı aşağıda adım adım anlatıyorum.

Bir ayrıntı daha var: tarayıcımdan discord.com açılıyordu ama program açılmıyordu. Üç ay önce modemde DNS’i değiştirmiştim ve o değişiklik işe yaramıştı — ama yalnızca tarayıcıda, ve yalnızca bazı siteler için. Discord’un programına hiçbir faydası olmadı. Buradaki farkın sebebi de o değil; deneyerek eledim. Fark DNS’te değil, kullanılan protokolde. Buna varmam zaman aldı: önce yanlış bir teşhis koydum, deneyince düzelttim. Onu da yazdım.

Sistemim / Test Ortamı#

• İşletim sistemi: Fedora 44, KDE Plasma (Wayland)
• Discord: paket sürümü 1.0.163 (terra deposu), program sürümü 1.0.164
• Tarayıcı: Brave
• DNS: modemde 1.1.1.1 + 1.0.0.1 (ikisi de Cloudflare)
• İnternet: Türk Telekom, Türkiye
• Kablosuz arayüz: wlo1

Aşağıdaki komutların birkaçında kablosuz arayüzün adı geçiyor; sizinki farklı olabilir:

ip -br link

lo          UNKNOWN   00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
wlo1        UP        xx:xx:xx:xx:xx:xx <BROADCAST,MULTICAST,UP,LOWER_UP>
docker0     UP        xx:xx:xx:xx:xx:xx <BROADCAST,MULTICAST,UP,LOWER_UP>

(MAC adreslerini gizledim, Docker’ın köprülerini de kısalttım.)

Kablosuz arayüzün adı wl ile başlar: wlo1, wlan0, wlp3s0 gibi. Kablolu bağlantı en ya da eth ile başlar. lo geri döngü arayüzü; docker0 ve br-... ile başlayanlar Docker’ın sanal köprüleri, onlar değil.

Engel aslında nereye konuyor?#

Çözümden önce bu lazım, çünkü hangi engelle uğraştığınızı bilmezseniz yanlış aracı kullanıyorsunuz.

Bir siteye girerken arka planda üç şey oluyor ve engel bu üç noktadan birine konabiliyor:

Üçü farklı şeylerle aşılıyor: birincisi başka bir DNS ile, üçüncüsü yalnızca VPN ile. Discord ikinci gruptaki engel. Yani adres sorma kısmı çalışıyor, sunucunun IP’si de açık. Operatör bağlantıyı, kurulurken gönderilen “discord.com” adını gördüğü için kesiyor.

Zaten yapmış olduğum şey: DNS’i değiştirmek#

Bu kurulumdan üç ay önce, Temmuz’da, modemin DNS ayarını değiştirmiştim. Önce onu anlatayım, çünkü Discord için neden yetmediğini açıklıyor.

O zamanki sorun şuydu: bazı siteler bazen açılıyor, bazen açılmıyordu. Hepsinin ortak noktası Cloudflare arkasında olmalarıydı. Sebebi şuydu:

• Türk Telekom, Cloudflare’in 188.114.96.0/22 adres aralığını tamamen kapatmış (yukarıdaki tabloda 3. yöntem).
• Google DNS (8.8.8.8) bu sitelere hep o kapalı aralıktan adres veriyordu.
• Cloudflare DNS (1.1.1.1) ise hep çalışan aralıktan (104.21.x, 172.67.x) adres veriyordu.
• Modemde ikisi birden tanımlıydı. Bilgisayar bazen Google’ın cevabını kullanıyor, site açılmıyordu; bazen Cloudflare’inkini kullanıyor, açılıyordu.

Yani o siteler aslında engelli değildi; DNS bana engelli bir adres veriyordu. Aynı site, başka bir adresten sorunsuz açılıyordu.

Modemden 8.8.8.8’i kaldırıp yalnızca 1.1.1.1 bırakınca sorun tamamen bitti (15 denemenin 15’i başarılı). Sonradan yedek olarak 1.0.0.1 de ekledim — o da Cloudflare ve aynı çalışan aralığı veriyor. Tek DNS bırakırsanız ona ulaşılamadığında internetiniz tamamen durur.

# Hangi DNS kullanılıyor?
resolvectl status wlo1 | grep "DNS Servers"
# Beklenen: DNS Servers: 1.1.1.1 1.0.0.1

# Bir sitenin hangi adrese çözüldüğü
getent ahosts discord.com

162.159.128.233 STREAM discord.com
162.159.128.233 DGRAM
162.159.128.233 RAW
162.159.135.232 STREAM
...

İlk sütun adres. Burada 162.159.x görünüyor, yani çalışan aralık. Eğer 188.114.96.x ya da 188.114.97.x görürseniz operatörün kapattığı aralıktaki bir adres gelmiş demektir; o sitede “bazen açılıyor bazen açılmıyor” sorununu yaşarsınız.

Bunun Discord’a faydası olmadı. Üstelik Discord o sorundan hiç etkilenmemiş bile; baktım:

dig +short A discord.com @1.1.1.1   # 162.159.136.232, 162.159.137.232 ...
dig +short A discord.com @8.8.8.8   # 162.159.135.232, 162.159.138.232 ...

İki DNS de 162.159.x veriyor, yani ikisi de çalışan aralıktan. Engelli 188.114.96.0/22 aralığı Discord’a hiç denk gelmiyor. Google DNS’in soruna yol açtığı siteler ayrıydı; Discord onlardan biri değil.

Zaten beklenmezdi de: DNS değiştirmek 1. yöntemdeki engelleri aşar, Discord ise 2. yöntemle engelli. Adresi hep doğru öğreniyordum; operatör bağlantıyı, o adrese bağlanırken gönderdiğim site adını gördüğü için kesiyordu.

DNS değişikliğinin asıl faydası başka oldu. Tarayıcıda bazı sitelerin açılmasını sağladı, üstüne bir yan etki getirdi: sistem DNS’i Cloudflare olunca Brave onu şifreli olarak (DNS-over-HTTPS) kullanmaya başlıyor, yani operatör artık neyi sorduğumu da göremiyor.

Program tam olarak nerede takılıyor?#

Discord’un neyi indirmeye çalıştığını anlamak için paketin içine baktım:

rpm -ql discord

/usr/bin/discord
/usr/share/applications/discord.desktop
/usr/share/discord
/usr/share/discord/updater_bootstrap
/usr/share/pixmaps/discord.png

Discord’un kendisi paketin içinde yok. Sadece updater_bootstrap adında bir indirici var.

/usr/bin/discord de küçük bir kabuk betiğiymiş. Yaptığı iş özetle şu:

discord_host=$HOME/.config/discord/Discord      # asıl program burada olmalı

if [ ! -x "$discord_host" ]; then               # program yoksa:
    # "Downloading Discord" penceresini aç ve
    # https://updates.discord.com/ adresinden indir
    app_dir=`/usr/share/discord/updater_bootstrap --zenity "$HOME/.config/discord" stable https://updates.discord.com/`
    exec "$HOME/.config/discord/$app_dir/Discord"
fi
exec "$discord_host"

~/.config/discord/ klasörümde eski bir installer.db vardı, program yoktu. Takıldığı yer de böylece belli oldu: updates.discord.com adresine bağlanamıyor, indirme hiç başlamıyordu.

Hangi Discord adresleri kapalı?#

for h in updates.discord.com dl.discordapp.net discord.com gateway.discord.gg; do
  printf "%-22s " $h
  curl -s -o /dev/null -w "%{http_code}\n" --max-time 10 https://$h/
done

updates.discord.com    000
dl.discordapp.net      301
discord.com            000
gateway.discord.gg     000

000 “hiç cevap alınamadı” demek. curl’ün çıkış kodu 35’ti (SSL bağlantı hatası) ve bağlantı 0,05 saniyede kesiliyordu. Bu hız, 2. yöntemle konan engelin tipik izi: paket karşı tarafa hiç varmıyor, aradaki bir cihaz el sıkışma daha bitmeden kesiyor.

İki şey dikkatimi çekti:

• dl.discordapp.net açık (301 döndü). Bu bir dosya sunucusu ve adının içinde “discord.com” geçmiyor. Engelin tam olarak hangi adlara bakıp hangilerine bakmadığını gösteriyor.
• gateway.discord.gg kapalı. Bu, Discord’un sohbet sunucusu. Yani eski bir sürüme dönmek işe yaramazdı: program açılsa bile hesabıma bağlanamazdı. Bir yerde “eski sürümü kur” tavsiyesi görürseniz, bu yüzden çalışmaz.

Asıl soru: tarayıcı nasıl giriyor?#

Buraya kadar her şey beklediğim gibiydi. Açıklanmayan tek şey şuydu: aynı anda tarayıcımdan discord.com açılıyordu.

En bariz açıklama modemdeki DNS değişikliğiydi, ama o olamaz. İki sebepten:

• discord.com hem 1.1.1.1’de hem 8.8.8.8’de aynı çalışan aralığa çözülüyor (yukarıda gösterdim), yani Discord o sorundan hiç etkilenmemişti.
• DNS bütün bilgisayar için aynı. Tarayıcı da curl de aynı adresi öğreniyor, ama biri giriyor diğeri giremiyor.

İkincisi asıl kanıt: aynı bilgisayar, aynı DNS, aynı adres — sonuç farklı. Demek ki fark adreste değil, o adrese nasıl bağlanıldığında. Tarayıcı, operatörün denetlemediği bir şey yapıyordu. Ne?

Yanlış teşhis (dürüst not)#

Şöyle düşündüm: “Tarayıcı şifreli site adı (ECH, Encrypted Client Hello) kullanıyordur. ECH, bağlanırken söylenen site adını da şifreliyor. Operatör adı göremeyince kesemiyor. Discord programında ECH yok, o yüzden adını açıkça söylüyor ve kesiliyor.”

Mantıklı geliyordu, hatta bir süre doğru kabul ettim. ECH’nin zaten tam olarak 2. yöntemdeki engeli aşmak için var olması bunu daha da inandırıcı yapıyordu.

Sonra denedim. ECH, sitenin DNS üzerinden yayınladığı bir anahtarla çalışıyor; site o anahtarı yayınlamıyorsa ECH hiç devreye giremiyor:

dig +short HTTPS discord.com           @1.1.1.1
dig +short HTTPS gateway.discord.gg    @1.1.1.1
dig +short HTTPS updates.discord.com   @1.1.1.1
dig +short HTTPS crypto.cloudflare.com @1.1.1.1   # karşılaştırma için

discord.com            1 . alpn="h3,h2" ipv4hint=162.159.128.233,...
gateway.discord.gg     1 . alpn="h2"    ipv4hint=162.159.130.234,...
updates.discord.com    1 . alpn="h3,h2" ipv4hint=162.159.128.233,...
crypto.cloudflare.com  1 . alpn="h2"    ipv4hint=162.159.135.79,... ech=AEX+DQBBJgAgACB7PKDZ...

(Adres listelerini kısalttım.)

Discord’un hiçbir adresinde ech= alanı yok. Karşılaştırma için baktığım crypto.cloudflare.com satırının sonunda ise ech= duruyor.

Bu çıktıda ikinci bir şey daha var, sonradan işime yarayacak: gateway.discord.gg satırında yalnızca alpn="h2" yazıyor, h3 yok. Diğer iki adreste h3 var. Yani sohbet sunucusu HTTP/3’ü hiç duyurmuyor.

Yani teşhisim yanlıştı. Discord ECH yayınlamıyor, dolayısıyla tarayıcı da Discord’a ECH ile bağlanmıyor. --enable-features=EncryptedClientHello gibi bir bayrakla bunu zorlamak da bu yüzden işe yaramaz.

Ama bu yanlış teşhisi test ederken asıl cevabı buldum: alpn="h3,h2" satırındaki h3, HTTP/3 demek.

Asıl sebep: engel yalnızca TCP’yi kesiyor#

Aynı adrese iki farklı protokolle bağlanmayı denedim:

curl -s -o /dev/null -w "%{http_code}\n" --http2      https://discord.com/   # TCP üzerinden
curl -s -o /dev/null -w "%{http_code}\n" --http3-only https://discord.com/   # UDP üzerinden

000    ← TCP: kesiliyor
200    ← QUIC (UDP): açılıyor

Cevap buydu: operatör site adını görüp bağlantıyı kesiyor, ama bunu yalnızca TCP’de yapıyor. Aynı trafik UDP üzerinden, yani HTTP/3 (QUIC) ile gittiğinde engellenmiyor.

Brave varsayılan olarak QUIC kullanıyor; tarayıcıda açılmasının sebebi bu. curl ise varsayılan olarak TCP kullanıyor, o yüzden açılmıyordu. Aynı bilgisayarda iki farklı sonuç almamın sebebi engel değil, hangi protokolü kullandığımdı.

Peki program neden QUIC kullanamıyor? Tablonun son satırı cevap veriyor: gateway.discord.gg QUIC desteklemiyor. Yukarıdaki DNS çıktısı da aynı şeyi söylüyordu: o adres yalnızca alpn="h2" duyuruyor. İki ayrı yerden aynı sonuç. Discord’un sohbet bağlantısı bir WebSocket ve yalnızca TCP üzerinden çalışıyor. Program ne yaparsa yapsın o bağlantıyı kurmak zorunda, kesilen de tam o.

Yani tarayıcıdaki Discord sayfası açılıyor çünkü QUIC var; masaüstü programı açılmıyor çünkü sohbet sunucusu TCP’den başka yol bilmiyor. Programı çalıştırmanın tek yolu, trafiğini operatörün hiç göremeyeceği bir tünele sokmak.

Çözüm: VPN, ama sadece Discord’un içinde#

Bütün bilgisayarı VPN’e almak istemedim. Sebeplerim:

• Bankacılık ve resmî işlemler normal bağlantıdan gitmeli.
• Docker ağlarım ve uzak erişim kurulumum var; bir sistem VPN’i bunlarla çakışabilir.
• Tek bir programın sorunu için bütün makineyi tünele sokmak gereksiz.

Linux’ta bunun doğrudan karşılığı ağ alanı (network namespace). Bir programa kendine ait, izole bir ağ yığını veriyorsunuz; o alandaki program sistemin ağını değil, kendi ağını görüyor.

Bilgisayar
│
├─ Brave · güncellemeler · Docker · diğer her şey
│    └──► Normal internet        (kendi IP'niz, warp=off)
│
└─ Discord'un ağ alanı
     └──► WARP tüneli ──► Cloudflare ──► Discord sunucuları
                                         (warp=on)

Kullandığım araçlar, hepsi ücretsiz ve açık kaynak:

Asıl işi vopono yapıyor: ağ alanını açıyor, tüneli onun içine kuruyor, programı orada başlatıyor ve program kapanınca hepsini siliyor.

Kurulum#

Araçları ayrı bir klasöre indirdim ve indirdiğim dosyayı yayıncının açıkladığı kontrol koduyla karşılaştırdım:

mkdir -p ~/Uygulamalar/discord-vpn/indir && cd ~/Uygulamalar/discord-vpn/indir

curl -LO https://github.com/ViRb3/wgcf/releases/download/v2.3.1/wgcf_2.3.1_linux_amd64
curl -LO https://github.com/ViRb3/wgcf/releases/download/v2.3.1/checksums.txt
curl -LO https://github.com/jamesmcm/vopono/releases/download/1.0.2/vopono_1.0.2_amd64_fedora.rpm

sha256sum wgcf_2.3.1_linux_amd64     # checksums.txt içindekiyle karşılaştırıldı: eşleşti

cd ..
install -m 755 indir/wgcf_2.3.1_linux_amd64 ./wgcf
sudo dnf5 install wireguard-tools ./indir/vopono_1.0.2_amd64_fedora.rpm

Ücretsiz WARP hesabını açıp WireGuard ayarını ürettim:

./wgcf register --accept-tos
./wgcf generate                       # → wgcf-profile.conf

Gerisini kurmadan önce tünelin çalıştığını doğruladım:

vopono exec --custom ./wgcf-profile.conf --protocol wireguard \
    "curl -s https://www.cloudflare.com/cdn-cgi/trace"

warp=on
loc=TR

warp=on satırı, o alanın içindeki trafiğin WARP üzerinden çıktığını söylüyor. loc=TR ise konumun yine Türkiye göründüğünü: WARP en yakın Cloudflare sunucusunu kullanıyor.

Her seferinde bu komutu yazmamak için küçük bir başlatıcı betik yazdım:

#!/usr/bin/env bash
# Discord'u yalnız kendine ait bir ağ alanında, Cloudflare WARP üzerinden çalıştırır.
cd "$(dirname "$0")"
exec vopono exec --custom ./wgcf-profile.conf --protocol wireguard discord "$@" \
     >>"$HOME/.local/state/discord-vpn.log" 2>&1

Son olarak menüdeki Discord girdisini bu betiğe yönlendirdim. Kullanıcı klasöründeki .desktop dosyası aynı addaki sistem dosyasının yerine geçtiği için menüde ikinci bir girdi oluşmuyor:

sed -e "s|^Exec=.*|Exec=$HOME/Uygulamalar/discord-vpn/discord-vpn.sh|" \
    -e "s|^Name=Discord$|Name=Discord (VPN)|" \
    /usr/share/applications/discord.desktop > ~/.local/share/applications/discord.desktop
update-desktop-database ~/.local/share/applications

Bu komutun çıktısı yok, bir dosya üretiyor. Doğru üretildiğini iki satıra bakarak anlıyorum:

grep -E "^(Name|Exec)=" ~/.local/share/applications/discord.desktop

Name=Discord (VPN)
Exec=/home/kullanici/Uygulamalar/discord-vpn/discord-vpn.sh

Exec artık /usr/bin/discord’u değil kendi betiğimi gösteriyor. Artık menüden tıklayınca Discord açılıyor, VPN otomatik devreye giriyor, Discord kapanınca VPN de kapanıyor. Başka bir şey açıp kapatmak gerekmiyor. Kurulumdan sonra Discord kendini tünel üzerinden indirdi ve açıldı.

Doğrulama#

Burası benim için en önemli kısım: bir kurulumun çalışıyor görünmesi ile gerçekten doğru çalışması farklı şeyler.

Discord gerçekten kendi alanında mı?

sudo ip netns identify $(pgrep -xo Discord)
# vo_c_FDYSro1

Bilgisayarın geri kalanı etkilenmiş mi?

curl -s https://www.cloudflare.com/cdn-cgi/trace | grep warp=
# warp=off          ← ana sistem VPN'de değil

curl -s -o /dev/null -w "%{http_code}\n" https://discord.com/
# 000               ← hâlâ kapalı, yani VPN sisteme geçmemiş

İkinci komut asıl kanıt. Ana sistemden discord.com hâlâ açılmıyorsa, VPN gerçekten sadece Discord’un alanında demektir. Açılsaydı VPN’in sisteme sızdığını anlardım.

Tünel düşerse trafik normal internete kaçar mı?

vopono alanın içine bir sızıntı koruması (kill switch) kuruyor. Bunu belgesinde okumak yetmez, denedim: tüneli elle düşürüp alanın içinden bağlanmaya çalıştım.

ns=vo_c_FDYSro1
sudo ip netns exec $ns ip link set $ns down                              # tüneli düşür

sudo ip netns exec $ns curl -4 https://1.1.1.1/                          # çıkış 7 (reddedildi)
sudo ip netns exec $ns curl -6 'https://[2606:4700:4700::1111]/'         # çıkış 7 (reddedildi)
sudo ip netns exec $ns dig @8.8.8.8 discord.com                          # connection refused
sudo ip netns exec $ns curl --interface ${ns}_s https://1.1.1.1/         # çıkış 7 (reddedildi)

Dördü de reddedildi: IPv4, IPv6, TCP ve UDP. Tünel düştüğünde Discord’un trafiği normal bağlantıya düşmüyor, tamamen engelleniyor. Tüneli geri açınca warp=on geri geldi.

VPN ne kadar yavaşlatıyor?

Aynı testi 10 kez VPN kapalıyken, 10 kez de Discord’un VPN’li alanının içinden çalıştırdım. Her denemede ölçtüğüm şey aynı: 1.1.1.1 adresine TCP bağlantısı kurmanın kaç milisaniye sürdüğü. Tablodaki sayılar bu denemelerin özeti:

Ortalama fark +3,3 ms. WARP İstanbul’daki Cloudflare sunucusunu kullanıyor (colo=IST), gecikmenin düşük kalmasının sebebi bu. Sesli kanala girip konuştum ve ekran paylaştım; ikisi de sorunsuz çalıştı.

Neden başka yöntemleri seçmedim?#

Bu engeli aşmanın birden fazla yolu var ve her birinin eksiği başka yerde. Hangisinin size uyduğu, neye öncelik verdiğinize bağlı:

byedpi ve zapret’i denemedim; ilk aklıma gelen VPN oldu. Paket bölme yöntemleri daha hafif ve sizin için daha uygun olabilir, ama ikisi birbirinin aynısı değil:

• byedpi bir vekil olduğu için ses trafiğini taşımıyor. Sesli kanal kullanacaksanız tek başına yetmez.
• zapret sesi etkilemiyor, yani o taraftan sorun yok. Karşılığında sistem geneline kalıcı bir servis ve güvenlik duvarı kuralı kuruyor — benim her açılışta sudo isteyen kurulumumdan daha derine iniyor.

Yani “hangisi daha iyi” diye tek bir cevap yok. Sesli kanal kullanmıyorsanız byedpi en hafifi; sistem geneline kalıcı kural koymaktan çekinmiyorsanız zapret en az uğraştıranı.

Cloudflare’in resmî WARP istemcisini de kullanmadım. Linux sürümünde “yalnızca şu uygulama” diye bir seçenek yok. Hangi trafiğin tünelden geçeceğini uygulamaya göre değil adrese göre seçebiliyorsunuz; yani Discord’un bütün sunucu adreslerini elle listelemeniz gerekir. Ses sunucuları da sabit değil, o listeyi güncel tutmak ayrı bir iş. Varsayılan ayarında ise bütün bilgisayarı VPN’e alıyor — kaçındığım şey tam olarak buydu.

Bilinmesi gerekenler#

Bunlar kurulum sırasında değil, sonradan günlük kullanımda ortaya çıktı:

• Discord’daki linkler. Önce şu açık vardı: tarayıcı kapalıyken Discord’daki bir linke tıklayınca tarayıcı Discord’un alanının içinde açılıyor ve o da VPN’e giriyordu. Kalıcı çözüm için xdg-open için küçük bir sarmalayıcı yazdım; systemd-run --user ile tarayıcıyı kullanıcının systemd yöneticisinden başlatıyor, böylece link her zaman ana ağdaki tarayıcıda açılıyor.

• Ağ simgesinde görünen bağlantı. Discord açıkken KDE ağ simgesinde vo_c_... adında bir “kablolu bağlantı” görünüyor. Bu, Discord’un alanına giden sanal kablonun ana sistemdeki ucu. Başka program kullanmıyor, Discord kapanınca kayboluyor.

• Konum gizlenmiyor. WARP gerçek IP adresinizi Discord’dan gizliyor ama konum yine Türkiye görünüyor, çünkü WARP size en yakın Cloudflare sunucusunu kullanıyor. Amaç gizlenmek değil, engeli aşmak.

• Yönetici yetkisi. Ağ alanı açmak sudo istiyor. Her açılışta parola sorulmasını istemiyorsanız doğru yol vopono daemon, yani onun yetkili arka plan servisi. sudo’yu tamamen parolasız yapmak kolay görünür ama bütün sistem için ciddi bir taviz; o yolu önermiyorum.

• Güncellemeler. dnf ile gelen Discord güncellemeleri menü girdisini bozmuyor; Discord kendi iç güncellemelerini de tünelden indiriyor.

Sık sorulan sorular#

Bütün bilgisayarım VPN’e mi giriyor?

Hayır. Tarayıcıda cloudflare.com/cdn-cgi/trace açın, warp=off görürsünüz. VPN yalnızca Discord çalışırken ve yalnızca onun ağ alanında açık.

Sesli sohbet ve ekran paylaşımı çalışıyor mu?

Evet, ikisini de denedim, sorun çıkmadı. Ağ alanı yöntemi Discord’un UDP trafiğini de tünelden geçiriyor.

Sadece DNS değiştirsem yetmez mi?

Yetmez. DNS değiştirmek yalnızca 1. yöntemle konan engelleri aşar. Discord 2. yöntemle engelli: adresi doğru öğreniyorsunuz ama bağlanırken kesiliyorsunuz.

Discord’u tarayıcıdan kullansam olmaz mı?

Sayfa açılıyor, çünkü tarayıcı QUIC kullanıyor. Ama sohbet sunucusu QUIC desteklemediği için mesajların gerçekten gelip gelmediğini ayrıca denemek gerekir; sayfa açılsa bile “bağlanıyor…” diye kalabilir.

WARP ücretli mi?

Hayır. Ücretsiz WARP hesabı kullanıyorum, veri sınırı yok.

Eski bir Discord sürümüne dönsem olmaz mı?

Olmaz. Sohbet sunucusu gateway.discord.gg de kapalı olduğu için program açılsa bile hesabınıza bağlanamaz.

Bu yöntem başka programlar için de kullanılır mı?

Evet. vopono exec ... <program> kalıbı herhangi bir program için çalışır. Mantık aynı: programa kendi ağ alanını verip VPN’i yalnızca orada çalıştırmak.

Bunu yapmak yasal mı?

Erişim engelleri ve bunları aşma yöntemlerinin hukuki durumu ülkeye göre değişir ve zamanla değişebilir. Bu yazı teknik bir anlatım; kullanım kararı ve sorumluluğu size ait.

Sonuç#

Discord’un engelli olduğunu baştan biliyordum. Bilmediğim şey, o engelin neye bakıp neyi kestiğiydi.

Operatör “Discord’u tamamen kapat” diye bir şey yapmıyor. Bağlanırken açıkça gönderilen site adını görüyor ve yalnızca TCP bağlantılarını kesiyor; UDP üzerinden giden aynı trafiği engellemiyor. Tarayıcımın girip programımın girememesinin tek sebebi buydu: biri QUIC kullanabiliyor, diğerinin sohbet sunucusu kullanamıyor.

Bu arada bir şey daha öğrendim: bir açıklamanın mantıklı olması doğru olduğunu göstermiyor. “Tarayıcı ECH kullandığı için giriyor” açıklaması kulağa makuldü, üstelik ECH tam olarak bu engel için icat edilmiş bir şey. Ama denediğimde Discord’un ECH’yi hiç yayınlamadığı çıktı. Doğru cevabı da tam o yanlışı test ederken buldum; ECH kaydı ararken gördüğüm alpn="h3,h2" satırı olmasa muhtemelen fark etmeyecektim.

Aynı şeyi sanal makinenin internet sorununu çözerken de yaşamıştım: orada da ayarlar doğru görünüyordu ve beni yanıltan tam olarak buydu. İki seferde de doğru cevabı tahmin değil, çalıştırdığım komutlar verdi.

Hızlı kontrol komutları (özet)#

# 1) Engel TCP'de mi? (ilki 000, ikincisi 200 ise evet)
curl -s -o /dev/null -w "%{http_code}\n" --http2      https://discord.com/
curl -s -o /dev/null -w "%{http_code}\n" --http3-only https://discord.com/

# 2) Site ECH yayınlıyor mu? ("ech=" yoksa ECH ile çözülmez)
dig +short HTTPS discord.com @1.1.1.1

# 3) DNS doğru mu? (188.114.96.x çıkıyorsa yanlış DNS kullanılıyor)
resolvectl status wlo1 | grep "DNS Servers"

# 4) Discord gerçekten kendi ağ alanında mı?
sudo ip netns identify $(pgrep -xo Discord)

# 5) VPN sistemin geri kalanına geçmiş mi? (ana sistemde warp=off ve discord.com 000 olmalı)
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep warp=
curl -s -o /dev/null -w "%{http_code}\n" https://discord.com/

Aynı engelle uğraşıyorsanız yorumlarda anlatın. Hangi dağıtımda ve hangi operatörde olduğunuzu yazarsanız başkalarına da yol gösterir; engelleme yöntemi operatöre göre değişebiliyor.