Headscale ile Kendi Tailscale Sunucunuzu Kurma Rehberi

Headscale nedir

Headscale, Tailscale kontrol sunucusunun kendi kendine barındırılan (self-hosted) bir uygulamasıdır; dolayısıyla özel ağınızı koordine eden makine, sahibi olduğunuz bir VPS'tir. Bu bir topluluk projesidir ve Tailscale Inc. tarafından yönetilmez. Her makine, resmi tailscale istemcisini çalıştırmaya devam eder ve --login-server bayrağı ile sunucunuza yönlendirilir.

Kontrol sunucusu, ağa kimin dahil olduğunu bilen kısımdır. Her düğüme 100.64.0.0/10 aralığından bir adres atar, genel anahtarları dağıtır ve düğümlere birbirlerini nerede bulacaklarını söyler. Tüneller, düğümler arasında kurulan WireGuard bağlantıları olarak kalır. İki makineniz arasındaki trafik, doğrudan bir yol oluşturulamadığı ve düğümler bir röleye (relay) başvurmak zorunda kalmadığı sürece headscale sunucusu üzerinden geçmez. Bu koordinasyon rolünü bizzat üstlenmek, sistemin yeteneklerini değil, sadece kontrolün kimde olduğunu değiştirir; bu nedenle geçişi tek başına bir güvenlik kazanımı olarak görmeden önce bu modelde bir kontrol sunucusunun nelere erişip nelere erişemeyeceğini anlamak önemlidir.

Headscale, proje tarafından kişisel kullanım veya küçük organizasyonlar için uygun olduğu belirtilen, örnek başına bir tailnet (bir Tailscale ağı) sunar. Üç veya dört makine söz konusu olduğunda, sahibi olduğunuz bir VPS üzerinde basit bir WireGuard VPN çalıştırmak, daha az yazılım yükü ve daha az arıza riski anlamına gelir. Headscale, her yeni dizüstü bilgisayar için manuel olarak [Peer] bloğu yazmak istemediğinizde avantaj sağlar. İnsanları bu arayışa iten genellikle maliyet faktörüdür; bu yüzden bir sunucu kurmadan önce barındırılan ücretsiz planın neleri kapsadığını okumakta fayda vardır, çünkü birkaç kişisel makine genellikle bu planın sınırları içine sığar. Eğer bu sınırı zaten aştıysanız, cihaz başına değil kullanıcı başına ücretlendirilen ücretli planların maliyeti ile bir karşılaştırma yapın; çünkü tek bir hesap üzerindeki bir hane halkı, cihaz sayısı önemini yitirdikten sonra bile uygun maliyetli kalabilir. Eğer kendi kendine barındırılan bir kontrol düzlemi istiyorsanız ancak Tailscale'in doğrudan yedeği yerine kendi istemcinizi ve eşleri yönetmek için bir web arayüzü tercih ediyorsanız, tek bir VPS üzerinde NetBird değerlendirilmesi gereken bir alternatiftir. İki modelin daha geniş bir karşılaştırması için WireGuard ve Tailscale arasındaki farklara bakabilirsiniz.

Kurulum öncesi gereksinimler

• Genel IPv4 adresi ve sudo yetkisi olan, Ubuntu 24.04 yüklü bir VPS. Sunucu yeniyse, önce yeni bir VPS üzerinde ilk on dakika rehberindeki adımları tamamlayın.
• Bu adrese yönlendirilmiş bir DNS A kaydı. Bu rehberde headscale.example.com kullanılmaktadır.
• MagicDNS için ikinci bir alan adı veya alt alan adı. Bu rehberde tailnet.example.net kullanılmaktadır. Bu, server_url içindeki alan adı ile aynı olmamalıdır.
• Ağa dahil edilecek; Linux, macOS, Windows, Android veya iOS çalıştıran bir istemci makinesi.

Resmi .deb paketinden headscale kurulumu

Proje, .deb paketlerini GitHub sürümler sayfasında yayınlamaktadır. Temmuz 2026 itibarıyla güncel sürüm 0.29.3'tür. Dosya adı mimari bilgisini içerdiğinden, öncelikle mimarinizi kontrol edin.

