Blog

4.5G/LTE ve Starlink’te EchoLink Node Sorunu: Neden Bağlanamıyorsunuz? ISS Trafik Şekillendirme, CGNAT ve TCP Proxy Çözümü”

  • Reading time:17 mins read
HOW TCP SAVES ECHOLINK NODES

Herkese Merhaba,

Uzun bir aradan sonra yeni bir gönderi ile tekrar karşınızdayım.

Bildiğiniz üzere, 2024 yılında Türkiye Radyo Amatörleri Cemiyeti (TRAC) Kapaklı Şubesi (YM1KPL) için kurduğum EchoLink sistemi, fiber internet altyapısı üzerinde sorunsuz bir şekilde çalışmaktaydı. İlk kurulum sürecinde, CGNAT belası sebebiyle almak zorunda kaldığım sabit IP ve ardından gelen karmaşık port yönlendirme yapılandırmalarıyla epey boğuşmuştum. Test süreçlerini başarıyla tamamlamıştık ancak daha sonra gerçekleşen yer değişikliği sebebiyle sistemi 4.5G mobil şebeke üzerinden kullanma zorunluluğu doğdu.

Yeniden port yönlendirme vb. bildik süreçlerden geçerek sistemi 4.5G üzerinde de ayağa kaldırmayı başarabildik. Ancak bu sefer karşımıza başka bir duvar çıktı. Fiber internette sorun çıkarmayan “node firewall” kaynaklı süreçler, mobil şebekede başımıza dert oldu. Özellikle çevrimlerin kalabalık olduğu günlerde bağlantı kopmaları, ses kesilmeleri veya sisteme hiç girilememesi gibi can sıkıcı sorunlar yaşamaya başladık.

Ne kadar ince ayar denemesi yapsam da, ne yazık ki bu sorunu mevcut yapıyla aşamadım. Fakat problemi çözüme kavuşturmaya da kararlıydım. Hal böyle olunca, araştırmalarım sonucunda karşıma tek bir kesin çözüm yolu çıktı: EchoLink Proxy.

İlk etapta proxy sunucusunu kendi evimdeki bir Raspberry Pi üzerinde barındırmayı düşündüm. Ancak ev için alacağım sabit IP’nin maliyeti ile dışarıdan bir sunucu kiralama maliyeti hemen hemen aynı kapıya çıkıyordu. Bu nedenle, daha stabil ve kesintisiz olacağını düşündüğüm bir bulut sunucu (VPS) kiralayarak durumu kökten çözmeye karar verdim.

İşin hikaye kısmını geçtiğimize göre, şimdi okuyucu kitlemin asıl merak edeceği o kritik soruya gelelim: Ne oluyor da EchoLink 4.5G/LTE/Starlink gibi ağlarda kararlı çalışmıyor? Bunu derinlemesine anlayabilmek için öncelikle internetin temel taşları olan TCP ve UDP protokollerinin ne olduğunu kavramamız gerekiyor.

NOT: Bu rehber her ne kadar bireysel EchoLink kullanıcıları için de geçerli olsa da, özellikle 7/24 aktif kalması gereken Repeater (-R) ve Link (-L) istasyonları (Node sahipleri) için tasarlanmıştır. Standart kullanıcılar için bağlantı kalitesini artırırken, Node sahipleri için sistemin ‘ölümsüz’ ve erişilebilir kalmasını sağlar.

İnternet Protokolleri

İnternet üzerinden veri aktarımı yaparken kullandığımız IP paketleri, bir taşıma katmanına ihtiyaç duyarlar. İşte UDP ve TCP dediğimiz kavramlar bu katmanlardır.

UDP (User Datagram Protocol): Gerçek zamanlı akışlar (ses, video gibi) için tasarlanmış bir bağlantı türüdür. “Kimsin, nesin?” gibi soruları pek sormaz. “Gönder ve unut” mantığıyla çalışır. Paketi gönderdikten sonra karşı taraf bunu almış mı, almamış mı diye sorgulamaz. Bunları eski dönem kargo firmaları gibi düşünebiliriz; paketi kapıya atar, kaçar ve arkasını asla sorgulamaz.

