ประกาศ Anycast IPsec: เส้นทางใหม่สำหรับ Cloudflare One

วันนี้ เรารู้สึกตื่นเต้นที่จะประกาศการสนับสนุน IPsec ให้เป็นเส้นทางใหม่สู่ Cloudflare One ในฐานะลูกค้า คุณควรจะใช้วิธีใดก็ได้ที่คุณต้องการเพื่อการรับส่งข้อมูลไปยังเครือข่ายของ Cloudflare เราทราบจากคุณว่า IPsec คือวิธีการที่คุณเลือกใช้เพื่อเชื่อมต่อกับเราที่เลเยอร์เครือข่าย เนื่องจากผู้ขายให้การสนับสนุนที่ใกล้เคียงระดับสากลและเลเยอร์การเข้ารหัสครอบคลุมในทุกการรับส่งข้อมูล ดังนั้นเราจึงเตรียมการสนับสนุนไว้ให้! แนะนำให้อ่านต่อเพื่อค้นหาคำตอบว่า การใช้งาน IPsec ของเรานั้นเร็วและง่ายกว่าการเชื่อมต่อ IPsec แบบเดิมอย่างไร และการผสานรวมเข้ากับชุดโปรแกรม Cloudflare One อย่างสมบูรณ์ เพื่อมอบความปลอดภัย ประสิทธิภาพ และความน่าเชื่อถือแบบรวมเป็นหนึ่งเดียวในทุกการรับส่งข้อมูลของคุณจะออกในรูปใด

ด้วย Cloudflare One ลูกค้าสามารถเชื่อมต่อต้นทางหรือปลายทางของการรับส่งข้อมูล ไม่ว่าจะเป็นสำนักงานสาขา ศูนย์ข้อมูล ทรัพย์สินระบบคลาวด์ อุปกรณ์ของผู้ใช้ เข้ากับเครือข่ายของเรา การรับส่งข้อมูลถูกกำหนดเส้นทางไปยังตำแหน่ง Cloudflare ที่ใกล้ที่สุด ซึ่งมีการนำนโยบายความปลอดภัยมาใช้ก่อนที่เราจะส่งข้อมูลไปตามเส้นทางที่ปรับให้เหมาะสมเพื่อไปยังปลายทาง ไม่ว่าจะภายในเครือข่ายส่วนตัวของคุณหรือบนอินเทอร์เน็ต ถือเป็นแนวทางปฏิบัติที่ดีหากจะเข้ารหัสการรับส่งข้อมูลที่มีความละเอียดอ่อนในระดับแอปพลิเคชัน แต่สำหรับลูกค้าที่กำลังเปลี่ยนจากรูปแบบการเชื่อมต่อส่วนตัว เช่น Multiprotocol Label Switching (MPLS) มักจะไม่เป็นเช่นนั้น เราได้พูดคุยกับลูกค้าจำนวนมากที่มีการถ่ายโอนไฟล์แบบเดิมและแอปพลิเคชันอื่น ๆ ที่ทำงานข้ามวงจร MPLS แบบไม่มีการเข้ารหัส และอิงอยู่กับข้อเท็จจริงที่ว่าวงจรเหล่านี้เป็น "ส่วนตัว" เพื่อให้การรักษาความปลอดภัย ในการเริ่มส่งการรับส่งข้อมูลนี้ทางอินเทอร์เน็ต ลูกค้าจำเป็นต้องมีเลเยอร์การเข้ารหัสที่ครอบคลุมทั้งหมด ซึ่ง IPsec tunnel ช่วยให้ทำสิ่งนี้ให้สำเร็จได้

IPsec เป็นเทคโนโลยีที่มีมาตั้งแต่ปี 1995 และถูกนำไปใช้อย่างกว้างขวางในแพลตฟอร์มฮาร์ดแวร์และซอฟต์แวร์จำนวนมาก หลายบริษัทได้ใช้ IPsec VPN เมื่อถ่ายโอนการรับส่งข้อมูลของบริษัทผ่านอินเทอร์เน็ตให้ปลอดภัย VPN เหล่านี้มักจะมีหนึ่งในสองสถาปัตยกรรมหลัก: Hub and Spoke หรือ Mesh