sudo apt update
sudo apt install -y wget
dpkg --print-architecture

Bu komut, standart bir x86 VPS üzerinde amd64, Ampere veya Graviton tarzı bir planda ise arm64 çıktısını verir. Yanıtı aşağıdaki değişkene atayın.

HEADSCALE_VERSION="0.29.3"
HEADSCALE_ARCH="amd64"
wget --output-document=headscale.deb \\
  "https://github.com/juanfont/headscale/releases/download/v${HEADSCALE_VERSION}/headscale_${HEADSCALE_VERSION}_linux_${HEADSCALE_ARCH}.deb"
sudo apt install -y ./headscale.deb
headscale version

Dosya adının önündeki ./ gereklidir. Bu olmadan apt, depolarınızda headscale.deb adlı bir paket arar ve başarısız olur.

Paket, headscale sistem kullanıcısını oluşturur, varsayılan bir /etc/headscale/config.yaml dosyası yazar ve bir systemd birimi kurar. Servisi başlatmaz; izlenmesi gereken doğru sıra budur. Gelen yapılandırma, server_url adresini http://127.0.0.1:8080 noktasına yönlendirir; bu adres istemcilerinizin erişebileceği bir adres değildir. Bu nedenle servis şu aşamada başlatılsa bile hatalı çalışacaktır. Bu noktada sudo systemctl is-active headscale komutunu çalıştırmak inactive çıktısını verir. Bu beklenen bir durumdur, bir hata değildir.

Servisi başlatmadan önce server_url yapılandırmasını yapın

/etc/headscale/config.yaml dosyasını sudo nano /etc/headscale/config.yaml ile düzenleyin veya aynı üç değişikliği sed ile uygulayın. Dosya uzun ve yoğun açıklamalar içerdiğinden, diğer ayarlar için en iyi referans kaynağıdır; bu nedenle orijinal dosyanın bir kopyasını saklayın.

sudo cp /etc/headscale/config.yaml /etc/headscale/config.yaml.orig
sudo sed -i 's|^server_url:.*|server_url: https://headscale.example.com|' /etc/headscale/config.yaml
sudo sed -i 's|^listen_addr:.*|listen_addr: 127.0.0.1:8080|' /etc/headscale/config.yaml
sudo sed -i 's|^  base_domain:.*|  base_domain: tailnet.example.net|' /etc/headscale/config.yaml
sudo grep -E '^(server_url|listen_addr):|^  base_domain:' /etc/headscale/config.yaml

server_url, headscale'in her istemci kaydına yazdığı adres başlığıdır. İstemciler bundan sonraki tüm süreçte tam olarak bu dizgeye bağlanır; bu nedenle adres, başında https:// bulunan genel bir alan adı olmalı, asla 127.0.0.1 kullanılmamalıdır.

listen_addr, sürecin dinleme yaptığı adrestir. Bunu loopback üzerinde bırakın. Aynı sunucudaki bir reverse proxy, TLS (transport layer security) sonlandırmasını yapar ve trafiği buraya iletir; bu sayede sunucu dışındaki hiçbir yapının 8080 numaralı porta erişmesine gerek kalmaz.

base_domain, düğümlerinizin isim alacağı alan adı olan MagicDNS sonekidir. Bu, sonunda nokta bulunmayan tam nitelikli bir alan adı (FQDN) olmalı ve server_url içindeki alan adından farklı olmalıdır; aksi takdirde iki isim alanı çakışacaktır.

Veritabanı bölümünü değiştirmeyin. Varsayılan ayar, paketin oluşturduğu ve sahipliğini elinde tuttuğu bir dizin olan /var/lib/headscale/db.sqlite konumundaki SQLite'tır ve bu boyuttaki bir tailnet için SQLite yeterlidir.

headscale servisini başlatma ve çalışır durumda olduğunu doğrulama

sudo systemctl enable --now headscale
sudo systemctl is-active headscale
curl -sS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8080/health

