On kişi aynı saniyelerde düştü, ikisi hiç düşmedi; cevap düşmeyenlerin operatöründeydi

Semptom

5 Kasım 2026 sabahı, bir kurumun Sophos Firewall'una (XGS serisi, SFOS 22.0) SSL VPN ile bağlanan uzaktan çalışanlar kopmaya başladı. Kopmalar tek tek değil, dalgalar halinde geldi: 10:24'te sekiz kişi aynı dakika içinde yeniden bağlandı, 10:31'de on kişi. Sophos'un VPN logunda aynı satır art arda diziliyordu: Inactivity timeout (--ping-restart). Başarısız giriş yoktu. Herkes ilk denemede kimlik doğrulamasını geçiyor, birkaç dakika sonra yine düşüyordu.

İkinci semptom kopmalar durduktan sonra geldi. 10:50'de iç paneldeki "Şu an bağlı" kutusu 4 diyordu. Çalışmaya devam eden kişi sayısı bundan fazlaydı.

Yanlış yollar

• "Cihaz takıldı." İlk şüphe Sophos'un kendisiydi. Cihaz 78 gündür açıktı, yük ortalaması 0,5'ti, işlemcinin %92'si boştaydı, sslvpn servisi çalışıyordu. Sophos SSL VPN'i iki ayrı OpenVPN süreciyle yürütüyor. İkisi de aynı saniyelerde kullanıcı kaybetmişti. Tek bir sürecin takılması bunu açıklamazdı.
• Korkutucu görünen loglar. Aynı saatlerde cihazın ağ işlemcisi (NPU) dakikada onlarca invalid pd_cntr satırı basıyordu. 10:18:51'de de IPsec bağlantıları yeniden yüklenmişti. İkisi de suçlu gibi duruyordu. NPU satırlarının saatlik sayısı trafikle birlikte inip çıkıyordu ve bir önceki günle aynıydı. IPsec yüklemesi ise 4,5 saatte bir, aynı dakikada tekrarlanan rutin bir işti.
• "Hat koptu." Öyle olsaydı ofisteki herkesin interneti de gitmeliydi. Güvenlik duvarının dakika başına açtığı bağlantı sayısında boşluk yoktu. Ama bu tek başına yetmez: yeni bağlantı denemeleri hat ölüyken de loga düşer. Daha sağlam bir saat lazımdı (EK-4).
• "İstemci tarafı." On farklı evden, farklı operatörlerden aynı saniyelerde düşen kullanıcıları tek tek istemci sorunlarıyla açıklamak mümkün değildi.
• "Ev IP'lerine ping atarım." Düşen ve düşmeyen kullanıcıların dış adreslerine 30'ar ping gönderdim. Hepsinde %100 kayıp. Ev modemlerinin çoğu ICMP'ye cevap vermiyor. Bu ölçüm hiçbir şeyi ayırt etmiyordu.

Doğru test

Önce kopmaların neye benzediğine baktım. Sophos'ta OpenVPN'in kendi logu kabuktan /log/sslvpn.log yolunda duruyor, saatleri UTC.

07:28:11Z [10060] kullanici-07/203.0.113.27 … Inactivity timeout (--ping-restart)
07:28:12Z [10060] kullanici-08/203.0.113.84 … Inactivity timeout (--ping-restart)
07:28:13Z [10024] kullanici-03/198.51.100.40 … Inactivity timeout (--ping-restart)
07:28:13Z [10060] kullanici-05/192.0.2.61 … Inactivity timeout (--ping-restart)
07:28:14Z [10060] kullanici-09/198.51.100.71 … Inactivity timeout (--ping-restart)
07:28:23Z [10024] kullanici-02/203.0.113.9 … Inactivity timeout (--ping-restart)
07:28:24Z [10060] kullanici-04/192.0.2.150 … Inactivity timeout (--ping-restart)

Bunun ne kadar olağandışı olduğunu ölçmek için aynı dakikada üç ya da daha fazla kişinin düştüğü anları saydım.

for g in 2026-11-03 2026-11-04 2026-11-05; do
  echo $g
  grep "^$g" /log/sslvpn.log | grep -F 'ping-restart), restarting' \
    | cut -c12-16 | uniq -c | awk '$1>=3'
done

2026-11-03
2026-11-04
2026-11-05
      3 07:24
      7 07:28
      5 07:34

