> ./SILENT_INGEST_FAILURE
Sertleştirilmiş lab ortamım 35 saat boyunca her ajan isteğini reddetti. Hiçbir şey alarm vermedi ve herkesin bakacağı tek sağlık sinyali bu süre boyunca yeşil kaldı. Ağ hatası bu işin küçük yarısıydı. Asıl bulgu izleme boşluğuydu.
Belirti
Lab sunucusuna giden her istek nginx'ten 403 dönüyordu. Kimse fark etmeden önce 23.000'den fazla reddedilme birikti ve bu durum bir izleyicinin alarm vermesiyle değil, benim konsola giriş yapamamamla ortaya çıktı.
35 saat boyunca neden görünmez kaldı
Önemsediğim kısım bu. Kendini belli eden bir yanlış yapılandırma bir zahmettir. Sağlıklı görünen bir panelin arkasına saklanan ise bir tespit sorunudur — ve bu kadar iyi saklanabilmesi için üç ayrı boşluğun aynı hizaya gelmesi gerekti.
Kaçırılacak bir başarı sinyali yoktu
nginx bu profilde erişim logu üretmiyor. Sağlıklı isteklere dair hiçbir kayıt yoktu, dolayısıyla yokluklarını ne biri ne bir şey fark edebilirdi.
Reddedilme oranını kimse izlemiyordu
Reddedilmeler yazılıyordu. Ne bir eşik, ne bir alarm, ne bir pano onlara bakıyordu. Kanıt en baştan beri oradaydı ve kimse ona bakmıyordu.
Yeşil kalan tek sinyal, en yanıltıcı olanıydı
Kesintiden iki gün önce açılmış bir metrik WebSocket'i boyunca açık kaldı. Hiç yeniden bağlanmadığı için bozuk yola bir daha hiç girmedi. Kalıcı ingest tamamen engellenmişken “ajan ayakta mı” kontrollerinin hepsi sağlıklı dönmeye devam etti.
Kök neden
Lab, mesh VPN adresine göre yetkilendiriyor. Her nginx location'ı açık bir allow listesi ve kapanışta bir deny all taşıyor. Bir peer'ın paketi web konteynerine, host'un mesh adresinden bir bridge ağının içindeki konteynere DNAT edilerek ulaşıyor ve ardından o bridge'e forward ediliyor.
Mesh arayüzünde forward edilmiş trafik olarak geldiği için Tailscale onu 0x40000 ile işaretliyor ve ts-postrouting zinciri bu işaret üzerinden masquerade yapıyor. Kaynak adres bridge ağ geçidiyle değiştiriliyor. nginx de ağdaki her istemci için tek ve aynı adresi görüyor ve hiçbir allow kuralıyla eşleşmiyor.
Önemli olan ayrım şu: ACL hiçbir zaman atlatılmadı. Yetkilendirdiği bilgi, ona ulaşmadan önce silindi. Arıza açık değil kapalı yönde gerçekleşti — ki bu doğru arıza yönü, ve tam da bu yüzden hiçbir şey endişe verici görünmedi.
Tetikleyici, rutin gözetimsiz güncelleme sırasında gerçekleşen bir servis yeniden başlatmasıydı. İlk reddedilme 2 dakika 46 saniye sonra geldi. Masquerade'in sebep olduğunu kaldırarak kanıtlayabiliyorum; yeniden başlatmanın tam olarak neyi değiştirdiğini ise hiç tespit edemedim ve bunu daha derli toplu bir final uydurmaya tercih ederim.
Düzeltme ve doğrulama
Alt ağ rotaları için kaynak NAT'ı kapatmak, sorunlu masquerade kuralını kaldırıyor. Varsayımla değil etkiyle doğruladım: reddedilmeler durdu; keepalive kapalı açılan üç yeni bağlantı — yani mevcut bir oturuma binemeyecek olanlar — 200 döndü, bu da yeni bağlantıların yeniden gerçek peer adresini taşıdığını kanıtladı; 12 dakikalık bir bekleme testinde sıfır reddedilme ve 12 dakikanın 12'sinde ingest kaydedildi.
Bu ayar, sertifikalı temel yapılandırmamdan bilinçli bir sapma; o yüzden öyle kayıt altına alındı. Yeniden başlatmalara dayanıyor ama mesh'i farklı bayraklarla ayağa kaldırmak onu sessizce geri alır.
Sonucunda ne değişti
Çalışma zamanı başlangıç kapısına iki yarımlı bir kontrol eklendi. Biri, hiçbir masquerade kuralının gelen peer adresini değiştiremeyeceğini ve beklenen DNAT yayınının var olduğunu doğruluyor. Diğeri, yakın zamanlı hiçbir reddedilmenin bridge ağ geçidinden kaynaklanmadığını doğruluyor — bu kesintinin bıraktığı tam parmak izi. Bir test profili hem iki yarımı hem çağrı noktasını koruyor, böylece kontrol sessizce çağrılmaz hâle gelemiyor.
Kapıyı tetikleyiciye değil parmak izine karşı yazdım, bilerek. Yeniden başlatmanın neyi değiştirdiğini hâlâ bilmiyorum; o yüzden o belirli yeniden başlatmayı gözleyen bir kontrol, beni bir arıza sınıfının yalnızca tek bir nedenine karşı korurdu.
Çıkardığım kural
> Uzun ömürlü bir bağlantıdaki canlılık, istek yolunun çalıştığının kanıtı değildir.
Kurulmuş bir akış, her mesajda ACL'e karşı yeniden değerlendirilmez. İstek başına çalışan bir yol değerlendirilir. İkisi aynı arıza alanını paylaşmaz, dolayısıyla biri diğerinin sağlık kontrolü yerine geçemez — ve iyi görünmeye devam eden, hep akış olanıdır.
İkinci ve daha rahatsız edici ders: bu sistemin hiçbir yerinde bir başarı sinyalim yoktu. Erişim loglamasını kapatmak tek başına makul bir sertleştirme tercihi, ama alarm yokluğuyla birleşince sağlıklı ile tamamen bozuk olanın aynı gözlemlenebilir çıktıyı ürettiği bir ortam bıraktı. Bu takası bir daha yapmaktansa log hacmine katlanırım.