ในโมเดล Hub and Spoke นั้น โหนด "Spoke" แต่ละโหนดจะสร้าง IPsec tunnel กลับไปยัง "Hub" หลัก ซึ่งมักจะเป็นสำนักงานใหญ่หรือที่ตั้งของศูนย์ข้อมูล การรับส่งข้อมูลระหว่าง Spoke จะไหลผ่าน Hub สำหรับการกำหนดเส้นทางและเพื่อให้มีการใช้นโยบายความปลอดภัย (เช่นโดยไฟร์วอลล์ในองค์กร) สถาปัตยกรรมนี้เรียบง่ายเพราะแต่ละโหนดจำเป็นต้องรักษา tunnel หนึ่งช่องเพื่อเชื่อมต่อไปยังตำแหน่งอื่น แต่สามารถทำให้ประสิทธิภาพถูกลดทอนลงไปได้อย่างมาก ลองนึกภาพเครือข่ายทั่วโลกที่มี "Spoke" สองอัน อันหนึ่งอยู่ในอินเดียและอีกอันในสิงคโปร์ แต่ "Hub" ตั้งอยู่ในสหรัฐอเมริกา การรับส่งข้อมูลจำเป็นต้องเดินทางไปกลับหลายพันไมล์เพื่อไปยังปลายทาง

ในโมเดล Mesh ทุกโหนดเชื่อมต่อกับโหนดอื่นทุกโหนดด้วยช่องสัญญาณ IPsec เฉพาะ ซึ่งจะช่วยปรับปรุงประสิทธิภาพเนื่องจากการรับส่งข้อมูลสามารถใช้เส้นทางที่ตรงกว่าได้ แต่ในทางปฏิบัติหมายถึงช่องสัญญาณที่ไม่สามารถจัดการได้จำนวนหนึ่งหลังจากเพิ่มตำแหน่งที่ตั้งจำนวนหนึ่งแล้ว

ลูกค้าที่เราได้พูดคุยด้วยเกี่ยวกับ IPsec ทราบดีว่าพวกเขาต้องการสิ่งนี้สำหรับเลเยอร์ารเข้ารหัสแบบครอบคลุมและการสนับสนุนจากผู้จำหน่ายในวงกว้าง แต่พวกเขาก็ไม่ได้รู้สึก_ตื่นเต้น_เป็นพิเศษกับเรื่องนี้เพราะยังมีปัญหากับโมเดลสถาปัตยกรรมที่มีอยู่ เรารู้ว่าเราต้องการพัฒนาบางสิ่งที่ใช้งานง่ายขึ้นและทิ้งปัญหาเหล่านั้นไว้ในอดีต เพื่อให้ลูกค้ารู้สึกตื่นเต้นกับการสร้างเครือข่ายรุ่นถัดไปบน Cloudflare แล้วเราจะนำ IPsec ออกจากยุค 90 ได้อย่างไร คำตอบคือด้วยการส่งมอบบนเครือข่าย Anycast ทั่วโลกของเรา: ลูกค้าสร้าง IPsec tunnel หนึ่งช่องให้เราและรับการเชื่อมต่ออัตโนมัติไปยังตำแหน่งที่ตั้งมากกว่า 250 แห่ง ซึ่งจริง ๆ แล้ว Hub มีแนวคิดคล้ายกับโมเดล Hub and Spoke แต่ “Hub” มีอยู่ทุกหนทุกแห่ง รวดเร็วทันใจและจัดการง่าย

IPsec ออกแบบมาในปี 1995 เพื่อให้การรับรองการตรวจสอบสิทธิ์ ความสมบูรณ์ และการรักษาความลับสำหรับแพ็กเก็ต IP วิธีหนึ่งในการทำเช่นนี้คือการสร้าง tunnel ระหว่างสองโฮสต์ เข้ารหัสแพ็กเก็ต IP และเพิ่มส่วนหัว IP ใหม่ลงในแพ็กเก็ตที่เข้ารหัส ซึ่งทั้งหมดนี้จะเกิดขึ้นได้ IPsec จะมีสององค์ประกอบที่ทำงานร่วมกัน: userspace Internet Key Exchange (IKE) daemon และ IPsec stack ในเคอร์เนลสเปซ ทั้งนี้ IKE เป็นโปรโตคอลที่สร้าง Security Associations (SAs) สำหรับ IPsec โดย SA คือชุดของพารามิเตอร์ความปลอดภัยทั้งหมด เช่น พารามิเตอร์สำหรับการตรวจสอบสิทธิ์และการเข้ารหัส ที่จำเป็นสำหรับการสร้าง IPsec tunnel