TCP (Transmission Control Protocol): Veri bütünlüğünün her şeyden önemli olduğu durumlar (bankacılık, dosya indirme vb.) için tasarlanmış bir bağlantı türüdür. “Üçlü el sıkışma” adında resmi bir protokolü vardır ve süreç şöyle işler:

  1. SYN: “Bağlanabilir miyiz?”
  2. SYN-ACK: “Evet, hazırım gel.”
  3. ACK: “Tamam, geliyorum.”

TCP, gönderdiği her paket için karşı taraftan bir “alındı” (ACK) onayı bekler. Eğer bu onay gelmezse, o paketi kaybolmuş sayar ve tekrar gönderir. Paketleri sıkı bir şekilde kontrol eder. Yani 2. paket yanlışlıkla 1. paketten önce ulaşırsa, onları tekrar doğru sıraya dizer. Bunları da yeni nesil, titiz kargo firmaları gibi düşünebiliriz; sizi arar, evde misiniz diye sorar ve teslimat için bir kod talep eder.

Şimdi, gelelim zurnanın zırt dediği yere: İnternet Servis Sağlayıcılar (ISS) bu iki protokoldeki paketlere nasıl davranıyor? Eğer her ikisine de aynı şekilde davrandıklarını düşünüyorsanız, maalesef yanılıyorsunuz.

Fiber Optik Altyapıdaki Durum

Fiber, bant genişliğinin nispeten daha rahat ve geniş olduğu bir ortamdır. Ancak burada da devreye CGNAT (Carrier-Grade NAT) ve Stateful Firewall (Durum Denetimli Güvenlik Duvarı) girer.

  • TCP: ISS için TCP trafiği “değerli” trafiktir. Bankacılık işlemleri, webde sörf yapmak (90’lı yıllarda internet kullananların gözleri yaşlı😢), dosya transferleri hep TCP üzerinden yapılır. Bir TCP bağlantısı kurulduğunda, ISS’in router’ı o oturumu hafızasına kaydeder ve ona saygı gösterir.
  • UDP: Fiberde UDP genellikle oyun, video konferans ve VoIP için serbest bırakılır. Ancak, eğer sabit bir IP’niz yoksa, CGNAT havuzundaki router, UDP paketlerini çok hızlı bir şekilde zaman aşımına (timeout) düşürür. Eğer 30-60 saniye boyunca bir veri aktarımı olmazsa, ISS tarafındaki port eşlemesi silinir ve bağlantınız “hayalet moduna” geçer; yani kopar.
4.5G Altyapısındaki Durum

Esas savaşın yaşandığı cephe işte burasıdır. Mobil şebekelerde bant genişliği son derece kıymetlidir ve binlerce cihaz aynı baz istasyonunun kaynaklarını paylaşmak zorundadır. Bu sebeple ISS’ler mobil tarafta çok daha agresif bir politika izler.

  • TCP: TCP yol yordam bilir, naziktir. El sıkışması olduğu için her paket gelişinde güvenlik duvarında nizami bir kayıt açılır. Eğer baz istasyonu yoğunluktan sıkışırsa, TCP bunu algılar ve paket gönderim hızını otomatik olarak düşürür. Operatörler bu “uyumlu” özelliğini severler ve genellikle TCP trafiğine müdahale etmezler.
  • UDP: 4.5G şebekelerinde UDP trafiği genellikle “Olduğu Kadar” sınıfına sokulur, yani üvey evlat muamelesi görür. Baz istasyonu sıkıştığı an, ISS sistemleri ilk iş olarak UDP paketlerini kısıtlamaya (throttle) veya doğrudan çöpe atmaya başlar. Ayrıca UDP paketleri küçük boyutlu ve sürekli akış halinde oldukları için, operatörün güvenlik sistemleri bunu bazen bir DDOS saldırısı ya da verimsiz/tanımsız bir trafik olarak algılayabilir. Ek olarak, mobil cihazların pillerini korumak ve ağ güvenliğini sağlamak adına bu şebekelerde firewall çok agresiftir; açık port bırakmamaya aşırı önem gösterirler. Sabit IP alsanız bile, kendi modem katmanındaki firewallı komple kapatsanız bile, operatör katmanındaki firewall, içeriye doğru gelen (inbound) UDP paketlerini istek dışı trafik olarak görüp filtreleyebilir. Hatta DPI (Deep Packet Inspection – Derin Paket İnceleme) ile bir porttan sürekli bir giriş olduğunu görürse, bunu bir saldırı girişimi olarak algılayıp o portu tamamen bloklayabilir.
