Onaylanmış bir Tailscale alt ağ rotası neden hâlâ zaman aşımına uğruyor

Yönetim konsolundaki onay son adım gibi görünür, ama değildir. Önce uygulama zaman aşımına uğrar, ancak ondan sonra yönlendiricinin çevrimiçi ve rotanın onaylı olduğunu görürsünüz. Onay bir dağıtım adımıdır, izin değildir ve iletme garantisi de değildir. Bir paket alt ağ yönlendiricisinin arkasındaki ana bilgisayara ulaşmadan önce dört aşamanın uyuşması gerekir ve her biri sıradaki başarısız olurken başarılı olabilir. Bunları sırayla işleyin ve ayakta kalmayan ilk aşamada durun.

Dört aşama, tek arıza

Yönlendirici öneki duyurur, tailnet bu duyuruyu onaylar, istemci aldığı rotayı kabul eder ve erişim ilkesi belirli bağlantıya izin verir. Bunlar üç farklı bileşenin verdiği dört ayrı karardır. Bu nedenle onaylı bir rota yalnızca ağın artık tailnet yönlendirme tablosunun parçası olduğunu söyler.

Dördüncü aşama en çok atlanan aşamadır, çünkü ilk üçü görünür bir durum üretir. Yönlendiricinin kendi tailnet adresini kapsayan bir izin, arkasındaki özel alt ağı otomatik olarak kapsamaz. Bunlar farklı hedeflerdir ve ilke her hedef için ayrı değerlendirilir.

Linux'ta üçüncü aşamanın insanları şaşırtan bir varsayılanı da vardır: alt ağ rotalarını kabul etmek isteğe bağlıdır. Birkaç GUI istemcisi duyurulan rotaları varsayılan olarak kabul eder, bu nedenle karışık bir filo, diğerleri çalışırken tek bir makinenin başarısız olduğunu gösterebilir.

Platform varsaymak yerine başarısız makinede ayarı doğrulayın. Rota, çalışan makinelerde hiçbir zaman eksik parça olmadı, bu yüzden tailnet tarafının sağlıklı olduğunu onlar kanıtlasın. Tailscale'in alt ağ yönlendiricileri belgeleri onayı, istemcide rota kabulünü ve ilke aşamasını kapsar.

Rotayı istemcinin çalıştığı yerde denetleyin

Yönlendiricide değil, başarısız istemcide başlayın. Rotanın var olduğunu ve istemci ayarının rota kabulüne izin verdiğini doğrulayın.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

İlk komut eş listesini ve alt ağ yönlendiricisine ulaşılıp ulaşılamadığını gösterir, ikincisi rota kabulü bayrağı dahil istemci tercihlerini yazdırır, üçüncüsü alt ağdaki gerçek bir ana bilgisayar için hangi arayüzü kullanacağını çekirdeğe sorar. Son komut Tailscale arayüzü yerine fiziksel arayüzü adlandırıyorsa rota tabloya hiç girmedi. Eksik rota istemci tarafında bir sorundur, onay sorunu değildir. İlkeye bakmadan önce bunu düzeltin.

Linux'ta rotaları kabul etmek için bayrağın ayarlı olduğunu varsaymak yerine onunla yeniden bağlanın: tailscale up --accept-routes. Başka bayraklarla katılan istemci bunları değiştirilene kadar korur, bu yüzden bir tane daha eklemeden önce mevcut ayarı denetleyin. Değişiklikten sonra ilk komutu yeniden çalıştırmak rotayı tabloda göstermelidir.

İletmeyi ve dönüş yolunu kanıtlayın

Onay, yönlendiriciyi paketleri iletmek üzere yapılandırmaz ve yanıtı düzenlemez. İkisi de yönlendiricinin LAN tarafında ana bilgisayar düzeyinde konulardır. Bunları istemcide değil, yönlendiricide test edin.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

İlk komut 1 bildirmelidir, aksi halde çekirdek iletilen paketi atar. İkincisi alt ağ rotası maskesinin kaynağı yeniden yazıp yazmadığını gösterir; bu varsayılan davranıştır ve genellikle istediğiniz şeydir. Üçüncüsü isteğin hedefe ulaşıp ulaşmadığını ve bir şeyin dönüp dönmediğini gösterir; yanıtsız istek dönüş yolu sorunudur, onay sorunu değildir. Herhangi birini değiştirmeden önce üç sonucu birlikte okuyun.

Maskeleme devre dışı bırakıldıysa hedef ağın tailnet adreslerine dönüş rotasına ihtiyacı vardır ve aradaki her atlama bunu bilmelidir. Maskelemeyi yeniden açmak tek bir hizmet için en hızlı düzeltmedir, ancak istemcinin özgün adresini hedeften gizleme pahasına. Bu değiş tokuş, hedef denetim için kaynak adresleri günlüğe kaydettiğinde önemlidir, bu yüzden olay sırasında bayrağı çevirmek yerine bilinçli karar verin. Hangi seçeneği seçtiğinizi belgeleyin, çünkü sonraki kişi iki davranıştan yalnızca birini görecek.

Kaynak için erişim kuralını okuyun

Rota varken ve iletme kanıtlanmışken geriye kalan şüpheli ilkedir. Bağlantıya izin vermesi gereken izni okuyun ve yalnızca kaynağı değil hedefini de denetleyin. İstemcinin kendi kimliği de ilke seçicisiyle eşleşmelidir, bu yüzden onu başarısız olan aynı makineden kaydedin.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Durum çıktısı istemcinin kendi adreslerini ve gördüğü eşleri tanımlar; ilkenin kaynak seçicisi bunlarla eşleşmelidir. tailscale ping tailnet yolunu alt ağ yönlendiricisinin kendisine kadar kanıtlar; eş adlarını ve tailnet adreslerini çözer, duyurulan alt ağ içindeki ana bilgisayarları değil. Üçüncü komut alt ağ rotası üzerinden normal bir ICMP yankısı gönderir, bu nedenle sonucu yönlendiriciyi değil hedefi tanımlar. tailnet düzeyindeki ret genellikle ret olarak döner, oysa çıkıp hiç dönmeyen paket zaman aşımına uğrar.

Başarısız bir ad, başarısız bir adresten farklı bir sorudur; rotayı suçlamadan önce ana bilgisayarı doğrudan çözün. İzni tüm alt ağ yerine kaynağın gerçek gereksinimine göre yazın. Bir uygulamanın çalışması için tüm /24'ü açmak, dar bir isteğin sonradan kimsenin kaldırmaya cesaret edemediği geniş bir izne dönüşme yoludur.

Hedef özel bir alt ağ değil de internet çıkışı idiyse, doğru bileşen alt ağ yönlendiricisi değil çıkış düğümüdür ve ilke ile yönlendirme buna göre farklıdır. Bir izni genişletmeden önce bu kararı denetleyin. Çıkış düğümü varsayılan rotayı değiştirir; alt ağ yönlendiricisi yalnızca önek duyurur.