เมื่อต้องตั้งค่า IPsec tunnel ใหม่ สิ่งที่จะเกิดขึ้นคือ IKE daemon หนึ่งจะเริ่มต้นเซสชันกับอีกอันหนึ่งและสร้าง SA ความซับซ้อนทั้งหมดของการกำหนดค่า การเจรจาคีย์ และการสร้างคีย์ล้วนเกิดขึ้นอย่างปลอดภัยในแพ็กเก็ตจำนวนหนึ่งระหว่างสอง IKE daemons ภายในพื้นที่ผู้ใช้ เมื่อ IKE Daemon เริ่มเซสชันแล้ว IKE Daemon ก็จะส่งต่อ SA ที่ดีและเหมาะสมไปยังสแต็ก IPsec ในเคอร์เนลสเปซ ซึ่งขณะนี้มีข้อมูลทั้งหมดที่จำเป็นในการสกัดกั้นแพ็กเก็ตที่ถูกต้องสำหรับการเข้ารหัสลับและการถอดรหัสลับ

มี IKE Daemon แบบโอเพ่นซอร์สมากมาย รวมถึง strongSwan, Libreswan และ Openswan ที่เราพิจารณาใช้เมื่อติดตั้ง IPsec “Swan” เหล่านี้ล้วนผูกติดอยู่กับโปรโตคอล IKE อย่างแน่นหนาผ่านการกำหนดค่าสแต็ก IPsec ซึ่งเหมาะอย่างยิ่งสำหรับการสร้าง tunnel แบบจุดต่อจุด ซึ่งก็คือการติดตั้ง “Swan” เพียงหนึ่งเดียวเพื่อพูด IKE และกำหนดค่า tunnel ที่เข้ารหัสลับ แต่เรากำลังสร้างเครือข่ายรุ่นถัดไปที่ใช้ประโยชน์จาก Anycast edge ทั่วโลกของ Cloudflare แล้วเราจะสร้างเครือข่ายดังกล่าวขึ้นมาได้อย่างไรเพื่อให้ลูกค้าตั้งค่า tunnel หนึ่งด้วย Cloudflare เข้ากับเซิร์ฟเวอร์ Edge เดี่ยว ๆ ที่สามารถแลกเปลี่ยนข้อมูลได้

ปัญหาพื้นฐานในแบบของ Anycast IPsec คือจำเป็นต้องส่งต่อ SA ไปยัง kernel-space IPsec stack บนเซิร์ฟเวอร์ Edge ของ Cloudflare ทุกเครื่อง แต่ SA ถูกสร้างขึ้นบนเซิร์ฟเวอร์เพียงเครื่องเดียว ซึ่งก็คือเซิร์ฟเวอร์ที่รัน IKE daemon ที่ IKE daemon ของลูกค้าเชื่อมต่อ เราจะแก้ไขปัญหานี้อย่างไร สิ่งแรกที่ต้องเป็นจริงคือทุกเซิร์ฟเวอร์ต้องสามารถสร้าง SA นั้นได้

ตอนนี้เซิร์ฟเวอร์ Cloudflare ทุกเครื่องรัน IKE daemon เรียบร้อยแล้ว ดังนั้นลูกค้าจึงมีการเชื่อมต่อที่รวดเร็วและเชื่อถือได้เพื่อเริ่ม tunnel ทุกที่ในโลก เราดูที่การใช้หนึ่งใน "Swan" ที่มีอยู่ แต่การประกบคู่ที่แน่นหนาของ IKE กับ IPsec stack หมายความว่า SA แยกตัวเองออกจากการกำหนดค่าระนาบข้อมูลได้ยาก เราต้องการ SA ที่แยกจากกันโดยสิ้นเชิงและสามารถแชร์ได้จากเซิร์ฟเวอร์ที่สร้างไปยังเซิร์ฟเวอร์อื่นบน Edge ของเรา ซึ่งแน่นอน เราสร้าง “Swan” ขึ้นมาเองเพื่อทำเช่นนั้น

