คำตอบโดยละเอียดต่อความคิดเห็น รวมถึงข้อมูลเล็กน้อยเกี่ยวกับชีวิตของผู้ให้บริการในสหพันธรัฐรัสเซีย

เลยชวนผมมาโพสต์นี้ นี่คือความคิดเห็น.

ฉันพูดมันที่นี่:

คาเลมาน วันนี้เวลา 18:53 น

วันนี้ฉันพอใจกับผู้ให้บริการ นอกจากการอัปเดตระบบบล็อกไซต์แล้ว Mailer mail.ru ของเขายังถูกแบนอีกด้วย ฉันโทรหาฝ่ายสนับสนุนด้านเทคนิคตั้งแต่เช้า แต่พวกเขาไม่สามารถทำอะไรได้เลย ผู้ให้บริการมีขนาดเล็กและเห็นได้ชัดว่าผู้ให้บริการที่มีอันดับสูงกว่าบล็อกไว้ ฉันยังสังเกตเห็นการชะลอตัวในการเปิดไซต์ทั้งหมด บางทีพวกเขาอาจติดตั้ง DLP ที่คดเคี้ยวบางประเภท ก่อนหน้านี้ไม่มีปัญหาในการเข้าถึง การทำลายล้างของ RuNet กำลังเกิดขึ้นต่อหน้าต่อตาฉัน...

ความจริงก็คือดูเหมือนว่าเราเป็นผู้ให้บริการรายเดียวกัน :)

และแท้จริงแล้ว คาเลมาน ฉันเกือบจะเดาสาเหตุของปัญหากับ mail.ru ได้ (แม้ว่าเราจะปฏิเสธที่จะเชื่อเรื่องแบบนี้มานานแล้วก็ตาม)

ต่อไปนี้จะแบ่งออกเป็นสองส่วน:

1. สาเหตุของปัญหาปัจจุบันของเรากับ mail.ru และภารกิจที่น่าตื่นเต้นในการค้นหาพวกเขา
2. การมีอยู่ของ ISP ในความเป็นจริงในปัจจุบัน ความมั่นคงของ Sovereign RuNet

ปัญหาการเข้าถึงกับ mail.ru

โอ้ มันเป็นเรื่องที่ค่อนข้างยาว

ความจริงก็คือเพื่อดำเนินการตามข้อกำหนดของรัฐ (รายละเอียดเพิ่มเติมในส่วนที่สอง) เราได้ซื้อกำหนดค่าและติดตั้งอุปกรณ์บางอย่าง - ทั้งสำหรับการกรองทรัพยากรที่ต้องห้ามและสำหรับการนำไปใช้ การแปลของ NAT สมาชิก

เมื่อไม่นานมานี้ ในที่สุดเราก็สร้างแกนเครือข่ายขึ้นมาใหม่ในลักษณะที่การรับส่งข้อมูลของสมาชิกทั้งหมดผ่านอุปกรณ์นี้ไปในทิศทางที่ถูกต้องอย่างเคร่งครัด

เมื่อไม่กี่วันก่อนเราได้เปิดการกรองแบบต้องห้าม (ในขณะที่ปล่อยให้ระบบเก่าทำงาน) - ดูเหมือนทุกอย่างจะเป็นไปด้วยดี

จากนั้น พวกเขาค่อยๆ เริ่มเปิดใช้งาน NAT บนอุปกรณ์นี้สำหรับสมาชิกส่วนต่างๆ ดูจากลักษณะแล้ว ทุกอย่างก็ดูเป็นไปด้วยดีเช่นกัน

แต่วันนี้เมื่อเปิดใช้งาน NAT บนอุปกรณ์สำหรับสมาชิกส่วนถัดไปตั้งแต่เช้าเราต้องเผชิญกับข้อร้องเรียนจำนวนมากเกี่ยวกับความไม่พร้อมใช้งานหรือความพร้อมใช้งานบางส่วน mail.ru และทรัพยากรอื่นๆ ของกลุ่ม Mail Ru

พวกเขาเริ่มตรวจสอบ: มีบางอย่างอยู่ที่ไหนสักแห่ง บางครั้ง, เป็นครั้งคราว ส่ง TCP RST เพื่อตอบสนองต่อคำขอเฉพาะเครือข่าย mail.ru ยิ่งไปกว่านั้น จะส่ง TCP RST ที่สร้างขึ้นอย่างไม่ถูกต้อง (โดยไม่มี ACK) ซึ่งเห็นได้ชัดว่าเป็น TCP RST ปลอม นี่คือสิ่งที่ดูเหมือน:

โดยปกติแล้ว ความคิดแรกๆ เกี่ยวกับอุปกรณ์ใหม่: DPI แย่มาก ไม่ไว้วางใจในมัน คุณไม่มีทางรู้ว่ามันทำอะไรได้บ้าง ท้ายที่สุดแล้ว TCP RST เป็นสิ่งที่พบได้บ่อยในเครื่องมือบล็อก

การสันนิษฐาน คาเลมาน นอกจากนี้เรายังหยิบยกแนวคิดที่ว่ามีคน "เหนือกว่า" กำลังกรองอยู่ แต่ก็ละทิ้งมันไปทันที

ประการแรก เรามีอัปลิงค์ที่สมเหตุสมผลเพียงพอ เพื่อที่เราจะได้ไม่ต้องทนทุกข์ทรมานเช่นนี้ :)

ประการที่สอง เราเชื่อมต่อกับหลาย ๆ IX ในมอสโกวและการรับส่งข้อมูลไปยัง mail.ru ผ่านพวกเขา - และพวกเขาไม่มีความรับผิดชอบหรือแรงจูงใจอื่นใดในการกรองการรับส่งข้อมูล

ครึ่งวันต่อมาใช้เวลาไปกับสิ่งที่มักเรียกว่าชามาน - ร่วมกับผู้ขายอุปกรณ์ ซึ่งเราขอบคุณพวกเขา พวกเขาไม่ยอมแพ้ :)

• การกรองถูกปิดใช้งานโดยสิ้นเชิง
• NAT ถูกปิดใช้งานโดยใช้รูปแบบใหม่
• พีซีทดสอบถูกวางไว้ในสระน้ำแยกที่แยกต่างหาก
• ที่อยู่ IP มีการเปลี่ยนแปลง

ในช่วงบ่าย มีการจัดสรรเครื่องเสมือนที่เชื่อมต่อกับเครือข่ายตามรูปแบบของผู้ใช้ทั่วไป และตัวแทนของผู้จำหน่ายได้รับสิทธิ์ในการเข้าถึงเครื่องและอุปกรณ์ดังกล่าว ลัทธิหมอผียังคงดำเนินต่อไป :)

ในท้ายที่สุด ตัวแทนของผู้จำหน่ายระบุอย่างมั่นใจว่าฮาร์ดแวร์ไม่มีส่วนเกี่ยวข้องใดๆ เลย ฮาร์ดแวร์แรกมาจากที่ที่สูงกว่า

หมายเหตุณ จุดนี้อาจมีบางคนพูดว่า: แต่มันง่ายกว่ามากที่จะทิ้งขยะไม่ใช่จากพีซีทดสอบ แต่จากทางหลวงเหนือ DPI

ไม่ น่าเสียดายที่การถ่ายโอนข้อมูล (และแม้กระทั่งการมิเรอร์) 40+gbps นั้นไม่ใช่เรื่องเล็กน้อยเลย

หลังจากนี้ในตอนเย็นก็ไม่มีอะไรเหลือให้ทำนอกจากกลับไปสู่การสันนิษฐานว่ามีการกรองแปลก ๆ ที่ใดที่หนึ่งข้างต้น

ฉันดูว่า IX การรับส่งข้อมูลไปยังเครือข่าย MRG ใดที่ผ่านไปแล้วและเพียงแค่ยกเลิกเซสชัน bgp ของมัน และ - ดูเถิด! - ทุกอย่างกลับสู่ปกติทันที 🙁

ในแง่หนึ่ง เป็นเรื่องน่าเสียดายที่ใช้เวลาทั้งวันค้นหาปัญหา แม้ว่าจะแก้ไขได้ภายในห้านาทีก็ตาม

ในทางกลับกัน:

— ในความทรงจำของฉัน นี่เป็นเรื่องที่ไม่เคยเกิดขึ้นมาก่อน ตามที่ฉันได้เขียนไว้ข้างต้น - ทรงเครื่อง จริงๆ ไม่มีประโยชน์ในการกรองการจราจร โดยปกติจะมีหลายร้อยกิกะบิต/เทราบิตต่อวินาที ฉันไม่สามารถจินตนาการถึงเรื่องแบบนี้ได้อย่างจริงจังจนกระทั่งเมื่อไม่นานมานี้

