Beni bu yazıya yönlendirdi .
Burada alıntı yapıyorum:
18 Bugün: 53
Bugün sağlayıcıdan memnun kaldım. Site engelleme sisteminin güncellenmesiyle birlikte mail.ru maili de yasaklandı, sabahtan beri teknik desteği arıyorum ama hiçbir şey yapamıyorlar. Sağlayıcı küçük ve görünüşe göre daha üst düzey sağlayıcılar onu engelliyor. Ayrıca tüm sitelerin açılışında bir yavaşlama fark ettim, belki bir tür çarpık DLP yüklemişler? Daha önce erişimde herhangi bir sorun yoktu. RuNet'in yok oluşu gözlerimin önünde gerçekleşiyor...
Gerçek şu ki, biz aynı sağlayıcıyız gibi görünüyor :)
И действительно, Mail.ru ile ilgili sorunların nedenini neredeyse tahmin ediyordum (uzun süre böyle bir şeye inanmayı reddetmiş olsak da).
Bundan sonra olanlar iki bölüme ayrılacaktır:
- mail.ru ile ilgili mevcut sorunlarımızın nedenleri ve bunları bulmanın heyecan verici arayışı
- günümüz gerçeklerinde ISP'nin varlığı, egemen RuNet'in istikrarı.
mail.ru ile ilgili erişilebilirlik sorunları
Ah, oldukça uzun bir hikaye.
Gerçek şu ki, devletin gereksinimlerini yerine getirmek için (ikinci bölümde daha fazla ayrıntı), hem yasaklı kaynakları filtrelemek hem de uygulamak için bazı ekipmanlar satın aldık, yapılandırdık ve kurduk. aboneler.
Bir süre önce, nihayet ağ çekirdeğini, tüm abone trafiğinin bu ekipmandan kesinlikle doğru yönde geçeceği şekilde yeniden inşa ettik.
Birkaç gün önce yasaklı filtrelemeyi açtık (eski sistemi çalışır durumda bırakırken) - her şey yolunda gidiyor gibi görünüyordu.
Daha sonra, abonelerin farklı bölümleri için bu ekipmanda NAT'ı yavaş yavaş etkinleştirmeye başladılar. Görünüşe bakılırsa her şey yolunda gidiyor gibi görünüyordu.
Ancak bugün, abonelerin bir sonraki kısmı için ekipmanda NAT'ı etkinleştirdikten sonra, sabahtan itibaren kullanılamama veya kısmi kullanılabilirlik konusunda çok sayıda şikayetle karşılaştık. ve diğer Mail Ru Grubu kaynakları.
Kontrol etmeye başladılar: bir yerlerde bir şey bazen, zaman zaman gönderir yalnızca mail.ru ağlarına yapılan taleplere yanıt olarak. Dahası, yanlış oluşturulmuş (ACK'siz), açıkça yapay bir TCP RST gönderir. Şöyle görünüyordu:
Doğal olarak, ilk düşünceler yeni ekipmanla ilgiliydi: korkunç DPI, ona güven yok, ne yapabileceğini asla bilemezsiniz - sonuçta TCP RST, engelleme araçları arasında oldukça yaygın bir şeydir.
Varsayım Biz de “üstün” birinin filtrelediği fikrini öne sürdük ama hemen vazgeçtik.
Öncelikle, bu şekilde acı çekmememiz için yeterince aklı başında bağlantılarımız var :)
İkincisi, birçok şeye bağlıyız Moskova'da ve mail.ru'ya giden trafik onlardan geçiyor - ve trafiği filtrelemek için ne sorumlulukları ne de başka bir nedenleri var.
Günün sonraki yarısı genellikle şamanizm denilen şeyle geçti - kendilerine teşekkür ettiğimiz ekipman satıcısıyla birlikte pes etmediler :)
- filtreleme tamamen devre dışı bırakıldı
- NAT yeni şema kullanılarak devre dışı bırakıldı
- test bilgisayarı ayrı bir izole havuza yerleştirildi
- IP adresi değiştirildi
Öğleden sonra, normal bir kullanıcının şemasına göre ağa bağlanan bir sanal makine tahsis edildi ve satıcı temsilcilerine ona ve ekipmana erişim izni verildi. Şamanizm devam etti :)
Sonunda satıcının temsilcisi kendinden emin bir şekilde donanımın bununla hiçbir ilgisinin olmadığını söyledi: ilkler daha yüksek bir yerden geliyor.
DikkatBu noktada birisi şunu söyleyebilir: ama test bilgisayarından değil, DPI üzerindeki otoyoldan çöplük almak çok daha kolaydı?
Hayır, ne yazık ki, 40+gbps'lik bir döküm almak (ve hatta sadece yansıtmak) hiç de önemsiz değil.
Bundan sonra, akşam, yukarıda bir yerde garip bir filtreleme olduğu varsayımına dönmekten başka yapacak bir şey kalmamıştı.
MRG ağlarına giden trafiğin şu anda hangi IX'tan geçtiğine baktım ve ona yönelik bgp oturumlarını iptal ettim. Ve - bakalım! - her şey hemen normale döndü 🙁
Bir yandan, beş dakikada çözülmesine rağmen bütün günün sorunu aramakla geçmesi utanç verici.
Diğer taraftan:
- hafızamda bu benzeri görülmemiş bir şey. Yukarıda da yazdığım gibi - IX gerçekten toplu taşıma trafiğini filtrelemenin bir anlamı yok. Genellikle saniyede yüzlerce gigabit/terabite sahiptirler. Yakın zamana kadar böyle bir şeyi ciddi olarak hayal edemiyordum.
— koşulların inanılmaz derecede talihli bir tesadüfü: özellikle güvenilmeyen ve kendisinden ne beklenebileceği belli olmayan yeni, karmaşık bir donanım — özellikle TCP RST'ler de dahil olmak üzere kaynakları engellemek için uyarlanmış
Bu internet santralinin NOC'si şu anda bir sorun arıyor. Onlara göre (ve ben onlara inanıyorum), özel olarak konuşlandırılmış bir filtreleme sistemleri yok. Ama çok şükür, daha ileri arayışlar artık bizim sorunumuz değil :)
Bu kendimi haklı çıkarmak için küçük bir girişimdi, lütfen anlayın ve affedin :)
Not: DPI/NAT veya IX üreticisinin adını bilinçli olarak vermiyorum (aslında onlar hakkında özel bir şikayetim bile yok, asıl önemli olan ne olduğunu anlamaktır)
Bir İnternet sağlayıcısının bakış açısından bugünün (aynı zamanda dünün ve dünden önceki günün) gerçekliği
Geçtiğimiz haftaları, canlı kullanıcı trafiğini önemli ölçüde etkileme riskiyle birlikte, "kâr amaçlı" bir dizi manipülasyon gerçekleştirerek ağın çekirdeğini önemli ölçüde yeniden inşa ederek geçirdim. Tüm bunların amaçları, sonuçları ve sonuçları düşünüldüğünde ahlaki açıdan oldukça zor. Özellikle - Runet'in istikrarını, egemenliğini vb. korumayla ilgili güzel konuşmaları bir kez daha dinliyorum. ve benzeri.
Bu bölümde tipik bir İSS'nin ağ çekirdeğinin son on yıldaki "evrimini" anlatmaya çalışacağım.
On yıl önce.
O mübarek zamanlarda, bir sağlayıcı ağının çekirdeği trafik sıkışıklığı kadar basit ve güvenilir olabiliyordu:
Bu çok çok basitleştirilmiş resimde hiçbir trunk, ring, ip/mpls yönlendirmesi yok.
Bunun özü, kullanıcı trafiğinin sonuçta çekirdek düzeyi geçişine gelmesi ve oradan da gitmesidir. , buradan, kural olarak, çekirdek anahtarlamaya geri dönün ve ardından bir veya daha fazla sınır ağ geçidi aracılığıyla İnternet'e "dışarı".
Böyle bir şemanın hem L3'te (dinamik yönlendirme) hem de L2'de (MPLS) rezerve edilmesi çok çok kolaydır.
Her şeyden N+1 yükleyebilirsiniz: sunuculara, anahtarlara, sınırlara erişin ve bunları şu veya bu şekilde otomatik yük devretme için ayırın.
Birkaç yıl sonra Artık böyle yaşamanın imkansız olduğu Rusya'daki herkes için açıktı: Çocukları internetin zararlı etkisinden acilen korumak gerekiyordu.
Kullanıcı trafiğini filtrelemenin yollarını bulmaya acil bir ihtiyaç vardı.
Burada farklı yaklaşımlar var.
Pek iyi olmayan bir durumda, kullanıcı trafiği ile İnternet arasındaki "boşluğa" bir şey konur. Bu "bir şeyin" içinden geçen trafik analiz edilir ve örneğin aboneye yönlendirmeli sahte bir paket gönderilir.
Biraz daha iyi bir durumda - eğer trafik hacimleri izin veriyorsa - kulaklarınızla küçük bir numara yapabilirsiniz: yalnızca kullanıcılardan gelen ve yalnızca filtrelenmesi gereken adreslere gelen trafiği filtrelemek için gönderin (bunu yapmak için IP adreslerini alabilirsiniz) kayıt defterinden orada belirtilenleri veya ek olarak kayıt defterindeki mevcut etki alanlarını çözümleyin).
Bir zamanlar bu amaçlarla basit bir yazı yazmıştım. - gerçi ona böyle seslenmeye bile cesaret edemiyorum. Çok basit ve çok üretken değil - ancak bize ve düzinelerce (yüzlerce olmasa da) diğer sağlayıcılara endüstriyel DPI sistemlerine hemen milyonlar harcamamamıza izin verdi, ancak birkaç yıl daha zaman verdi.
Bu arada, o zamanki ve mevcut DPI hakkındaBu arada o dönemde piyasada bulunan DPI sistemlerini satın alan pek çok kişi bunları çoktan çöpe atmıştı. Aslında bunun için tasarlanmamışlardır: yüzbinlerce adres, onbinlerce URL.
Aynı zamanda yerli üreticiler de bu pazara çok güçlü bir şekilde yükseldi. Donanım bileşeninden bahsetmiyorum - burada herkes için her şey açık, ancak yazılım - DPI'nın sahip olduğu en önemli şey - belki bugün, dünyadaki en gelişmiş olmasa da, o zaman kesinlikle a) büyük bir hızla gelişiyor, ve b) kutulu bir ürünün fiyatına - yabancı rakiplerle kıyaslanamaz.
Gururlanmak isterdim ama biraz üzgünüm =)
Artık her şey şöyle görünüyordu:
Birkaç yıl daha herkesin zaten denetçileri vardı; Kayıt defterinde giderek daha fazla kaynak vardı. Bazı eski ekipmanlar için (örneğin, Cisco 7600), "yan filtreleme" şeması uygulanamaz hale geldi: 76 platformdaki rota sayısı dokuz yüz bin gibi bir şeyle sınırlıyken, bugün yalnızca IPv4 rotalarının sayısı 800'e yaklaşıyor. bin. Ve eğer aynı zamanda ipv6 ise... Ve ayrıca... ne kadar var? RKN yasağında 900000 bireysel adres mi var? =)
Birisi, tüm omurga trafiğinin, tüm akışı analiz etmesi ve kötü bir şey bulunursa her iki yöne (gönderen ve alıcı) RST göndermesi gereken bir filtreleme sunucusuna yansıtıldığı bir şemaya geçti.
Ancak trafik ne kadar fazla olursa bu planın uygulanabilirliği de o kadar az olur. İşleme sırasında en ufak bir gecikme olursa, yansıtılan trafik fark edilmeden uçup gidecek ve sağlayıcı bir ceza raporu alacaktır.
Giderek daha fazla sağlayıcı, otoyollarda farklı derecelerde güvenilirliğe sahip DPI sistemleri kurmak zorunda kalıyor.
Bir veya iki yıl önce söylentilere göre neredeyse tüm FSB, ekipmanın fiili kurulumunu talep etmeye başladı (daha önce çoğu sağlayıcı yetkililerin onayıyla yönetiliyordu SORM planı - bir yerde bir şey bulma ihtiyacı durumunda operasyonel önlemlerin planı)
Paraya ek olarak (tam olarak fahiş olmasa da yine de milyonlarca), SORM ağda daha birçok manipülasyona ihtiyaç duyuyordu.
- SORM'un nat çevirisinden önce "gri" kullanıcı adreslerini görmesi gerekiyor
- SORM sınırlı sayıda ağ arayüzüne sahiptir
Bu nedenle, özellikle, kullanıcı trafiğini erişim sunucularına tek bir yerde toplamak için çekirdeğin bir parçasını büyük ölçüde yeniden inşa etmek zorunda kaldık. Birkaç bağlantıyla SORM'a yansıtmak için.
Yani, çok basitleştirilmiş şekilde, (sol) oldu ve (sağ) oldu:
Şimdi Sağlayıcıların çoğu, diğer şeylerin yanı sıra doğal yayınların günlüğe kaydedilmesini de içeren SORM-3'ün uygulanmasını da gerektirir.
Bu amaçlar doğrultusunda, yukarıdaki diyagrama NAT için ayrı bir ekipman da eklemek zorunda kaldık (tam olarak ilk bölümde tartışılan şey). Ayrıca, belirli bir sırayla ekleyin: SORM'un adresleri çevirmeden önce trafiği "görmesi" gerektiğinden, trafik kesinlikle şu şekilde ilerlemelidir: kullanıcılar -> anahtarlama, çekirdek -> erişim sunucuları -> SORM -> NAT -> anahtarlama, çekirdek - > İnternet. Bunu yapmak için, kar amacıyla trafik akışını kelimenin tam anlamıyla diğer yöne "çevirmek" zorundaydık ki bu da oldukça zordu.
Özetle: Son on yılda, ortalama bir sağlayıcının temel tasarımı birçok kez daha karmaşık hale geldi ve ek arıza noktaları (hem ekipman hem de tek anahtarlama hatları şeklinde) önemli ölçüde arttı. Aslında “her şeyi görme” zorunluluğu, bu “her şeyi” bir noktaya indirgemek anlamına geliyor.
Bunun, Runet'i egemenlik altına almaya, korumaya, istikrara kavuşturmaya ve geliştirmeye yönelik mevcut girişimlere oldukça şeffaf bir şekilde yansıtılabileceğini düşünüyorum :)
Ve Yarovaya hala önde.
Kaynak: habr.com