Echolink Portları

EchoLink normalde “Peer-to-Peer” (uçtan uca) mantığıyla çalışan bir sistemdir. Bir istasyona bağlandığınızda, ses paketleri doğrudan sizin bilgisayarınız ile karşı tarafın bilgisayarı arasında gidip gelir. Bunun için de EchoLink şu portları kullanır:

  • UDP 5198 ve 5199: Ses paketleri ve anlık veri alışverişi için.
  • TCP 5200: Sunucuya kayıt olma ve kontrol işlemleri için.

İdeal bir dünyada yaşasaydık her şey mükemmel çalışırdı. Ancak yukarıda anlattığım gibi, gerçek dünyada UDP başımıza bela olmaktadır. Bahsedilen ISS kısıtlamaları ve çoğu kurumsal güvenlik duvarı, güvenliği sağlamak adına UDP trafiğini varsayılan olarak bloklar ve sadece standart TCP trafiğine izin verir.

Peki, “E bu EchoLink ne yapmaya çalışıyor? Ses iletiminde bu sorunları bile bile neden TCP değil de inatla UDP kullanıyor?” sorusunu sorduysanız, emin olun yalnız değilsiniz. EchoLink’in (ve neredeyse tüm gerçek zamanlı ses uygulamalarının) inatla UDP kullanmasının tek bir sebebi vardır: Gecikme (Latency).

UDP ile bir TX yaptığınızda (ses gönderdiğinizde), sistem paketi “DAN” diye doğrudan gönderir. El sıkışmaz, alındı mı alınmadı mı diye bakıp vakit kaybetmez. Eğer UDP yerine TCP kullansaydı ne olurdu? İnternet hızındaki en ufak bir anlık dalgalanmada veya paket kaybında, TCP, kaybolan o küçücük ses paketini tekrar göndermek için tüm ses akışını durdurup bekletirdi. Bu da seste 1-2 saniyelik takılmalara ve ardından biriken sesin hızlandırılarak (“Mickey Mouse” gibi) gelmesine neden olurdu. Zamanında Skype veya MSN üzerinden sesli görüşme yapmış olanlar bu hissi çok iyi bilirler, hatta okuyunca kulaklarında canlanmıştır 😊.

E biz şimdi ne yapacağız? Bile bile lades mi diyeceğiz? Tabii ki de demeyeceğiz. İşte çözüm: EchoLink Proxy.

Yukarıdaki “Ağ Protokolleri 101” dersimizden sonra proxy’nin teknik derinliklerine çok inmeyeceğim ancak yazının bütünlüğünü bozmamak adına ne olduğu hakkında ufak bir bilgilendirme yapmış olayım. Proxy’yi aslında bildiğimiz VPN’in biraz daha hafifletilmiş ve özelleştirilmiş hali gibi düşünebilirsiniz. VPN, orijinal veri paketlerini alır ve operatörün (ISS) “güvenli” veya “tanıdık” gördüğü başka bir protokolün (genellikle TCP) içine saklar. Böylece ISS’in UDP bloklaması, DPI filtrelemesi gibi kısıtlamalarının etrafından dolaşır. Dış dünyaya kendi IP’niz ile değil, tünelin diğer ucundaki sunucunun IP’si ile çıkmanızı sağlar. VPN bunu yaparken, tünelden geçen paketleri şifreler (kriptolar). Bu şifrelemeyi, paketi matruşka bebekleri gibi iç içe 10 farklı kasaya koymuş ve öyle göndermiş gibi düşünebiliriz. Bu sistem harika bir gizlilik sağlasa da, şifreleme/şifre çözme işlemi zaman aldığından EchoLink’te bizim en büyük düşmanımız olan gecikmeyi (ping süresini) arttırır. Bu sebeple EchoLink Proxy’de şifreleme yapılmaz, amaç sadece protokolü değiştirmektir.