— สถานการณ์บังเอิญที่โชคดีอย่างไม่น่าเชื่อ: ฮาร์ดแวร์ที่ซับซ้อนตัวใหม่ที่ไม่น่าเชื่อถือเป็นพิเศษ และไม่ชัดเจนว่าจะคาดหวังอะไรได้บ้าง — ออกแบบมาโดยเฉพาะสำหรับการบล็อกทรัพยากร รวมถึง TCP RST

NOC ของการแลกเปลี่ยนทางอินเทอร์เน็ตนี้กำลังมองหาปัญหาอยู่ ตามที่พวกเขาพูด (และฉันเชื่อพวกเขา) พวกเขาไม่มีระบบการกรองที่ใช้งานเป็นพิเศษ แต่ขอบคุณสวรรค์ ภารกิจต่อไปไม่ใช่ปัญหาของเราอีกต่อไป :)

นี่เป็นความพยายามเล็กๆ น้อยๆ ที่จะพิสูจน์ตัวเอง โปรดเข้าใจและให้อภัย :)

PS: ฉันจงใจไม่ตั้งชื่อผู้ผลิต DPI/NAT หรือ IX (อันที่จริง ฉันไม่ได้มีข้อร้องเรียนพิเศษใดๆ เกี่ยวกับพวกเขาด้วยซ้ำ สิ่งสำคัญคือต้องเข้าใจว่ามันคืออะไร)

ความเป็นจริงของวันนี้ (เช่นเดียวกับเมื่อวานและวันก่อนของเมื่อวาน) จากมุมมองของผู้ให้บริการอินเทอร์เน็ต

ฉันใช้เวลาหลายสัปดาห์ที่ผ่านมาในการสร้างแกนหลักของเครือข่ายขึ้นใหม่อย่างมีนัยสำคัญ โดยดำเนินการหลายอย่าง "เพื่อผลกำไร" โดยมีความเสี่ยงที่จะส่งผลกระทบอย่างมีนัยสำคัญต่อการรับส่งข้อมูลของผู้ใช้จริง เมื่อพิจารณาถึงเป้าหมาย ผลลัพธ์ และผลที่ตามมาของทั้งหมดนี้ ในทางศีลธรรมแล้ว ทั้งหมดนี้ค่อนข้างยาก โดยเฉพาะอย่างยิ่ง - ฟังสุนทรพจน์ที่สวยงามเกี่ยวกับการปกป้องความมั่นคงของ Runet อธิปไตย ฯลฯ อีกครั้ง และอื่น ๆ

ในส่วนนี้ ฉันจะพยายามอธิบาย "วิวัฒนาการ" ของแกนเครือข่ายของ ISP ทั่วไปในช่วงสิบปีที่ผ่านมา

สิบปีก่อน.

ในช่วงเวลาที่มีความสุขเหล่านั้น แกนหลักของเครือข่ายผู้ให้บริการอาจเรียบง่ายและเชื่อถือได้พอๆ กับการจราจรติดขัด:

ในภาพที่เรียบง่ายมากนี้ ไม่มีเส้นทาง trunk, วงแหวน, ip/mpls

สิ่งสำคัญคือในที่สุดการรับส่งข้อมูลของผู้ใช้ก็มาถึงการสลับระดับเคอร์เนล - จากที่ที่มันไป BNGตามกฎแล้วกลับไปที่การสลับหลักแล้ว "ออก" - ผ่านเกตเวย์ชายแดนหนึ่งรายการขึ้นไปไปยังอินเทอร์เน็ต

รูปแบบดังกล่าวเป็นเรื่องง่ายมากที่จะจองทั้งบน L3 (การกำหนดเส้นทางแบบไดนามิก) และบน L2 (MPLS)

คุณสามารถติดตั้ง N+1 อะไรก็ได้: เซิร์ฟเวอร์การเข้าถึง สวิตช์ ขอบเขต - และวิธีใดวิธีหนึ่งสงวนไว้สำหรับการเฟลโอเวอร์อัตโนมัติ

หลังจากนั้นไม่กี่ปี เป็นที่ชัดเจนสำหรับทุกคนในรัสเซียว่าเป็นไปไม่ได้ที่จะใช้ชีวิตแบบนี้อีกต่อไป การปกป้องเด็ก ๆ จากอิทธิพลที่เป็นอันตรายของอินเทอร์เน็ตเป็นเรื่องเร่งด่วน

มีความจำเป็นเร่งด่วนในการหาวิธีกรองการรับส่งข้อมูลของผู้ใช้

มีแนวทางที่แตกต่างกันที่นี่