is-active komutu active çıktısını, curl komutu ise 200 çıktısını verir. enable --now komutu ise her iki işlemi de gerçekleştirir: servisi başlatır ve yeniden başlatma sonrasında otomatik olarak çalışacak şekilde işaretler.

Eğer is-active komutu failed çıktısını veriyorsa, sudo journalctl -u headscale -n 50 --no-pager komutu ile günlük kayıtlarını inceleyin. Bu aşamadaki bir hata neredeyse her zaman yapılandırma dosyasından kaynaklanır; çünkü headscale bir soket açmadan önce tüm dosyayı ayrıştırır. Bu nedenle hatalı bir girinti veya bilinmeyen bir anahtar, süreç daha dinlemeye başlamadan durmasına neden olur. Dosyayı düzeltin ve ardından sudo systemctl restart headscale komutunu çalıştırın. Daha sonra yapılacak her yapılandırma değişikliği için aynı yeniden başlatma işlemi gereklidir. İstemciler sonrasında kendiliğinden yeniden bağlanır. systemd birimleri sizin için yeniyse, systemd ile kendi servislerinizi ve zamanlayıcılarınızı çalıştırma rehberi burada kullanılan komutları kapsamaktadır.

Kabuk üzerindeyken durum dosyalarını kontrol edin:

stat -c '%U %n' /var/lib/headscale/db.sqlite /var/lib/headscale/noise_private.key

Her iki satır da paketin oluşturduğu yetkisiz kullanıcı olan headscale ile başlar. noise_private.key, sunucunun istemcileri nezdindeki kimliğidir. Bu dosyayı koruyun. Eğer silerseniz, headscale yeni bir tane oluşturur ve her düğümün yeniden kayıt olması gerekir.

headscale önüne TLS ekleme

İstemcilerin server_url adresine HTTPS üzerinden ulaşması gerekir. Caddy, sertifikayı kendi başına talep edip yenilediği için en kısa yoldur.

sudo apt install -y caddy

/etc/caddy/Caddyfile içeriğini headscale dokümantasyonundaki blok ile değiştirin:

headscale.example.com {
    reverse_proxy 127.0.0.1:8080 {
        header_up True-Client-IP {remote_host}
        header_up X-Real-IP {remote_host}
    }
}

sudo caddy validate --adapter caddyfile --config /etc/caddy/Caddyfile
sudo systemctl restart caddy
sudo systemctl is-active caddy

validate, dosya ayrıştırıldığında adapted config to JSON çıktısını verir. Dosyanın biçimlendirilmediğine dair bir uyarı kozmetiktir. Dizüstü bilgisayarınızdan curl -sS -o /dev/null -w '%{http_code}\\n' https://headscale.example.com/health komutu da 200 çıktısını vermelidir. Bu tek kontrol; DNS, güvenlik duvarı, sertifika ve proxy'nin birlikte çalıştığını kanıtlar.

İnsanların bir akşamını harcamasına neden olan proxy detayı şudur: Tailscale kontrol bağlantısı bir HTTP yükseltme (upgrade) işlemidir, GET yerine POST ile başlatılır ve Upgrade başlığının değeri tailscale-control-protocol şeklindedir. Caddy bunu ek bir yapılandırma gerektirmeden iletir. nginx bunu yapmaz, bu nedenle bir nginx ön ucu şu yükseltme haritasına ihtiyaç duyar:

map $http_upgrade $connection_upgrade {
    default keep-alive;
    ''      close;
}

server {
    listen 443 ssl;
    server_name headscale.example.com;
    location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
        proxy_pass http://127.0.0.1:8080;
    }
}

Bu satırları çıkarırsanız normal istekler yine de başarılı olur; bu yüzden /health komutu 200 döner ve her şey yolunda görünür, ancak uzun ömürlü kontrol bağlantısı asla kurulmaz ve düğümleriniz kaydolduktan sonra çevrimdışı kalır. nginx yolunu seçerseniz, Ubuntu 24.04 üzerinde nginx ile Certbot rehberi sertifika kısmını kapsar.

UFW üzerinde açılması gereken portlar

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