Asıl ayırt edici soru şuydu: kim düşmedi? Sabah bağlı olan on iki kişiden ikisi bütün dalgaları kopmadan geçirmişti; biri 09:04'ten, diğeri 09:28'den beri bağlıydı. Düşenlerin ve düşmeyenlerin kaynak adreslerini Team Cymru'nun IP→AS servisine toplu olarak sordum. Servise yalnız adresleri gönderdim, kullanıcı adlarını göndermedim.

printf 'begin\nverbose\n%s\nend\n' <adresler> | nc whois.cymru.com 43

Geriye hattın gerçekten kopmadığını göstermek kalıyordu. Bunun için cihazın kendi dış kalp atışını kullandım. Sophos, Sophos Central'a yaklaşık 31 saniyede bir yoklama gönderiyor ve her yanıtı /log/centralmanagement.log dosyasına yazıyor. Hat bir dakika gitse yanıtlar arasında boşluk kalırdı.

grep '^2026-11-05 07:\(0[5-9]\|[1-4][0-9]\)' /log/centralmanagement.log \
  | grep -F 'got response of poll' | cut -c12-19 \
  | awk -F: '{s = $1*3600 + $2*60 + $3
              if (p && s-p > 45) print "BOŞLUK", onceki, "->", $0
              p = s; onceki = $0}
             END {print "son yanıt:", onceki}'

son yanıt: 07:47:03

Kök neden

1 · Yol: ofisin sağlayıcısından üç operatöre

Ofisin internet çıkışı tek bir sağlayıcı üzerinden. Bu sağlayıcıdan Superonline, Türk Telekom ve Türksat abonelerine giden yol 10:12 ile 10:36 arasında birkaç kez bir iki dakikalığına kesildi. TurkNet'e ve genel internete giden yol sağlam kaldı.

En doğrudan iz Türk Telekom'daki bir kullanıcının oturumundaydı. 10:12–10:17 arasında sunucunun TCP soketi bu kullanıcı için 73 kez No route to host (EHOSTUNREACH) aldı. Çekirdek bu hatayı, yolun üzerindeki bir yönlendiriciden "bu adrese yolum yok" diyen bir ICMP iletisi geldiğinde üretir. Sağlayıcının içini göremiyorum. Burada yazdığım, kenardan ölçülebilenin gösterdiği.

2 · Büyüteç: TCP üzerinde OpenVPN ve keepalive

Bir iki dakikalık bir yol kesintisi normalde tünel düşürmemeli. Burada düşürdü, çünkü iki ayar kesintiyi büyüttü. Sophos'un ürettiği OpenVPN yapılandırmasında proto tcp6-server ve keepalive 45 180 var. Sunucu modunda bu satır iki tarafa farklı açılıyor. İstemciye ping 45 ve ping-restart 180 itiliyor, sunucunun kendisi ping-restart 360 kullanıyor.

Bu ikilik loglarda bir kayma yaratıyor. İstemci 180 saniye sessizlikten sonra tüneli bırakıyor ve yeni bir TCP bağlantısıyla yeni oturum açıyor. Sunucu eski oturumu ancak 360 saniye sonra "Inactivity timeout" diye kapatıyor. Logdaki kapanma anı kopma anı değil.

~10:21        yol kesiliyor
10:24:03–41   sekiz istemci yeniden bağlanıyor     (≈ kesinti + 180 sn)
10:28:11–24   sunucu eski yedi oturumu kapatıyor   (≈ kesinti + 360 sn)

Hesap 45 saniyelik ping aralığı kadar oynuyor, ama sıra tutuyor. EK-1'deki dalga 10:28'de bir şey olduğunu değil, 10:21–10:22'de bir şey olduğunu söylüyor.

TCP de kısa kesintiyi uzatıyor. Tünel TCP üzerinde olunca kaybolan her segment, her denemede iki katına çıkan aralıklarla yeniden gönderiliyor. Arkasındaki her şey, keepalive ping'leri de dahil, sırada bekliyor. Bir buçuk dakikalık bir kesintiden sonra sıradaki yeniden gönderim 180 saniye sınırının ötesine düşebiliyor. Aynı operatördeki iki kullanıcıdan birinin düşüp diğerinin kurtulmasını da bu açıklıyor: kimin düşeceği, kesinti anında yeniden gönderim sayacının nerede durduğuna bağlı.