ในกรณีที่ไม่ค่อยดีนัก มีบางอย่าง "อยู่ในช่องว่าง": ระหว่างการรับส่งข้อมูลของผู้ใช้และอินเทอร์เน็ต การรับส่งข้อมูลที่ส่งผ่าน "บางสิ่ง" นี้ได้รับการวิเคราะห์และตัวอย่างเช่นแพ็กเก็ตปลอมที่มีการเปลี่ยนเส้นทางจะถูกส่งไปยังสมาชิก

ในกรณีที่ดีกว่าเล็กน้อย - หากปริมาณการรับส่งข้อมูลอนุญาต - คุณสามารถทำเคล็ดลับเล็ก ๆ น้อย ๆ ได้: ส่งเพื่อกรองเฉพาะการรับส่งข้อมูลที่มาจากผู้ใช้ไปยังที่อยู่เหล่านั้นเท่านั้นที่ต้องกรอง (ในการดำเนินการนี้คุณสามารถใช้ที่อยู่ IP ได้ ระบุไว้จากรีจิสทรีหรือแก้ไขโดเมนที่มีอยู่ในรีจิสทรีเพิ่มเติม)

ครั้งหนึ่งฉันเขียนข้อความง่ายๆ เพื่อจุดประสงค์เหล่านี้ มินิ dpi - แม้ว่าฉันจะไม่กล้าเรียกเขาแบบนั้นก็ตาม มันง่ายมากและไม่มีประสิทธิภาพมากนัก อย่างไรก็ตาม มันทำให้เราและผู้ให้บริการรายอื่นๆ หลายสิบราย (ถ้าไม่ใช่หลายร้อย) ไม่ต้องจ่ายเงินหลายล้านในระบบ DPI อุตสาหกรรมในทันที แต่ให้เวลาเพิ่มอีกหลายปี

อย่างไรก็ตาม เกี่ยวกับ DPI ในขณะนั้นและปัจจุบันอย่างไรก็ตาม หลายๆ คนที่ซื้อระบบ DPI ที่มีจำหน่ายในท้องตลาดในขณะนั้นได้ทิ้งมันไปไปแล้ว พวกเขาไม่ได้ออกแบบมาเพื่อสิ่งนี้: ที่อยู่นับแสน, URL นับหมื่น

และในขณะเดียวกันผู้ผลิตในประเทศก็เพิ่มขึ้นอย่างมากในตลาดนี้ ฉันไม่ได้พูดถึงส่วนประกอบของฮาร์ดแวร์ - ทุกอย่างชัดเจนสำหรับทุกคนที่นี่ แต่ซอฟต์แวร์ - สิ่งสำคัญที่ DPI มี - บางทีในปัจจุบันนี้ หากไม่ใช่สิ่งที่ก้าวหน้าที่สุดในโลก ก็แน่นอนว่า ก) พัฒนาอย่างก้าวกระโดด และ b) ในราคาของผลิตภัณฑ์ชนิดบรรจุกล่องซึ่งไม่มีใครเทียบได้กับคู่แข่งจากต่างประเทศ

ฉันก็อยากจะภูมิใจ แต่ก็เศร้านิดหน่อย =)

ตอนนี้ทุกอย่างดูเหมือน:

ในอีกสองสามปีข้างหน้า ทุกคนมีผู้ตรวจสอบบัญชีอยู่แล้ว มีทรัพยากรในรีจิสทรีเพิ่มมากขึ้นเรื่อยๆ สำหรับอุปกรณ์รุ่นเก่าบางรุ่น (เช่น Cisco 7600) รูปแบบ "การกรองด้านข้าง" เริ่มใช้ไม่ได้อีกต่อไป: จำนวนเส้นทางบน 76 แพลตฟอร์มถูกจำกัดไว้ที่ประมาณเก้าแสน ขณะที่จำนวนเส้นทาง IPv4 เพียงอย่างเดียวในปัจจุบันกำลังเข้าใกล้ 800 พัน. แล้วถ้าเป็น ipv6 ด้วย... แล้วยัง... มีเท่าไหร่ล่ะ? มีที่อยู่ 900000 รายการในการแบน RKN? =)

มีคนเปลี่ยนไปใช้รูปแบบที่มีการมิเรอร์การรับส่งข้อมูลแกนหลักทั้งหมดไปยังเซิร์ฟเวอร์กรอง ซึ่งควรวิเคราะห์โฟลว์ทั้งหมด และหากพบสิ่งที่ไม่ดี ให้ส่ง RST ในทั้งสองทิศทาง (ผู้ส่งและผู้รับ)