Peki, EchoLink Proxy ile tam olarak ne yapıyoruz? UDP 5198, 5199 ve TCP 5200 portlarından giden/gelen tüm paketleri tek bir potada eritip, TCP 8100 portu üzerinden gönderip alıyoruz… Nasıl yani?

Normalde ne demiştik? EchoLink üzerinden 5198 ve 5199 UDP portlarından ses alışverişi yapılır. Ancak biz bu proxy sayesinde, 5198 ve 5199 UDP’den gelen o “sorunlu” paketleri alıp, güvenli bir “TCP zarfının” içine koyuyoruz. Peki bu UDP paketini TCP zarfına koyma işlemi (teknik adıyla Encapsulation – Sarmalama) nasıl işliyor?

Normal şartlarda EchoLink ses paketlerinin üzerinde “Ben UDP’yim, şu şu porta gidiyorum” diye yazar. Ancak ISS firewall’u bu paketi görünce “Sen sahipsizsin, güvenilmezsin” diyerek onu sıranın en arkasına atar veya baz istasyonu yoğunsa doğrudan çöpe gönderir.

Proxy kullandığımızda ise süreç şöyle işler: EchoLink yazılımınız yine normal bir ses paketi (UDP) üretir. Sizin tarafınızdaki Proxy yazılımı (veya EchoLink’in kendi içindeki proxy istemcisi) bu UDP paketini yakalar ve üzerine bir TCP başlığı (header) ekler. Artık dışarıdan bakan bir ISS veya Firewall, içinde ses olan bir UDP paketi görmez; sanki bir banka işlemi ya da güvenli bir web sayfası trafiği gibi görünen, “yol yordam bilen”, nizami bir TCP paketi görür. Firewall, “Ha, bu TCP, yani önemli bir veri, bunu kaybetmemem ve engellememem lazım” der ve paketi güvenle hedefe (kiraladığımız sunucuya) ulaştırır. Paket bizim kiralık sunucumuza ulaştığında, sunucudaki Proxy yazılımı dıştaki o sahte TCP zarfını yırtıp atar, içindeki orijinal UDP paketini çıkarır ve onu EchoLink’in ana sunucularına veya bağlandığınız istasyona “taze ve bozulmamış” şekilde teslim eder.

Burada oluşması muhtemel bir kafa karışıklığını da giderelim: “E şimdi diğer EchoLink istasyonları (operatörler) benim setup’ıma mı bağlanacak yoksa kiraladığım sunucuya mı gidecek?”

Sorunun detaylı cevabı şu şekilde: Bir operatör EchoLink listesinde sizin çağrı işaretinizi görür (bizim için şu an YM1KPL-R) ve “Connect” tuşuna basar. EchoLink ana sunucuları (Directory Servers), o operatörü sizin 4.5G modeminize değil, kiraladığınız Proxy Sunucusunun IP adresine yönlendirir. Yani karşıdaki operatör teknik olarak aslında sizin sunucunuza bağlanır. Sunucu burada bir “Resepsiyonist” gibidir. Gelen ses paketlerini kapıda karşılar. Sunucu, karşı taraftan aldığı o paketleri hemen o bahsettiğimiz “TCP zarfının” içine paketler ve sizin modeminizle önceden kurulmuş olan o özel, kesintisiz tünelden içeri gönderir. Sizin EchoLink setup’ınız, sunucudan gelen bu zarfı açar ve içindeki sesi hoparlöre veya telsize aktarır. Süreç bu şekilde kesintisiz devam eder.

Kurulum

Evet, teorik kısmı hallettiğimize göre artık pratik kısma, yani sunucu kiralama aşamasına geçebiliriz. EchoLink Proxy için minimum sistem gereksinimleri oldukça düşüktür:

  • 1 vCPU (En düşük işlemci bile yeterlidir)
  • 1 GB RAM (Aslında 512MB bile yeter ama 1GB rahat ettirir)
  • 10-20 GB Disk (Sadece log tutacak ve küçük bir uygulama barındıracak)