443 numaralı port tüm istemci trafiğini taşır. 80 numaralı port yalnızca ACME (otomatik sertifika yönetimi ortamı) HTTP sınaması ve HTTPS yönlendirmesi için gereklidir; Caddy'nin sertifika alabilmesi için bu portun açık olması şarttır.

8080 numaralı port kapalı tutulmalıdır. listen_addr, 127.0.0.1:8080 olduğu için proxy, headscale servisine loopback arayüzü üzerinden erişir ve bu süreçte herhangi bir güvenlik duvarı kuralı devreye girmez. 8080 numaralı portu internete açmak, istemcilere şifrelenmemiş bir kontrol kanalı sunmaktan başka bir işe yaramaz ve hiçbir avantaj sağlamaz. Çoğu sağlayıcının UFW'den bağımsız olarak kontrol panellerinde ikinci bir güvenlik duvarı çalıştırdığını unutmayın; bu nedenle bir port sunucu üzerinde açık görünse bile ağın giriş noktasında kapalı olabilir. VPS üzerinde UFW güvenlik duvarı temelleri dokümanı, kural sözdizimini daha ayrıntılı olarak ele almaktadır.

Bir kullanıcı ve ön kimlik doğrulama anahtarı oluşturma

sudo headscale users create alice
sudo headscale users list

headscale komutu bir istemcidir. /var/run/headscale/headscale.sock konumundaki unix soketi üzerinden çalışan daemon ile iletişim kurar; bu soket 0770 modundadır ve headscale grubuna aittir. Buradan iki sonuç çıkar. Servis durdurulduğunda komut başarısız olur; bu rehberdeki sıralamanın önemli olmasının diğer nedeni budur. Ayrıca, kendi hesabınızı headscale grubuna eklemediğiniz sürece sudo yetkisi gerektirir.

users list, her ismin yanında bir kimlik numarası yazdırır. Bu numaraya ihtiyacınız vardır, çünkü anahtar komutu isim yerine sayısal bir kullanıcı kimliği kabul eder.

sudo headscale preauthkeys create --user 1 --expiration 24h

Anahtar yalnızca bir kez yazdırılır. Şimdi kopyalayın. Ön kimlik doğrulama anahtarı tek kullanımlıktır ve aksi belirtilmedikçe bir saat boyunca geçerlidir; bu nedenle test aşamasındayken --expiration 24h ayarını yapmak faydalıdır. Birden fazla makineyi kaydedecek bir anahtar için --reusable parametresini ekleyin. Bu anahtarı bir parola gibi koruyun, çünkü elinde tutan herkes ağınıza katılabilir.

İlk istemcinizi --login-server ile bağlayın

Ağa dahil etmek istediğiniz makinede:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --login-server https://headscale.example.com --auth-key 'hskey-auth-PASTE-YOUR-KEY-HERE'
tailscale status
tailscale ip -4

tailscale ip -4, headscale tarafından atanan adresi yazdırır; bu, 100.64.0.1 gibi bir değerdir. Sunucuya geri döndüğünüzde, sudo headscale nodes list düğümü kimliği, kullanıcısı ve çevrimiçi durumuyla birlikte gösterir.

--login-server değeri, şema dahil ve sonunda eğik çizgi (slash) olmadan, server_url ile tam olarak eşleşmelidir. Bu değerler dizge olarak karşılaştırılır; bir uyuşmazlık, istemcinin bir adrese kayıt olup ardından başka bir adresle iletişim kurmasının istenmesi anlamına gelir.

Daha önce Tailscale'in barındırılan servisine giriş yapmış bir makine bu oturumu korur. Önce üzerinde sudo tailscale logout komutunu çalıştırın, ardından --login-server ile tailscale up komutunu uygulayın.

Eğer --auth-key parametresini kullanmazsanız, istemci bir URL yazdırır. Bu URL'yi açtığınızda sayfa, sunucu üzerinden onaylamanız gereken kayıt denemesine ait tanımlayıcıyı gösterir:

sudo headscale auth register --user alice --auth-id PASTE-THE-ID-FROM-THE-PAGE