เพื่อส่ง SA ไปทั่วโลก เราได้ทำเรื่องเดิมแต่ในรูปแบบใหม่ เพราะด้วย Cloudflare Tunnels กระบวนการ tunnel cloudflare ของลูกค้าจะสร้างการเชื่อมต่อกับเซิร์ฟเวอร์ Edge Cloudflare ใกล้เคียงสองสามเครื่อง แต่การรับส่งข้อมูลที่กำหนดไว้สำหรับ tunnel นั้นอาจมาถึงเซิร์ฟเวอร์ Edge ใดก็ได้ ซึ่งจำเป็นต้องรู้วิธีพร็อกซีการรับส่งข้อมูลไปยังเซิร์ฟเวอร์ Edge ที่เชื่อมต่อกับ tunnel ดังนั้นเราจึงสร้างเทคโนโลยีที่ช่วยให้เซิร์ฟเวอร์ Edge สามารถแจกจ่ายข้อมูลเกี่ยวกับการเชื่อมต่อ Cloudflare Tunnel ไปยังเซิร์ฟเวอร์ Edge อื่น ๆ ทั้งหมดได้อย่างรวดเร็ว

โดยพื้นฐานแล้ว ปัญหาของการกระจาย SA นั้นคล้ายคลึงกัน กล่าวคือ IKE daemon ของลูกค้าเชื่อมต่อกับ IKE daemon ของเซิร์ฟเวอร์ Edge Cloudflare เดียว และจำเป็นต้องแจกจ่ายข้อมูลเกี่ยวกับการเชื่อมต่อนั้นไปยัง เซิร์ฟเวอร์ Edge อื่น ๆ ทุกเซิร์ฟเวอร์ เราจึงอัพเกรดเทคโนโลยี Cloudflare Tunnel ให้ใช้กันโดยทั่วไปได้มากขึ้น และตอนนี้กำลังใช้เทคโนโลยีนี้เพื่อแจกจ่าย SA ซึ่งเป็นส่วนหนึ่งของการสนับสนุน Anycast IPsec ภายในไม่กี่วินาทีหลังจากสร้าง SA ระบบจะแจกจ่าย SA ไปยังเซิร์ฟเวอร์ Edge ของ Cloudflare ทุกเครื่องที่โปรโตคอลการสตรีมนำการกำหนดค่ามาใช้กับ IPsec stack ของเคอร์เนลสเปซ Anycast IPsec ของ Cloudflare ได้รับประโยชน์จากความน่าเชื่อถือและความยืดหยุ่นแบบเดียวกับที่เราสร้างขึ้นใน Cloudflare Tunnel และเปลี่ยนเครือข่ายของเราให้กลายเป็น IPsec tunnel ที่ปรับขนาดได้อย่างเหมาะสม หนึ่งเดียวไปยังเครือข่ายของคุณ

เราสร้าง IPsec เพื่อเป็นเส้นทางไปยัง Cloudflare One ไว้บนสถาปัตยกรรมระบบที่มีอยู่ทั่วโลก โดยให้ความสำคัญกับลูกค้าก่อนเป็นอันดับแรก คุณสนใจเรื่องความสะดวกในการปรับใช้ ดังนั้นเราจึงช่วยให้คุณสามารถเชื่อมต่อกับเครือข่ายเสมือนทั้งหมดของคุณบน Cloudflare One ด้วย IPsec tunnel เดียว คุณใส่ใจในประสิทธิภาพการทำงาน เราจึงสร้างเทคโนโลยีที่เชื่อมต่อ IPsec tunnel ของคุณกับตำแหน่ง Cloudflare ทุกแห่ง ขจัดการลดทอนประสิทธิภาพสำหรับโมเดล Hub-and-Spoke คุณใส่ใจในการบังคับใช้นโยบายความปลอดภัยในการรับส่งข้อมูลทุกครั้งของคุณโดยไม่คำนึงถึงแหล่งที่มา ดังนั้นเราจึงรวม IPsec เข้ากับชุด Cloudflare One ทั้งหมด รวมถึง Magic Transit, Magic Firewall, Zero Trust และอีกมากมาย

IPsec รวมอยู่ในการเข้าถึงสำหรับลูกค้า Cloudflare One ไว้ล่วงหน้าแล้ว ถ้าคุณอยากทดลองใช้ดู โปรดติดต่อทีมฝ่ายบริการลูกค้าของเราได้เลย!