Bu sistem gereksinimlerine uygun, dilediğiniz bir firmadan “VPS” (Sanal Özel Sunucu) kiralayabilirsiniz. Burada dikkat etmeniz gereken en önemli nokta; kiraladığınız sunucunun lokasyonu ile EchoLink kurulumunuzun bulunduğu yerin (ülkenin) aynı olmasıdır. Kurulum Türkiye’de iken sunucuyu Almanya’dan kiralarsanız, sesin gidip gelmesi sırasında ekstra 100-200 ms gecikme yaşarsınız, bu da mandal gecikmesine yol açar.

Sunucuyu kiraladıktan sonra işletim sistemine karar vermemiz gerekiyor. Ben burada yıllardır kullandığım, stabilite sorunu yaşamadığım ve aşina olduğum bir Linux dağıtımı olan Debian ile devam ettim. Siz isterseniz Ubuntu, CentOS gibi farklı Linux dağıtımlarını tercih edebilirsiniz. EchoLink Proxy Java tabanlı çalıştığından, Java destekleyen tüm platformlarda sağlıklı bir şekilde çalışacaktır (Windows, macOS, FreeBSD…)

Sunucuyu kurduktan sonra SSH (Secure Shell) protokolü ile sunucuya uzak bağlantı kurmalıyız. Linux ve macOS kullanıcıları doğrudan terminal ekranını kullanarak, Windows kullanıcıları ise PuTTY gibi bir araçla bu bağlantıyı sağlayabilirler.

SSH ile sunucuya login olduktan sonra yapacağımız ilk işlem, swap alanı oluşturmaktır. Swap, fiziksel RAM’in (ana belleğin) dolduğu anlarda işletim sisteminin imdadına yetişen bir “yedek depo”dur. Düşük RAM’li sunucuların sigortasıdır. 1 GB RAM, her ne kadar EchoLink Proxy için yeterli görünse de, sistemin beklenmedik anlarda (mesela Java’nın bellek kullanımı anlık sıçradığında) kilitlenmemesi için “emniyet supabı” ihtiyacını swap ile karşılarız. 10-20 GB diskimiz olduğu için buradan 2 GB feda etmek akıllıca olacaktır.

# 2GB boyutunda boş bir dosya oluşturuyoruz
sudo fallocate -l 2G /swapfile

#Restrict file permissions so only the system can read it (Security!)
sudo chmod 600 /swapfile

# Dosyayı takas alanı olarak biçimlendiriyoruz
sudo mkswap /swapfile

# Takas alanını hemen şimdi aktif ediyoruz
sudo swapon /swapfile

# Bu ayarın kalıcı olması (sunucu yeniden başladığında da çalışması) için fstab dosyasına ekliyoruz
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Ardından sistemi güncelledikten sonra, EchoLink Proxy Java ile çalıştığından gerekli Java paketini kuracağız. Sonrasında, port açma işlemlerini daha pratik ve sağlıklı bir şekilde yapabilmek adına “UFW” (Uncomplicated Firewall) paketini kuracağız. Linux dünyasında iptables, nftables, firewalld gibi farklı ve güçlü güvenlik duvarı araçları da var; ancak ben sözdizimi (syntax) daha rahat ve anlaşılır olduğu için UFW’yi tercih ettim. Son olarak da “Unzip” paketini kuruyoruz. Bunu kurmamızın sebebi, EchoLink Proxy yazılımını resmi sitesinden indirdiğimizde zip formatında sıkıştırılmış olarak gelmesi ve bu paketi sunucuda açmamız gerekmesidir.

İşlem sırası aşağıdaki gibidir:

# Sistemi güncelliyoruz.
sudo apt update && sudo apt upgrade -y

# Java, Unzip ve UFW paketlerini kuruyoruz.
sudo apt install default-jre unzip ufw -y

# Echolink Proxy için düzenli bir klasör oluşturuyoruz.
mkdir ~/echolink-proxy

# Oluşturduğumuz klasöre giriş yapıyoruz.
cd ~/echolink-proxy

# Resmi adresten Proxy paketini sunucuya indiriyoruz.
wget https://www.echolink.org/downloads/EchoLinkProxy_1_2_3.zip