Bu form, kendi dizüstü bilgisayarınız için daha pratiktir. Ön kimlik doğrulama anahtarları (preauth keys), herhangi bir insan müdahalesi gerektirmediğinden betik tabanlı işlemler için daha uygundur. VPS'niz bir düğüm haline geldiğinde, diğer makinelerinizin internet trafiğini de taşıyabilir; bu çıkış düğümü kurulumu işlemidir. Tek fark, barındırılan bir yönetici konsolu yerine, sunucu üzerinde headscale komutuyla duyurulan rotayı onaylamanızdır. Eğer amacınız internete çıkış sağlamak değil de, o VPS'nin arkasında bulunan özel bir ağa erişmekse, aynı onay adımı bu alt ağın tailnet'inizin geri kalanına duyurulması için de geçerlidir. Tüm ağları bir düğüm üzerinden yönlendirmek yerine tek bir uygulamayı yayınlamak farklı bir işlemdir ve serve ve funnel bunu yapmanın iki yoludur; ancak her ikisi de Tailscale'in kendi sertifika ve giriş mekanizmalarına dayandığından, bunları headscale'in sunduğu özelliklerden ziyade barındırılan tailnet özellikleri olarak değerlendirin.

DERP ve doğrudan yol başarısız olduğunda trafiği aktaran mekanizma

DERP (designated encrypted relay for packets), yedek yol işlevi görür. İki düğüm, genellikle her ikisi de katı NAT (network address translation) arkasında olduğu için doğrudan bir WireGuard bağlantısı kuramadığında, paketlerini bir aktarıcı (relay) üzerinden gönderir. Aktarıcı hiçbir anahtara sahip değildir, bu nedenle trafiğinizi okuyamaz. Yalnızca hangi düğümlerin birbiriyle konuştuğunu ve ne kadar veri aktarıldığını görür.

Varsayılan yapılandırmanın ne yaptığı konusunda net olun. Headscale, https://controlplane.tailscale.com/derpmap/default adresine, auto_update_enabled: true ve update_frequency: 3h ile işaret ederek gönderilir; yani kontrol düzleminiz size aitken aktarıcılarınız Tailscale'e aittir. Çoğu kullanıcı için bu makul bir takastır. Eğer sizin için değilse, kendi aktarıcınızı çalıştırın.

Kendi aktarıcınızı çalıştırmak için config.yaml dosyasındaki derp.server altında enabled: true ayarını yapın, headscale'i yeniden başlatın ve sudo ufw allow 3478/udp ile STUN (session traversal utilities for NAT) portunu açın. Yapılandırma dosyası gereksinimi açıkça belirtir: server_url kısmı https kullanmalıdır, çünkü DERP TLS gerektirir. derp.urls listesini boşaltmak, Tailscale'in aktarıcılarını haritadan kaldırır. Eğer bunu çalışan bir gömülü aktarıcı olmadan yaparsanız, doğrudan bağlanamayan hiçbir düğüm çifti birbiriyle iletişim kuramaz.

Bir istemciden tailscale netcheck bilinen her relay bölgesine olan gecikmeyi yazdırır. tailscale status ise her eşin adresi varsa direct, bölge kodu varsa relay olarak işaretlenmesini sağlar. relay durumunda takılı kalan bir eş, headscale sorunu değil, NAT sorunudur. direct durumunda olan ve hâlâ yavaş çalışan bir eş ise farklı bir konudur; buradaki yaygın neden tünelin kendisi değil, MTU'dur.

Bir düğüm neden çevrimdışı görünüyor?

Proxy, yükseltme işlemini düşürüyor. Bu yaygın bir durumdur ve belirtisi diğer her şeyin sağlıklı görünmesidir: /health 200 kodu döndürür, headscale nodes list düğümü gösterir ancak düğüm hiçbir zaman çevrimiçi olmaz. Kontrol bağlantısı, Upgrade: tailscale-control-protocol taşıyan bir POST isteğidir ve bunu iletmeyen bir proxy, düğüm durumunu bildiren tek kanalı kapatır. Nginx yapılandırmanızı yukarıdaki map bloğu ile karşılaştırın veya proxy kaynaklı olup olmadığını anlamak için Caddy'ye geçiş yapın.