3 · İkinci semptom: panel 12 kişiyi 4 saydı

Kopmalar 10:36'da durdu. 10:51'de cihazın canlı oturum listesinde (OpenVPN durum dosyası) 12 kişi vardı ve 12 oturumun hepsi son 60 saniye içinde paket almıştı. Panel 4 diyordu.

Panelin kaynağına henüz bakmadım, ama davranışı tek bir kurala birebir uyuyor: her kullanıcının günün son VPN olayına bak, son olay "Established" ise kişiyi bağlı say. Kayma burada ikinci kez vurdu. Yeniden bağlanan sekiz kişinin bir önceki oturumu, yenisi açıldıktan sonra sunucuda 10:33–10:41 arasında kapandı. Bu kapanma kayıtları yeni oturumdan sonra geldiği için panel o sekiz kişiyi çıkmış saydı. Panelde kalan dört kişi, son olayı tesadüfen bağlanma olanlardı.

Çözüm

Cihazda hiçbir şeyi değiştirmedim. Değiştirecek bir şey yoktu; dalgalanma 10:36'da kendiliğinden durdu. Yapılacaklar cihazın dışında.

1 · Sağlayıcıya ölçülebilir bir kayıt

"VPN'imiz kopuyor" demek sağlayıcıya bir şey anlatmaz. Kayıt dört satırdan oluşuyor:

• Zaman aralığı: 5 Kasım 2026, 10:12–10:36 (UTC+3), en yoğun anlar ≈10:21 ve ≈10:28.
• Etkilenen hedef AS'ler: 34984, 9121, 47524.
• Etkilenmeyen: AS12735 ve genel internet çıkışı (EK-4).
• 10:12–10:17 arasında AS9121'deki bir adres için ICMP "host unreachable" (EHOSTUNREACH).

2 · Paneli oturuma bağlamak

Hata, olayları kullanıcıya bağlamaktı. Bir kapanma kaydı yalnız kendi oturumunu kapatmalı. Sophos'un SSL VPN olaylarında oturumu ayırt eden alan, kullanıcıya verilen VPN adresi (remote_ip). Aynı kullanıcının üst üste binen iki oturumu farklı VPN adresi alıyor.

# Yanlış: kullanıcının son olayı
son = {}
for o in olaylar:                                # zamana göre sıralı
    son[o["user_name"]] = o["status"]
bagli = [k for k, d in son.items() if d == "Established"]

# Doğru: (kullanıcı, VPN adresi) bir oturumdur
acik = {}
for o in olaylar:
    oturum = (o["user_name"], o["remote_ip"])
    if o["status"] == "Established":
        acik[oturum] = o["zaman"]
    elif o["status"] == "Terminated":
        acik.pop(oturum, None)                   # yalnız kendi oturumunu kapatır
bagli = sorted({kullanici for kullanici, _ in acik})

3 · Açık karar: TCP mi, UDP mi

Bu vakada kısa yol kesintilerini tünel kopmasına çeviren şey TCP moduydu. UDP'de kaybolan paket yeniden gönderilmez, arkasında bekleyen bir şey olmaz. Bir buçuk dakikalık bir kesinti 180 saniyelik sınıra ulaşmaz. Öte yandan UDP bazı otel ve misafir ağlarında engellenebiliyor ve geçiş bütün kullanıcıların istemci profilini değiştiriyor. Bu ayrı bir karar. Vaka bu yüzden AÇIK.

Kalıcı ders

• Önce "kim düşmedi?" diye sor. Etkilenmeyenler bedava bir kontrol grubudur. Operatörü, şehri, istemci sürümünü iki grup arasında karşılaştırmak, cihazın içinde saatlerce aramaktan daha hızlı sonuç verir.
• Kapanma kaydının zamanı, kopmanın zamanı değildir. keepalive değerlerini bil. OpenVPN sunucu modunda sunucu tarafının süresi istemcininkinin iki katıdır.
• Hat kesintisini cihazın kendi kalp atışıyla doğrula. Düzenli aralıkla dışarı çıkıp cevabını loglayan bir süreç (burada Central yoklaması), bağlantı sayısından daha güvenilir bir saattir.
• "Şu an" bilgisini olay logundan türetiyorsan olayları oturuma bağla. Üst üste binen oturumlar tam da arıza günlerinde olur. Panel en çok gerektiği gün yanlış sayar.