# İndirdiğimiz dosyaları zipten çıkarıyoruz (İçinden EchoLinkProxy.jar ve ELProxy.conf çıkacak).
unzip EchoLinkProxy_1_2_3.zip

EchoLink Proxy dosyalarımız hazır, ancak henüz çalıştırmadan önce yapmamız gereken kritik port açma ve konfigürasyon dosyası güncelleme adımlarımız var. Öncelikle port açma (firewall) işlemlerini halledelim.

Dikkat! UFW ile port izinlerinde değişiklik yapmadan önce, ilk kural olarak SSH erişimini kesinlikle korumaya almalıyız. Eğer aşağıdaki ilk komutu yazmadan UFW’yi aktif ederseniz, sunucuya olan kendi bağlantınızı kesersiniz ve dışarıda kalırsınız.

# SSH erişimine izin vererek bağlantımızı koruyoruz.
sudo ufw allow ssh

# Proxy tünel bağlantısı için kullanacağımız ana portu (TCP 8100) açıyoruz.
sudo ufw allow 8100/tcp

# Dış dünyadaki diğer operatörlerin ve EchoLink sunucularının ses paketleri için ilgili orijinal portları açıyoruz.
sudo ufw allow 5198:5199/udp
sudo ufw allow 5200/tcp

# Kuralları belirledikten sonra güvenlik duvarını başlatıyoruz.
sudo ufw enable

Şimdi sıra geldi EchoLink Proxy’nin ince ayarlarını yapmaya. Aşağıdaki komutla ayar dosyasını metin editörü ile açıyoruz.

sudo nano ELProxy.conf

Açılan ekrandaki önemli ayarların detayları ve ne işe yaradıkları aşağıdaki gibidir:

  • Password: Burası en kritik kısımdır. Eğer burayı varsayılan olarak PUBLIC bırakırsanız, dünya üzerindeki herhangi bir EchoLink kullanıcısı sizin sunucunuzu bedava bir proxy gibi kullanıp trafiğini sizin üzerinizden geçirebilir. Kişisel kullanım için buraya mutlaka güçlü ve tahmin edilmesi zor bir şifre yazmalısınız. Bu şifreyi bir yere not edin, daha sonra kendi EchoLink programımızda kullanacağız.
  • Port: Varsayılan olarak 8100dür. Linux sistemlerde 1024’ün altındaki portları (Örn: 80, 443 gibi) kullanmak isterseniz uygulamayıt root yetkisiyle çalıştırmanız gerekir. 8100 hem standart hem de sorunsuz olduğu için idealdir, değiştirmenize gerek yoktur.
  • BindAdress: Eğer kiraladığınız sunucunun birden fazla ağ arayüzü veya IP adresi varsa, proxy’nin sadece belirli bir IP’den gelen istekleri dinlemesini sağlar. 0.0.0.0 olarak bırakırsanız sunucudaki tüm IP’lerden gelen istekleri kabul eder, genelde böyle kalması uygundur.
  • ExternalBindAdress: Bu daha karmaşık ağ yapıları içindir. Eğer sunucunun bir ayağı ev ağına (LAN), diğer ayağı internete (WAN) bakıyorsa kullanılır. Bizim gibi tek IP’li standart bir VPS kullananlar için 0.0.0.0 olarak kalmalıdır.
  • PublicAdress: Eğer sunucunuz bir NAT arkasındaysa (ki VPS’lerde genelde değildir) ve EchoLink durum sayfasında gerçek IP’niz yerine yanlış bir lokal IP görünüyorsa, buraya elle sunucunun dış (public) IP’sini yazabilirsiniz. Sadece görüntüleme amaçlıdır, çalışmayı etkilemez.
  • ConnectionTimeout: Proxy’ye bağlanan bir cihazın (telefon veya PC), aktif bir EchoLink görüşmesi yapsın ya da yapmasın, tünelde ne kadar süre boşta kalabileceğini belirler. Burayı 0 yaparsanız, tünel siz bağlantıyı kesene kadar sonsuza dek açık kalır. Kesintisiz bir node için 0 idealdir.
  • RegistrationName: Buraya çağrı işaretinizi yazarsanız, sunucunuz EchoLink’in web sitesindeki halka açık “Proxy Listesi”ne kayıt olur. Eğer sunucu IP adresiniz değişkense ve sunucunuzu kolayca bulmak istiyorsanız kullanabilirsiniz, aksi takdirde boş bırakabilirsiniz.
  • RegistrationComment: Kayıt listesinde çağrı işaretinin yanında görünecek kısa bir nottur. (Örn: “Ercan 4.5G Ozel Proxy”).
  • Güvenlik Ayarları (RegEx): Regular Expression kullanarak kimlerin sunucunuzu kullanabileceğini çok detaylı filtreleyebilirsiniz:
  • CallsignsAllowed: Burası beyaz listedir. Sadece belirli kişilere izin verir. Örneğin TA1TEC|TA1NDA yazarsanız, şifreyi bilseler dahi sadece bu iki çağrı işaretine sahip istasyonlar sizin sunucunuzu kullanabilir.
  • CallsignsDenied: Burası kara listedir. Belirli kişileri yasaklar. Örneğin .-L$|.-R$ yazarsanız, sonu “-L” (Link) ve “-R” (Repeater) ile biten tüm istasyonların sizin proxy’nizi kullanmasını engellersiniz. Yani sadece şahıs istasyonlarına izin vermiş olursunuz.

