Güvenlik Duvarı WebSocket'leri Engellediğinde Canlı Transkripsiyon

Gerçek zamanlı transkripsiyonun kurumsal bir ağda başarısız olmasının belirli, çıldırtıcı bir yolu var. Wi-Fi''niz gayet iyi. HTTPS çalışıyor — herhangi bir web sitesini açabiliyorsunuz. Ama canlı transkripsiyon sadece... başlamıyor ve size neden olduğunu hiçbir şey söylemiyor.

Suçlu, sıradan HTTPS trafiğine izin veren ama WebSocket yükseltmesini engelleyen bir tür kurumsal proxy — bir HTTPS bağlantısını, gerçek zamanlı transkripsiyonun ihtiyaç duyduğu kalıcı, çift yönlü kanala dönüştüren el sıkışma. Proxy''ye göre bir WebSocket, ağdan dışarı açılan izlenmeyen bir tünel gibi görünür, bu yüzden onu öldürür. Size göreyse transkripsiyon sessizce bozuktur.

GeekBye v2.0.8 tam da bunun için otomatik bir yedek ekledi — ve onu inşa etmek, tüm özelliğin hiçbir şey yapmamasına yol açacak bir hatayı ortaya çıkardı.

Neden bir yedek, sadece bir yeniden deneme değil

Kararsız ağları zaten ele alıyoruz. Bağlantınız oturumun ortasında düşerse, GeekBye backoff ile yeniden bağlanır ve hiçbir şey kaybolmasın diye sesinizi bir tamponda tutar — bu ayrı bir özellik ve AI not asistanınız neden kötü Wi-Fi''de duruyor yazısında ele alınıyor.

Ama engellenen bir WebSocket kararsız bir bağlantı değildir. WebSocket''leri reddeden bir proxy''ye karşı aynı WebSocket''i yeniden denemek her seferinde aynı şekilde, sonsuza dek başarısız olur. Tek çözüm farklı bir taşıma — proxy''nin zaten izin verdiği düz HTTPS gibi görünen bir taşıma.

Bu yüzden v2.0.8, aynı kimlik doğrulamalı endpoint üzerinden bir saf HTTPS taşımaya geri düşer:

• Aşağı yönde (size geri gelen transkriptler): server-sent events — proxy''nin sıradan bir akışlı indirme olarak gördüğü, uzun ömürlü bir HTTPS yanıtı.
• Yukarı yönde (dışarı giden sesiniz): toplu POST istekleri; her biri bir ses parçasını bir sıra numarasıyla taşır, böylece ağ onları yeniden sıralasa bile sunucu onları sırayla yeniden birleştirebilir.

Kalıcı soket yok, tünele benzeyen bir şey yok — yalnızca HTTPS istekleri ve yanıtları. Bir proxy bir web sitesi kullanmanıza izin veriyorsa, buna da izin verir.

Ölü bir özellik yayınlayacak olan hata

İşte okumaya değer kısım. Yedek, WebSocket bağlantısı denemelerini engellenmiş-taşıma imzasıyla tükettiğinde tetiklenmeli — her deneme yükseltmede başarısız oluyor, kimlik doğrulama ya da kota sorunu yok, en az bir proxy biçimli reddediş var. Bir WebSocket''i engelleyen bir proxy, yükseltmeye genellikle bir HTTP 403 Forbidden ya da 407 ile yanıt verir.

Sorun şu: bağlantı kodumuzda zaten bir 403''ün ölümcül kimlik doğrulama hatası — dur, kullanıcıya göster, yeniden deneme anlamına geldiğine dair bir kural vardı. Ki bu neredeyse her yerde doğrudur. Ama bu, engelleyen bir proxy''den gelen 403''ün — tam da yedeği tetiklemesi gereken sinyalin — bunun yerine yedek mantığı hiç çalışamadan önce ölümcül bir hata olarak fırlatıldığı anlamına geliyordu. Yedeğe yalnızca ham bir bağlantı kesintisi (bir 1006 kapanışı) düşüyordu. Yani özellik nadir durum için çalışır, gerçek birincil hedefi olan kurumsal proxy içinse sessizce başarısız olurdu.

Bunu üretimde değil, sürümü sağlamlaştırırken yakaladık. Düzeltme: WebSocket yükseltme ayağındaki bir 403/407 artık kurtarılabilir olarak ele alınıyor, böylece bağlantı döngüsü yedeğe doğru tükenebiliyor — gerçek bir kimlik doğrulama hatası ise (ki o farklı gelir, yükseltme başarıya ulaştıktan sonra) tam eskisi gibi hızla başarısız olmaya devam ediyor. Bir regresyon testi ayrımı artık sabitliyor: engellenmiş proxy 403''ü yedeğe düşmeli; gerçek bir auth 403''ü düşmemeli.

Sağlamlaştırmanın geri kalanı aynı paranoyak çizgiyi izledi: her yukarı yön POST''una bir zaman aşımı, böylece bir isteği kabul edip asla yanıt vermeyen bir proxy ses akışını tıkayamaz; ve gerçek bir oturum açma sorununun yedek mekanizması tarafından asla sessizce maskelenememesi güvencesi.

Bunu gerçek bir düşman proxy''ye karşı test ettik

Tüm amacı düşman ağlarda hayatta kalmak olan bir özellik yalnızca birim testleriyle doğrulanamaz — birim testlerinin proxy''si yoktur. Onu etkinleştirmeden önce, gerçek uygulamayı, tam da kurumsal proxy''lerin yaptığını yapmak üzere yapılandırılmış yerel bir reverse proxy''den geçirdik: HTTPS''i ilet, WebSocket yükseltmelerini bir 403 ile reddet.

Loglardaki iz, makbuz gibi: dört engellenmiş WebSocket denemesi, tanınan tükenme imzası, HTTPS taşımaya otomatik geçiş ve ardından saf HTTPS üzerinden sağlıklı, 96 saniyelik bir transkripsiyon oturumu — 66 transkript segmenti, sıfır kayıp. Devretme çalışıyor çünkü devrederken onu izledik.

Aktarılabilir üç ders

1. "Kararsız Wi-Fi''de çalışıyor" ile "düşman bir proxy''nin arkasında çalışıyor" farklı güvencelerdir. Biri yeniden bağlanmaya ihtiyaç duyar; diğeri farklı bir taşımaya. İkisini birbirine karıştırmak, koca bir kurumsal kullanıcı kitlesini sessizce bozuk bırakır.
2. Hata sınıflandırmanız kendi özelliğinizi kendisinden gizleyebilir. Zamanın %99''unda doğru olan bir kural (403 = ölümcül auth), bu özelliğin var olma sebebi olan %1 için tam olarak yanlıştı. Bir yedek eklediğinizde, tetikleme koşulunun yedeğe ulaşabilip ulaşamadığını denetleyin.
3. Yalnızca mutlu yolu değil, düşmanı da test edin. "WebSocket engelleyen bir proxy''ye dayanır" iddiasının tek dürüst testi, WebSocket engelleyen bir proxy''dir. Biz bir tane inşa ettik.

GeekBye v2.0.8, HTTPS yedeğini flag ile korunmuş ve doğrulanmış olarak yayınladı. Yanında durduğu güvenilirlik çalışması için AI not asistanınız neden kötü Wi-Fi''de duruyor yazısına, bu serideki komşu sürümler için ise AI not asistanınız neden toplantının ortasında kaydı durduruyor (v2.0.9) ve AI transkripsiyonu teknik terimleri neden yanlış duyuyor (v2.0.11) yazılarına bakın.