Đã nhắc tôi đăng bài này .
Tôi trích dẫn nó ở đây:
Hôm nay tại 18: 53
Tôi hài lòng với nhà cung cấp ngày hôm nay. Cùng với việc cập nhật hệ thống chặn trang, mail.ru của anh ấy đã bị cấm, tôi đã gọi hỗ trợ kỹ thuật từ sáng nhưng họ không làm gì được. Nhà cung cấp này nhỏ và dường như các nhà cung cấp cấp cao hơn đã chặn nó. Tôi cũng nhận thấy việc mở tất cả các trang web bị chậm lại, có thể họ đã cài đặt một loại DLP quanh co nào đó? Trước đây không có vấn đề gì với việc truy cập. Sự hủy diệt của RuNet đang diễn ra ngay trước mắt tôi...
Thực tế là có vẻ như chúng tôi là cùng một nhà cung cấp :)
Và thực sự, Tôi gần như đoán được nguyên nhân của vấn đề với mail.ru (mặc dù chúng tôi đã từ chối tin vào điều đó trong một thời gian dài).
Nội dung sau đây sẽ được chia thành hai phần:
- lý do cho các vấn đề hiện tại của chúng tôi với mail.ru và nhiệm vụ thú vị để tìm ra chúng
- sự tồn tại của ISP trong thực tế ngày nay, sự ổn định của RuNet có chủ quyền.
Sự cố về khả năng truy cập với mail.ru
Ồ, đó là một câu chuyện khá dài.
Thực tế là để thực hiện các yêu cầu của nhà nước (chi tiết hơn trong phần thứ hai), chúng tôi đã mua, cấu hình và lắp đặt một số thiết bị - vừa để lọc các tài nguyên bị cấm vừa để thực hiện người đăng ký.
Cách đây một thời gian, cuối cùng chúng tôi đã xây dựng lại lõi mạng theo cách mà tất cả lưu lượng thuê bao đều đi qua thiết bị này theo đúng hướng.
Một vài ngày trước, chúng tôi đã bật tính năng lọc bị cấm trên đó (trong khi vẫn để hệ thống cũ hoạt động) - mọi thứ dường như diễn ra tốt đẹp.
Tiếp theo, họ dần dần bắt đầu kích hoạt NAT trên thiết bị này cho các bộ phận thuê bao khác nhau. Nhìn bề ngoài thì mọi việc dường như cũng diễn ra tốt đẹp.
Nhưng hôm nay, sau khi kích hoạt NAT trên thiết bị cho phần tiếp theo của người đăng ký, ngay từ buổi sáng, chúng tôi đã phải đối mặt với rất nhiều khiếu nại về việc không có sẵn hoặc có sẵn một phần và các tài nguyên khác của Mail Ru Group.
Họ bắt đầu kiểm tra: cái gì đó ở đâu đó đôi khi, thỉnh thoảng gửi để đáp ứng các yêu cầu dành riêng cho mạng mail.ru. Hơn nữa, nó gửi một TCP RST được tạo không chính xác (không có ACK), rõ ràng là giả tạo. Đây là những gì nó trông như thế nào:
Đương nhiên, những suy nghĩ đầu tiên là về thiết bị mới: PPI khủng khiếp, không tin tưởng vào nó, bạn không bao giờ biết nó có thể làm gì - xét cho cùng, TCP RST là một thứ khá phổ biến trong số các công cụ chặn.
Giả thiết Chúng tôi cũng đưa ra ý kiến cho rằng có người “cấp trên” đang lọc nhưng ngay lập tức loại bỏ.
Đầu tiên là chúng ta có uplinks đủ lành mạnh để không phải khổ sở như thế này :)
Thứ hai, chúng tôi được kết nối với một số ở Moscow và lưu lượng truy cập vào mail.ru đi qua họ - và họ không có trách nhiệm cũng như bất kỳ động cơ nào khác để lọc lưu lượng truy cập.
Nửa ngày tiếp theo được dành cho cái thường được gọi là pháp sư - cùng với nhà cung cấp thiết bị mà chúng tôi cảm ơn họ, họ đã không bỏ cuộc :)
- quá trình lọc đã bị vô hiệu hóa hoàn toàn
- NAT đã bị vô hiệu hóa khi sử dụng sơ đồ mới
- PC thử nghiệm được đặt trong một nhóm biệt lập riêng biệt
- Địa chỉ IP đã thay đổi
Vào buổi chiều, một máy ảo đã được phân bổ kết nối với mạng theo sơ đồ của người dùng thông thường và đại diện của nhà cung cấp được cấp quyền truy cập vào nó và thiết bị. Đạo Shaman vẫn tiếp tục :)
Cuối cùng, đại diện của nhà cung cấp tự tin tuyên bố rằng phần cứng hoàn toàn không liên quan gì đến nó: những cái đầu tiên đến từ một nơi nào đó cao hơn.
GhiTại thời điểm này, ai đó có thể nói: nhưng việc đổ rác không phải từ PC thử nghiệm mà từ đường cao tốc phía trên PI sẽ dễ dàng hơn nhiều?
Không, thật không may, việc kết xuất (và thậm chí chỉ phản chiếu) 40+gbps hoàn toàn không phải là chuyện nhỏ.
Sau đó, vào buổi tối, không còn gì để làm ngoài việc quay lại với giả định về sự lọc kỳ lạ ở đâu đó phía trên.
Tôi đã xem qua IX lưu lượng truy cập đến mạng MRG hiện đang đi qua và chỉ cần hủy các phiên bgp tới nó. Và - kìa và kìa! - mọi thứ ngay lập tức trở lại bình thường 🙁
Một mặt, thật đáng tiếc khi phải dành cả ngày để tìm kiếm vấn đề, mặc dù nó đã được giải quyết trong vòng năm phút.
Mặt khác:
- trong trí nhớ của tôi đây là một điều chưa từng có. Như tôi đã viết ở trên - IX thực sự không có ích gì khi lọc lưu lượng chuyển tuyến. Chúng thường có hàng trăm gigabit/terabit mỗi giây. Tôi thực sự không thể tưởng tượng được điều gì đó như thế này cho đến gần đây.
— một tình huống trùng hợp cực kỳ may mắn: một phần cứng phức tạp mới không đặc biệt đáng tin cậy và không rõ điều gì có thể xảy ra — được thiết kế đặc biệt để chặn tài nguyên, bao gồm cả TCP RST
NOC của sàn giao dịch internet này hiện đang tìm kiếm sự cố. Theo họ (và tôi tin họ), họ không có bất kỳ hệ thống lọc nào được triển khai đặc biệt. Nhưng, cảm ơn trời, nhiệm vụ tiếp theo không còn là vấn đề của chúng tôi nữa :)
Đây là một nỗ lực nhỏ để biện minh cho bản thân, mong bạn thông cảm và tha thứ :)
Tái bút: Tôi cố tình không nêu tên nhà sản xuất DPI/NAT hoặc IX (trên thực tế, tôi thậm chí không có bất kỳ phàn nàn đặc biệt nào về họ, điều chính yếu là phải hiểu nó là gì)
Thực tế của ngày hôm nay (cũng như của ngày hôm qua và ngày kia) từ góc nhìn của một nhà cung cấp Internet
Tôi đã dành những tuần qua để xây dựng lại đáng kể lõi của mạng, thực hiện một loạt thao tác “vì lợi nhuận”, có nguy cơ ảnh hưởng đáng kể đến lưu lượng truy cập trực tiếp của người dùng. Xem xét các mục tiêu, kết quả và hậu quả của tất cả những điều này, về mặt đạo đức, tất cả đều khá khó khăn. Đặc biệt - một lần nữa được nghe những bài phát biểu hay về việc bảo vệ sự ổn định của Runet, chủ quyền, v.v. và như thế.
Trong phần này, tôi sẽ cố gắng mô tả “sự phát triển” lõi mạng của một ISP điển hình trong mười năm qua.
Cách đây mười năm.
Trong những thời điểm may mắn đó, cốt lõi của mạng lưới nhà cung cấp có thể đơn giản và đáng tin cậy như tắc đường:
Trong bức tranh rất đơn giản này, không có đường trục, vòng, định tuyến ip/mpls.
Bản chất của nó là lưu lượng truy cập của người dùng cuối cùng đã chuyển sang cấp độ chuyển đổi hạt nhân - từ đó nó đi tới , từ đó, theo quy luật, quay lại chuyển mạch lõi, sau đó “ra” - thông qua một hoặc nhiều cổng biên giới với Internet.
Sơ đồ như vậy rất dễ dàng để dự trữ cả trên L3 (định tuyến động) và trên L2 (MPLS).
Bạn có thể cài đặt N+1 bất cứ thứ gì: truy cập máy chủ, thiết bị chuyển mạch, đường viền - và bằng cách này hay cách khác, dự trữ chúng để tự động chuyển đổi dự phòng.
Sau vài năm Mọi người ở Nga đều thấy rõ rằng không thể sống như thế này được nữa: việc bảo vệ trẻ em khỏi ảnh hưởng nguy hại của Internet là điều cấp thiết.
Cần phải tìm cách lọc lưu lượng truy cập của người dùng.
Có nhiều cách tiếp cận khác nhau ở đây.
Trong một trường hợp không mấy khả quan, có thứ gì đó được đặt “vào khoảng trống”: giữa lưu lượng truy cập của người dùng và Internet. Lưu lượng truy cập đi qua “thứ gì đó” này sẽ được phân tích và chẳng hạn như một gói giả có chuyển hướng sẽ được gửi tới người đăng ký.
Trong trường hợp tốt hơn một chút - nếu lưu lượng truy cập cho phép - bạn có thể thực hiện một thủ thuật nhỏ bằng tai: gửi để chỉ lọc lưu lượng truy cập bắt nguồn từ người dùng chỉ đến những địa chỉ cần lọc (để thực hiện việc này, bạn có thể lấy địa chỉ IP được chỉ định ở đó từ sổ đăng ký hoặc giải quyết bổ sung các miền hiện có trong sổ đăng ký).
Có lần, vì những mục đích này, tôi đã viết một bài viết đơn giản - mặc dù tôi thậm chí còn không dám gọi anh ấy như vậy. Nó rất đơn giản và không hiệu quả lắm - tuy nhiên, nó cho phép chúng tôi và hàng chục (nếu không phải hàng trăm) nhà cung cấp khác không chi ngay hàng triệu USD cho hệ thống PP công nghiệp mà có thêm vài năm thời gian.
Nhân tiện, về Sở Di Trú lúc bấy giờ và hiện tạiNhân tiện, nhiều người mua hệ thống DPI có sẵn trên thị trường vào thời điểm đó đã vứt chúng đi. Chà, chúng không được thiết kế cho việc này: hàng trăm nghìn địa chỉ, hàng chục nghìn URL.
Đồng thời, các nhà sản xuất trong nước đã vươn lên rất mạnh mẽ tại thị trường này. Tôi không nói về thành phần phần cứng - mọi thứ đều rõ ràng với mọi người ở đây, nhưng phần mềm - thứ chính mà Sở KHĐT có - có lẽ là ngày nay, nếu không phải là tiên tiến nhất trên thế giới, thì chắc chắn a) đang phát triển nhảy vọt, và b) với giá của một sản phẩm đóng hộp - đơn giản là không thể so sánh được với các đối thủ cạnh tranh nước ngoài.
Muốn tự hào nhưng hơi buồn =))
Bây giờ mọi thứ trông như thế này:
Trong một vài năm nữa mọi người đều đã có kiểm toán viên rồi; Ngày càng có nhiều tài nguyên trong sổ đăng ký. Đối với một số thiết bị cũ hơn (ví dụ: Cisco 7600), sơ đồ "lọc bên" đơn giản là không thể áp dụng được: số lượng tuyến đường trên 76 nền tảng bị giới hạn ở mức khoảng chín trăm nghìn, trong khi chỉ riêng số tuyến IPv4 ngày nay đã lên tới gần 800 nghìn. Và nếu đó cũng là ipv6... Và còn... có bao nhiêu? 900000 địa chỉ cá nhân trong lệnh cấm RKN? =)
Ai đó đã chuyển sang sơ đồ sao chép tất cả lưu lượng truy cập đường trục sang máy chủ lọc, máy chủ này sẽ phân tích toàn bộ luồng và nếu phát hiện thấy điều gì đó không ổn, hãy gửi RST theo cả hai hướng (người gửi và người nhận).
Tuy nhiên, càng có nhiều người tham gia thì phương án này càng ít được áp dụng. Nếu có sự chậm trễ nhỏ nhất trong quá trình xử lý, lưu lượng truy cập được nhân đôi sẽ trôi qua mà không được chú ý và nhà cung cấp sẽ nhận được một báo cáo phạt.
Ngày càng có nhiều nhà cung cấp buộc phải lắp đặt các hệ thống DPI với mức độ tin cậy khác nhau trên các tuyến đường cao tốc.
Một hoặc hai năm trước theo tin đồn, gần như toàn bộ FSB bắt đầu yêu cầu lắp đặt thiết bị thực tế (trước đây hầu hết các nhà cung cấp đều được quản lý có sự chấp thuận của cơ quan chức năng kế hoạch SORM - kế hoạch các biện pháp hoạt động trong trường hợp cần tìm thứ gì đó ở đâu đó)
Ngoài tiền (không hẳn là quá cao nhưng vẫn là hàng triệu), SORM còn yêu cầu nhiều thao tác hơn với mạng.
- SORM cần xem địa chỉ người dùng “xám” trước khi dịch nat
- SORM có số lượng giao diện mạng hạn chế
Do đó, đặc biệt, chúng tôi đã phải xây dựng lại rất nhiều phần của hạt nhân - chỉ để thu thập lưu lượng truy cập của người dùng đến các máy chủ truy cập ở một nơi nào đó ở một nơi. Để phản chiếu nó trong SORM bằng một số liên kết.
Nghĩa là, rất đơn giản, đó là (trái) và trở thành (phải):
Bây giờ Hầu hết các nhà cung cấp cũng yêu cầu triển khai SORM-3 - bao gồm, trong số những thứ khác, ghi nhật ký các chương trình phát sóng tự nhiên.
Vì những mục đích này, chúng tôi cũng phải thêm thiết bị riêng cho NAT vào sơ đồ trên (chính xác là những gì được thảo luận trong phần đầu tiên). Hơn nữa, hãy thêm theo một thứ tự nhất định: vì SORM phải “nhìn” lưu lượng trước khi dịch địa chỉ nên lưu lượng phải tuân thủ nghiêm ngặt như sau: người dùng -> chuyển mạch, kernel -> truy cập máy chủ -> SORM -> NAT -> chuyển mạch, kernel - > Internet. Để làm được điều này, chúng tôi phải “chuyển” luồng giao thông sang hướng khác để kiếm lợi nhuận, điều này cũng khá khó khăn.
Tóm lại: trong mười năm qua, thiết kế cốt lõi của một nhà cung cấp trung bình đã trở nên phức tạp hơn nhiều lần và các điểm hỏng hóc bổ sung (cả ở dạng thiết bị và ở dạng đường dây chuyển mạch đơn) đã tăng lên đáng kể. Trên thực tế, chính yêu cầu “nhìn thấy mọi thứ” hàm ý giảm “mọi thứ” này xuống một điểm.
Tôi nghĩ điều này có thể được ngoại suy khá minh bạch cho các sáng kiến hiện tại nhằm chủ quyền hóa Runet, bảo vệ nó, ổn định và cải thiện nó :)
Và Yarovaya vẫn ở phía trước.
Nguồn: www.habr.com