อย่างไรก็ตาม ยิ่งมีการรับส่งข้อมูลมากเท่าใด รูปแบบนี้ก็จะยิ่งมีประสิทธิภาพน้อยลงเท่านั้น หากมีความล่าช้าเล็กน้อยในการประมวลผล การรับส่งข้อมูลที่มิเรอร์จะหายไปโดยไม่มีใครสังเกตเห็น และผู้ให้บริการจะได้รับรายงานที่ดี

ผู้ให้บริการจำนวนมากขึ้นเรื่อยๆ ถูกบังคับให้ติดตั้งระบบ DPI ที่มีระดับความน่าเชื่อถือที่แตกต่างกันไปตามทางหลวง

หนึ่งหรือสองปีที่ผ่านมา ตามข่าวลือ FSB เกือบทั้งหมดเริ่มเรียกร้องให้มีการติดตั้งอุปกรณ์จริง ซอม (ก่อนหน้านี้ผู้ให้บริการส่วนใหญ่จัดการโดยได้รับอนุมัติจากทางการ แผนซอม - แผนมาตรการปฏิบัติการกรณีจำเป็นต้องหาของที่ไหนสักแห่ง)

นอกเหนือจากเงิน (ไม่มากจนเกินไปนัก แต่ยังเป็นล้าน) SORM ยังต้องการการจัดการเครือข่ายอีกมากมาย

• SORM จำเป็นต้องเห็นที่อยู่ผู้ใช้ "สีเทา" ก่อนที่จะแปล nat
• SORM มีอินเทอร์เฟซเครือข่ายจำนวนจำกัด

ดังนั้น โดยเฉพาะอย่างยิ่ง เราต้องสร้างเคอร์เนลขึ้นใหม่อย่างมาก เพียงเพื่อที่จะรวบรวมการรับส่งข้อมูลของผู้ใช้ไปยังเซิร์ฟเวอร์การเข้าถึงที่ใดที่หนึ่งไว้ในที่เดียว เพื่อที่จะสะท้อนมันใน SORM ด้วยลิงก์หลาย ๆ อัน

นั่นคือ ง่ายมาก คือ (ซ้าย) กับ กลายเป็น (ขวา):

ขณะนี้ ผู้ให้บริการส่วนใหญ่ยังต้องการการนำ SORM-3 ไปใช้ ซึ่งรวมถึงการบันทึกการออกอากาศแบบ nat ด้วย

เพื่อจุดประสงค์เหล่านี้ เรายังต้องเพิ่มอุปกรณ์แยกต่างหากสำหรับ NAT ลงในไดอะแกรมด้านบน (ตรงกับที่กล่าวไว้ในส่วนแรก) นอกจากนี้ ให้เพิ่มลำดับที่แน่นอน: เนื่องจาก SORM ต้อง "ดู" การรับส่งข้อมูลก่อนที่จะแปลที่อยู่ การรับส่งข้อมูลจะต้องดำเนินการอย่างเคร่งครัดดังนี้: ผู้ใช้ -> การสลับ, เคอร์เนล -> เซิร์ฟเวอร์การเข้าถึง -> SORM -> NAT -> การสลับ, เคอร์เนล - > อินเทอร์เน็ต ในการทำเช่นนี้ เราต้อง "เปลี่ยน" กระแสการจราจรไปในทิศทางอื่นเพื่อหากำไร ซึ่งก็ค่อนข้างยากเช่นกัน

โดยสรุป: ในช่วงสิบปีที่ผ่านมา การออกแบบหลักของผู้ให้บริการโดยเฉลี่ยมีความซับซ้อนมากขึ้นหลายเท่า และจุดความล้มเหลวเพิ่มเติม (ทั้งในรูปแบบของอุปกรณ์และในรูปแบบของสายสวิตช์เดี่ยว) ได้เพิ่มขึ้นอย่างมีนัยสำคัญ จริงๆ แล้ว ข้อกำหนดอย่างยิ่งในการ "มองเห็นทุกสิ่ง" หมายถึงการลด "ทุกสิ่ง" นี้ให้เหลือเพียงจุดเดียว

ฉันคิดว่าสิ่งนี้สามารถคาดการณ์ได้อย่างโปร่งใสถึงความคิดริเริ่มในปัจจุบันเพื่ออธิปไตย Runet ปกป้องมัน ทำให้เสถียรและปรับปรุง :)

และยาโรวายายังอยู่ข้างหน้า

ที่มา: will.com