Düğümler kaydedildikten sonra server_url değişti. Düğümler, kayıt sırasında kendilerine verilen değeri aramaya devam eder. Eğer bu değeri değiştirdiyseniz, her düğümde sudo tailscale up --login-server https://headscale.example.com --force-reauth komutunu çalıştırın.

İstemci çalışmıyor. Düğüm üzerinde sudo systemctl is-active tailscaled ve sudo journalctl -u tailscaled -n 50 --no-pager komutlarını kontrol edin. Alan adınızı çözümleyemeyen veya erişemeyen bir istemci, yeniden deneme kayıtlarını burada tutar.

Anahtarın süresi doldu. Bu konu bir sonraki bölümde ele alınmıştır.

Test sırasında sunucu tarafını izlemek için VPS üzerinde sudo journalctl -u headscale -f komutunu çalıştırın ve istemci üzerinde tailscaled servisini yeniden başlatın. headscale'e ulaşan bir düğüm, anında günlük satırları üretir. Sessizlik, isteğin ulaşmadığı anlamına gelir; bu nedenle headscale'e bakmadan önce DNS, güvenlik duvarı ve proxy ayarlarını inceleyin.

Anahtar geçerlilik süresi ve haftalar sonra çalışmayı durduran düğüm

İki ayrı geçerlilik süresi mevcuttur ve bunları birbirine karıştırmak zaman kaybına yol açar.

Preauth anahtarları tasarım gereği hızla geçerliliğini yitirir. Varsayılan değer bir saat ve tek kullanımdır. Eğer tailscale up anahtarı reddederse, istemci tarafında herhangi bir düzenleme yapmak yerine sunucu üzerinde yeni bir anahtar oluşturun.

Düğüm anahtarları (node keys) uzun ömürlü olan kısımdır. config.yaml dosyasının node bölümü expiry: 0 değerini belirler; 0 ise varsayılan bir geçerlilik süresi olmadığı anlamına gelir: kayıtlı bir düğüm, siz süresini dolana kadar geçerli kalır. Etiketli (tagged) düğümlerin süresi hiçbir zaman dolmaz. Kayıtların zaman aşımına uğramasını istiyorsanız expiry: 180d ayarını yapılandırın, ancak ne istediğinizi iyi anlayın: bu durumda etiketli olmayan her düğümün belirtilen takvimde sudo tailscale up --login-server https://headscale.example.com --force-reauth işlemine ihtiyacı olacaktır ve kimsenin yeniden kimlik doğrulaması yapmadığı başsız (headless) bir sunucu, kendi kendine ağdan düşecektir.

Birisi dizüstü bilgisayarını kaybettiğinde bu işlemi manuel olarak gerçekleştirin. sudo headscale nodes list size kimlik bilgisini (ID) verir, ardından sudo headscale nodes expire -i 3 o düğümün oturumunu kapatır ve sudo headscale nodes delete -i 3 onu ağdan tamamen kaldırır.

Yedeklemeler ve yükseltmeler

/var/lib/headscale ve /etc/headscale dosyaları birlikte tüm sunucuyu oluşturur. Kopyalamadan önce servisi durdurun; SQLite üzerinde devam eden yazma işlemleri olabilir ve yük altındayken kopyalanan bir veritabanı tutarsız hale gelebilir.

sudo systemctl stop headscale
sudo tar czf /root/headscale-state.tgz -C /var/lib headscale
sudo tar czf /root/headscale-config.tgz -C /etc headscale
sudo systemctl start headscale
sudo chmod 600 /root/headscale-*.tgz

Her iki dosyayı da sunucudan başka bir yere taşıyın. Bu dosyalar özel anahtarları ve tüm kayıtları içerdiğinden, sunucunun kendisiyle aynı özeni hak ederler. bir VPS üzerinden restic yedekleri konusu, bu işlemin zamanlanmış ve şifreli olarak nasıl yapılacağını açıklar.