Tanımlamaları detaylandırdık. Detaya girmek istemeyenler için, sistemin çalışması ve güvenliği için gerekli temel ayarlar şunlardır (diğerlerini varsayılan bırakabilirsiniz):

Password=OluşturacağınızGüçlüŞifre
Port=8100
ConnectionTimeout=0
# Sadece kendi node'unuzun bağlanmasına izin verin, başkaları şifreyi bilse bile giremesin.
CallsignsAllowed=Çağrıİşareti (Örn: YM1KPL-R)

Bu değerleri girdikten sonra klavyeden CTRL+X, ardından Y ve son olarak Enter tuşlarına basarak konfigürasyon dosyamızı kaydedip çıkıyoruz. Bir hata yapmadıysak bu dosyaya bir daha dokunmamız gerekmeyecek.

Aslında şu an teknik olarak her şey tamam. Proxy yazılımını manuel olarak çalıştırabiliriz. Ancak şu anki haliyle, sunucuda yaşanacak bir elektrik kesintisi veya yeniden başlatma (reboot) durumunda EchoLink Proxy kendiliğinden tekrar çalışmayacaktır. Her seferinde elle başlatmak gerekir.

Proxy’nin sunucu her açıldığında otomatik olarak başlaması ve arka planda “ölümsüz” bir servis gibi çalışması için bir systemd servisi oluşturmamız gerekiyor.

Peki, neden basitçe crontab içine @reboot ile başlayan tek satırlık bir komut yazmak varken, daha karmaşık görünen bir systemd servisi oluşturmakla uğraşıyoruz?

Cevabı basit: Kararlılık ve Kontrol. Crontab, programı açılışta yalnızca bir kez tetikler ve işi biter. Eğer uygulama başlarken Java bir hata verip çökerse veya çalışma esnasında bir sebeple kapanırsa, crontab’ın ruhu bile duymaz. Sunucuyu siz fark edip yeniden başlatana kadar EchoLink Proxy kapalı kalır.

Systemd ise bir “bekçi” gibidir. Programı sürekli izler. Eğer program çökerse, systemd bunu fark eder ve belirlediğimiz kurallara göre otomatik olarak yeniden başlatır. Ayrıca crontab, sunucu açılır açılmaz komutu çalıştırır; bu sırada henüz internet bağlantısı gelmemiş veya IP adresi tanımlanmamış olabilir. Böyle bir durumda EchoLink Proxy hata verecek ve çalışmayacaktır. Ancak systemd’ye After=network.target komutunu ekleyerek, “İnternet bağlantısı tamamen hazır olana kadar bu programı çalıştırma, bekle” diyebiliyoruz. Ek olarak, crontab ile arka planda ne döndüğünü anlamak zordur, log tutması için ekstra ayar gerekir. Systemd ise otomatik olarak tüm çıktıları loglar ve yönetimi çok daha profesyoneldir.

Şimdi, EchoLink Proxy’nin her koşulda ayakta kalması için gerekli servis dosyasını oluşturalım:

sudo nano /etc/systemd/system/echolink-proxy.service

Açılan boş editöre aşağıdaki kod bloğunu tamamen yapıştırın:

[Unit]
Description=EchoLink Proxy Server Service
# İnternet bağlantısı hazır olduktan sonra başla
After=network.target

[Service]
# Dosyaların bulunduğu klasör (Kendi yolunuz farklıysa düzenleyin)
WorkingDirectory=/root/echolink-proxy
# Çalıştırılacak komut (Java'nın tam yolu ve JAR dosyasının ismi)
ExecStart=/usr/bin/java -jar EchoLinkProxy.jar
# Herhangi bir hata veya çökme durumunda servisi otomatik olarak yeniden başlat
Restart=always
# Yeniden başlatmadan önce 5 saniye bekle (Sistemi boğmamak için)
RestartSec=5
# Logların standart sistem günlüğüne düşmesi için gerekli ayarlar
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=echolink-proxy

[Install]
# Çok kullanıcılı modda (standart sunucu açılışı) çalışması için
WantedBy=multi-user.target

Kodu yapıştırdıktan sonra yine CTRL+X, Y, Enter diyerek dosyayı kaydedip çıkalım. Şimdi bu yeni servisi sisteme tanıtalım ve başlatalım:

# 1. Systemd'ye yeni bir servis dosyası eklediğimizi haber verelim, konfigürasyonu yeniden okusun.
sudo systemctl daemon-reload

# 2. Servisi başlangıca ekleyelim (Böylece sunucu her açıldığında kendi kendine başlayacak).
sudo systemctl enable echolink-proxy

# 3. Ve servisi hemen şimdi başlatalım.
sudo systemctl start echolink-proxy

# 4. Son olarak, her şey yolunda mı diye durumunu kontrol edelim.
sudo systemctl status echolink-proxy

Eğer son komuttan sonra ekranda yeşil renkte active (running) yazısını görüyorsanız, tebrikler! Artık 4.5G hattınız ne kadar kararsız olursa olsun, arkasında kaya gibi sağlam duran profesyonel bir proxy sunucunuz var.

Sunucudaki işlerimizi başarıyla tamamladık ve servisimiz arka planda çalışmaya başladı. Şimdi sıra, telsizimize veya bilgisayarımıza bağlı olan EchoLink yazılımına bu yeni tüneli tanıtmaya geldi:

  1. EchoLink programını açın ve üst menüden Tools > Setup adımlarını takip edin.
  2. Açılan pencerede Proxy sekmesine gelin.
  3. “Use Specific Proxy” seçeneğini işaretleyin.
  4. Host: Buraya EchoLink Proxy’nin çalıştığı sunucunuzun IP adresini yazın.
  5. Port: Eğer konfigürasyon dosyasında değiştirmediyseniz 8100 olarak bırakın.
  6. Password: ELProxy.conf dosyasında belirlediğiniz o güçlü şifreyi buraya girin.
  7. Tamam diyerek ayarları kaydedin.

Eğer her şeyi doğru yaptıysanız, EchoLink ana sunucu listesine tünel üzerinden bağlanacak ve çağrı işaretinizin yanında proxy kullandığınıza dair küçük bir simge belirecektir. Geçmiş olsun! Artık 4.5G şebekesinin agresif kısıtlamaları, CGNAT engelleri veya paket çöpe atmaları sizin için bir sorun değil. Kendi kurduğunuz bu dijital köprü sayesinde:

  • Ses paketleriniz ISS tarafından “değerli TCP trafiği” olarak görülecek ve önceliklendirilecek.
  • Bağlantı kopmaları minimuma inecek.
  • Özellikle kalabalık çevrimlerde (netlerde) sesin “Mickey Mouse” gibi hızlanması veya tamamen kesilmesi sorunu tarih olacak.

Evet…

Bu uzun yazının sonuna kadar geldiğiniz için teşekkür ederim. İletişimin önüne koyulan kısıtları ve engelleri aşmak zorunda kalmadığımız, sadece teknoloji üretmenin heyecanına odaklandığımız günlerde görüşmek dileğiyle.

Ercan, 2026.