online-mode, server.properties dosyasındaki tek satırlık bir ayar ama sunucunuzun güvenlik modelini baştan belirler. true iken sunucu, bağlanan her oyuncunun gerçekten o Microsoft hesabının sahibi olduğunu Mojang oturum sunucusuna sorarak doğrular. false yaptığınızda bu soru hiç sorulmaz; kim ne isim yazarsa o kabul edilir.
Türkiye’deki Minecraft sunucularının önemli bir kısmı bu ayarı kapalı çalıştırıyor. Bunun somut sebepleri var ve sayfanın sonunda o gerçeği dürüstçe konuşacağız. Ama önce ayarın teknik olarak ne yaptığını, kapatınca neyin kaybolduğunu ve UUID meselesinin neden geri dönüşü zor bir karar olduğunu net biçimde ortaya koyalım.
online-mode Tam Olarak Neyi Doğrular?#
Oyuncu sunucuya bağlandığında şu sıra işler: istemci kullanıcı adını gönderir, sunucu şifreleme isteği yollar, istemci Mojang oturum sunucusuna “şu sunucuya katılıyorum” der, sunucu da aynı oturum sunucusuna “bu isim gerçekten katıldı mı” diye sorar. İki taraf eşleşmezse bağlantı düşer ve konsolda kimlik doğrulama hatası görürsünüz.
Bu mekanizmanın doğruladığı tek şey vardır: bağlanan kişi, o kullanıcı adının ve UUID’nin sahibi olan hesaba giriş yapmış durumdadır. Doğrulamadığı şeyler ise şunlardır — oyuncunun hile kullanıp kullanmadığı, VPN arkasında olup olmadığı, daha önce ban yiyip yemediği. Kimlik doğrulaması bir güvenlik temelidir, güvenlik duvarı değil.
Doğrulama başarısız olduğunda karşınıza çıkan mesajlar da bu zincirin hangi halkasının koptuğunu söyler. Sunucu tarafında “Failed to verify username” satırı, oturum sunucusunun katılım kaydını görmediği anlamına gelir. İstemci tarafındaki “Bad login” çoğunlukla eşleşmeyen oturum, “Invalid Session” hatası ise başlatıcının oturumunun düşmüş olmasıdır. Mojang tarafında kesinti varsa doğrulama tamamen durur; bu senaryoda sunucunuzda bir arıza yoktur, dışarısı çalışmıyordur.
online-mode=true
enforce-secure-profile=true
prevent-proxy-connections=false
white-list=false
enforce-secure-profile imzalı sohbet profili ister ve varsayılanı true’dur. prevent-proxy-connections ise oyuncunun bildirdiği adres ile Mojang’ın gördüğü adresi karşılaştırır; yalnızca kimlik doğrulaması açıkken anlamlıdır ve VPN kullanan gerçek oyuncuları da eleyebileceği için varsayılan olarak kapalı gelir. Bu dosyadaki diğer satırların tamamı için server.properties ayarları sayfamıza bakabilirsiniz.
online-mode=false Yapınca Ne Olur?#
Ayarı kapattığınız anda sunucu oturum sunucusuyla hiç konuşmaz. Sonuçlar şunlardır:
- Kimlik doğrulanmaz. Giren kişinin o hesabın sahibi olduğuna dair hiçbir kanıt yoktur.
- Herkes her ismi kullanabilir. Bir başkasının nickiyle girmek, o ismi yazmak kadar kolaydır.
- Yetkili hesabı taklit edilebilir. Sunucu sahibinin nickini bilen biri OP yetkileriyle içeri girer.
- Skin ve pelerin yüklenmez. Profil bilgisi Mojang’dan çekilmediği için herkes varsayılan görünümdedir.
- İmzalı sohbet çalışmaz.
enforce-secure-profileaçık kalırsa oyuncular hiç giremez; kapatmanız gerekir. - UUID’ler değişir. Aşağıda ayrıntısıyla anlatıyoruz; kararın en kalıcı sonucu budur.
online-mode=false
enforce-secure-profile=false
Risk Tablosu: Kapalı Kimlik Doğrulamanın Bedeli#
Riskleri tek tek görmek, kararı duygusal olmaktan çıkarır.
| Risk | Nasıl gerçekleşir | Etkisi | Azaltma yöntemi |
|---|---|---|---|
| Yetkili taklidi | Saldırgan sahibin veya moderatörün nickiyle bağlanır | Kritik: OP komutları, dünya ve ekonomi | AuthMe zorunluluğu, OP yerine LuckPerms, IP kısıtı |
| Oyuncu hesabı gaspı | Başkasının nickiyle girip üssünü ve envanterini alır | Yüksek: veri kaybı, oyuncu kaybı | AuthMe parolası, tek oturum kuralı |
| Ban kaçırma | Ban yiyen oyuncu ismini değiştirip geri gelir | Orta: moderasyon işlevsizleşir | IP tabanlı ban, LiteBans, kayıt limiti |
| Proxy atlatma | Arka uç sunucunun portu internete açık bırakılır | Kritik: bütün ağ savunmasız | Güvenlik duvarı, 127.0.0.1’e bağlama |
| Bot ve çoklu hesap seli | Sınırsız sahte isimle bağlantı akını | Yüksek: giriş kilitlenmesi, spam | Anti-bot katmanı, IP başına kayıt limiti |
| UUID çakışması | Bir ismi bırakan oyuncunun verisi yeni sahibine geçer | Orta: karışan envanter ve yetki | Whitelist, kayıt sonrası isim kilidi |
| Sohbet imzasının kaybı | enforce-secure-profile kapatılmak zorundadır | Düşük: rapor altyapısı devre dışı | Sunucu içi loglama ve moderasyon eklentisi |
UUID Meselesi: Çevrimiçi ve Çevrimdışı Kimlik#
Minecraft oyuncuyu isimle değil UUID ile tanır. Dünya klasöründeki playerdata/<uuid>.dat, istatistikler, başarımlar; eklenti tarafında LuckPerms grupları, Essentials evleri, ekonomi bakiyesi, arazi tapuları — hepsi UUID’ye bağlıdır.
İki mod arasındaki fark burada başlıyor:
| Konu | online-mode=true | online-mode=false |
|---|---|---|
| UUID kaynağı | Mojang hesabı (v4) | Kullanıcı adından türetilir (v3) |
| İsim değişince | UUID aynı kalır, veri korunur | UUID değişir, veri kaybolur |
| Aynı ismi başkası alırsa | Farklı UUID, veriye erişemez | Aynı UUID, tüm veriyi devralır |
| Farklı sunucularda | Aynı UUID | Aynı isim, aynı UUID |
| Skin ve pelerin | Yüklenir | Yüklenmez |
| Kimlik doğrulama | Mojang yapar | Yapılmaz, eklentiye kalır |
Çevrimdışı UUID kullanıcı adından matematiksel olarak üretilir; formül sabittir ve herkese açıktır. Pratik sonucu şudur: “Ahmet” adını kullanan oyuncu hangi çevrimdışı sunucuya girerse girsin aynı UUID’yi alır. Aynı isim, aynı kimlik, aynı veri.
Bunun yarattığı iki kalıcı sorun var. Birincisi, ismini değiştiren oyuncu kendi verisine bir daha ulaşamaz. İkincisi, sunucunuzu bir gün çevrimiçi moda almaya karar verirseniz tüm oyuncu kimlikleri değişir; envanterler, yetkiler ve bakiyeler eski kayıtlarla eşleşmez.
Bu geçişin neye dokunduğunu somutlaştıralım. UUID ile saklanan veriler kabaca şunlardır:
world/playerdata/<uuid>.dat— envanter, konum, can, deneyim.world/stats/veworld/advancements/— istatistikler ve başarımlar.- LuckPerms kullanıcı kayıtları — grup, rütbe ve izin düğümleri.
- Essentials kullanıcı dosyaları — ev noktaları, kit sayaçları, ban kayıtları.
- Ekonomi bakiyesi, dükkân sahiplikleri, arazi tapuları ve ada kayıtları.
Geçişi zorunlu olarak yapmanız gerekiyorsa sıra şudur: tam yedek alın, sunucuyu kapatın, oyuncu listesinin eski ve yeni UUID eşlemesini çıkarın, dosya ve veritabanı kayıtlarını bu eşlemeye göre dönüştürün, test kopyasında birkaç hesapla doğrulayın, ancak ondan sonra yayına alın. Bu iş bir akşamda değil, planlı bir bakım penceresinde yapılır.
Proxy Arkasında Doğru Yapılandırma#
Kimlik doğrulamasını kapatmanın tek meşru sebebi budur. BungeeCord veya Velocity kullanan bir ağda oyuncuyu proxy doğrular; arka uç sunucular aynı doğrulamayı tekrar denerse oyuncu “Bad login” hatasıyla atılır. Dolayısıyla arka uçta ayar kapalı olmak zorundadır.
Velocity tarafında modern forwarding kullanılır ve paylaşılan bir gizli anahtar üretilir:
# velocity.toml (proxy)
bind = "0.0.0.0:25565"
online-mode = true
player-info-forwarding-mode = "modern"
forwarding-secret-file = "forwarding.secret"
# arka uç: config/paper-global.yml
proxies:
velocity:
enabled: true
online-mode: true
secret: 'forwarding.secret dosyasindaki degerin aynisi'
# arka uç: server.properties
online-mode=false
enforce-secure-profile=false
server-ip=127.0.0.1
server-port=25566
BungeeCord kullanıyorsanız karşılığı ip_forward: true ve arka uçta spigot.yml içindeki settings.bungeecord: true’dur. İkisini aynı anda açmayın; farklı forwarding protokolleridir. Kurulumun tamamı BungeeCord ve Velocity ile sunucu ağı kurulumu sayfasında.
Asıl kritik adım üçüncüsü: arka uç sunuculara doğrudan erişimi kapatmak. Proxy 25565’i dinlerken arka uç portları da internete açık kalırsa saldırgan proxy’yi tamamen atlar ve doğrulaması olmayan sunucuya istediği isimle bağlanır. Ağ kurulumunda en pahalıya mal olan hata budur.
# Linux (UFW): sadece proxy IP'sine izin ver
sudo ufw allow from 10.0.0.5 to any port 25566 proto tcp
sudo ufw deny 25566/tcp
# Windows: 25566 portunu yalnızca proxy IP'sine aç
New-NetFirewallRule -DisplayName "MC-Backend" -Direction Inbound -LocalPort 25566 -Protocol TCP -RemoteAddress 10.0.0.5 -Action Allow
Aynı makinede çalışan ağlarda en temiz yol server-ip=127.0.0.1 ile arka uçları yerel arayüze kilitlemektir; o zaman dışarıdan erişim fiziksel olarak mümkün olmaz. Güvenlik duvarı tarafının ayrıntısı için sunucu güvenlik duvarı yapılandırması sayfasına bakın.
AuthMe: Doğrulama Kapalıysa Zorunlu Katman#
Kimlik doğrulaması kapalı bir sunucuda AuthMe isteğe bağlı bir eklenti değildir. Mojang’ın yapmadığı işi devralır: oyuncu girer girmez hareketi kısıtlanır, /register parola parola ile hesabını açar, sonraki girişlerde /login parola yazarak kimliğini kanıtlar.
# plugins/AuthMe/config.yml (öne çıkan satırlar)
settings:
security:
passwordHash: BCRYPT
minPasswordLength: 8
restrictions:
allowChat: false
timeout: 45
maxRegPerIp: 2
sessions:
enabled: true
Hooks:
bungeecord: true
Bağlantılar resmî kaynaklara gider. Üçüncü taraf sitelerden jar indirmeyin.
Türkiye’deki Sunucu Gerçeği#
Şimdi konuşmadan geçilmeyen kısma gelelim. Türkiye’de Minecraft oynayan kitlenin ciddi bir bölümü lisanssız istemci kullanıyor ve kimlik doğrulaması açık bir sunucuya bu oyuncular giremiyor. Sunucu sahibi açısından denklem basit görünüyor: ayarı kapat, oyuncu sayın birkaç katına çıksın.
Dürüst değerlendirme şu: bu bir güvenlik kararı değil, iş kararıdır ve bedeli vardır. Bedeli ödemeye razıysanız hiç değilse bilerek ödeyin.
- Kimlik altyapınız kalıcı olarak zayıf olur. Parolayı unutan oyuncu, parolası çalınan oyuncu, isim değiştirmek isteyen oyuncu; hepsi manuel destek işi üretir.
- Moderasyon zorlaşır. Ban yiyen oyuncu isim değiştirip geri gelir. IP tabanlı önlemler gerekir, onlar da paylaşımlı bağlantılarda masumları vurur.
- Hile ve bot tarafı ağırlaşır. Hesap maliyeti sıfır olduğu için saldırgan sınırsız isimle deneme yapabilir. Bot saldırısı önleme önlemleri ek yük getirir.
- Lisanssız istemcilerin kendi riskleri var. Oyuncularınızın kullandığı başlatıcılar hakkında TLauncher güvenli mi sayfasındaki bulgular okumaya değer.
- Oyunun geliştiricisi bu gelirden pay almaz. Bu, teknik değil etik bir maliyettir ve göz ardı edilmesini önermiyoruz.
Orta yol arayanlar için pratik bir yaklaşım var: proxy üzerinde oyuncu bazlı doğrulama. Proxy, bağlanan ismi Mojang’a sorar; hesap gerçekse şifreli doğrulama yapar, değilse AuthMe parolasına düşer. Böylece lisanslı oyuncular parola girmeden ve taklit edilemeden oynar, diğerleri parolayla girer. Kurulumu zahmetlidir ve yanlış yapılandırıldığında tam tersi sonucu doğurur — yani lisanslı hesapların taklit edilmesine kapı açar. Kuracaksanız test sunucusunda doğrulamadan yayına almayın.
Hangi Ayarı Seçmelisiniz?#
| Durumunuz | Doğru ayar | Ek olarak yapılacak |
|---|---|---|
| Arkadaş grubu, küçük survival | online-mode=true | Whitelist açın, başka bir şeye gerek yok |
| Halka açık lisanslı sunucu | online-mode=true | Anticheat, LuckPerms, düzenli yedek |
| Proxy arkasındaki alt sunucu | online-mode=false | Forwarding + güvenlik duvarı zorunlu |
| Lisanssız oyuncu kabul eden sunucu | online-mode=false | AuthMe, anti-bot, IP tabanlı ban altyapısı |
| Test veya yerel geliştirme | online-mode=false | Dışarıya kapalı tutun |
Kararsız kaldığınız noktada varsayılana güvenin: online-mode=true. Kapatmak için elinizde somut bir sebep yoksa açık bırakın. Genel güvenlik kontrol listesi için Minecraft sunucu güvenliği rehberimiz yardımcı olur; küçük bir topluluk işletiyorsanız beyaz liste açmak, kimlik doğrulaması açık bir sunucuda bile en ucuz ek katmandır. Altyapı tarafında ne yapacağınızdan emin değilseniz Minecraft sunucu paketlerimizle gelen destek ekibine danışabilirsiniz; kurulum öncesi bu kararı doğru vermek, sonradan veri taşımaktan çok daha ucuza gelir.
Özetle#
online-mode tek satır, ama arkasında sunucunuzun bütün kimlik modeli duruyor. true iken Mojang oturum sunucusu her oyuncunun gerçekten o hesabın sahibi olduğunu doğrular; false iken böyle bir kontrol hiç yapılmaz ve isim yazan herkes o kişi sayılır.
Kararın en kalıcı sonucu UUID tarafındadır. Çevrimiçi kimlik hesaba, çevrimdışı kimlik isme bağlıdır; bu yüzden çevrimdışı sunucuda isim değiştiren oyuncu verisini kaybeder, o ismi alan başkası veriyi devralır. Modlar arası geçiş de bütün oyuncu kayıtlarını yeniden eşleştirmeyi gerektirir. Yedeksiz denemeyin.
Proxy arkasında online-mode=false zorunludur ve tamamen normaldir; şartı, forwarding’in doğru kurulması ve arka uç sunucuların güvenlik duvarıyla dışarıya kapatılmasıdır. Lisanssız oyuncu kabul eden sunucularda ise AuthMe pazarlık konusu değildir. Bunun dışında kalan hiçbir durumda ayarı kapatmak için geçerli bir sebep yok; varsayılanı bozmadan bırakmak yapabileceğiniz en ucuz güvenlik yatırımıdır. Sonradan telafi etmeye çalışmak, baştan doğru kurmaktan her zaman pahalıya mal oluyor — bu konuda hala tereddüt eden sunucu sahiplerinin bir kısmı bunu zor yoldan öğreniyor.