Yükseltmeler, kurulum işleminin tekrarıdır: yeni .deb ve sudo apt install ./headscale.deb dosyalarını indirin, ardından servisi yeniden başlatın ve is-active ile /health kontrollerini tekrar çalıştırın. 0.29 sürümünden itibaren yükseltme yolu katıdır. Bir ara sürümü atlamak engellenmiştir; aynı şekilde daha eski bir ara sürüme düşürmek de engellenmiştir. Her seferinde bir ara sürüm ilerleyin, her adımdan önce yedek alın ve sürümün sürüm notlarını önceden okuyun; çünkü aynı sürüm ACL ilkesi davranışını değiştirmiş ve çeşitli yapılandırma anahtarlarının yerini değiştirmiştir.

FAQ

.deb paketini kurduktan hemen sonra headscale neden başlamıyor?

Paket, systemd birimini kurar ancak servisi durdurulmuş halde bırakır; varsayılan /etc/headscale/config.yaml ise çalışan bir yapılandırmadan ziyade bir şablondur. Önce server_url, listen_addr ve base_domain dosyalarını düzenleyin, ardından sudo systemctl enable --now headscale komutunu çalıştırın ve sudo systemctl is-active headscale ile durumu doğrulayın. Eğer hala başarısız oluyorsa, sudo journalctl -u headscale -n 50 --no-pager sorunun kaynağını belirtir. headscale bir portu dinlemeye başlamadan önce tüm dosyayı ayrıştırdığı için bu aşamadaki hatalar neredeyse her zaman bir YAML hatasıdır.

Makinelerime hala standart Tailscale istemcisini mi kurmalıyım?

Evet. Headscale yalnızca kontrol sunucusunun yerini alır. Her düğüm, Tailscale'in resmi istemcisini çalıştırır ve siz onu sudo tailscale up --login-server https://headscale.example.com bayrağı ile kendi sunucunuza yönlendirirsiniz. Bu bayrak standart istemcide mevcuttur, bu nedenle herhangi bir yama yapılması veya yeniden derleme gerekmez.

Trafiğim headscale sunucusu üzerinden mi geçiyor?

Genellikle hayır. Headscale ağı koordine eder, anahtarları ve adresleri dağıtır; veri yolu ise düğümleriniz arasında doğrudan WireGuard üzerinden kurulur. Trafik yalnızca iki düğüm birbirine doğrudan ulaşamadığında ve bir DERP aktarıcısına (relay) geri dönmek zorunda kaldığında dolaylı yoldan akar. Varsayılan yapılandırmada bu aktarıcılar Tailscale'in genel sunucularıdır. Belirli bir eşin direct mi yoksa bir relay üzerinde mi olduğunu görmek için bir düğümde tailscale status komutunu çalıştırın.

Düğümüm kayıt olduktan sonra neden çevrimdışı kalıyor?

headscale nodes list listesinde görünen ancak çevrimiçi olmayan bir düğüm, genellikle reverse proxy üzerindeki kontrol bağlantısını kaybetmiştir. Bu bağlantı, Upgrade: tailscale-control-protocol başlığı ile gönderilen bir POST isteği olarak gerçekleşen bir HTTP yükseltmesidir (upgrade). nginx, map $http_upgrade $connection_upgrade bloğunu ve buna karşılık gelen proxy_set_header satırlarını eklemediğiniz sürece bu bağlantıyı düşürür. Caddy bunu ek bir yapılandırma gerektirmeden iletir; bu da proxy'nin hatalı olup olmadığını test etmenin hızlı bir yoludur.

Headscale için bir alan adına ve TLS'ye ihtiyacım var mı?

Uygulamada, evet. İstemciler server_url içine yazdığınız dizgiye bağlanır, sertifikalar ham IP adresleri için değil alan adları için düzenlenir ve yapılandırma dosyası DERP'in TLS gerektirdiğini belirtir. Bir alan adı ve Caddy kullanımı yaklaşık beş dakika sürer ve size otomatik olarak yenilenen bir HTTPS uç noktası sağlar. Kontrol sunucusunu düz HTTP üzerinden çalıştırmak, istemcinin sunucuyla yaptığı her görüşmenin internet üzerinden açık metin olarak iletilmesi anlamına gelir.