Site-to-Site VPN คืออะไร เหมาะกับองค์กรแบบไหน

บริษัทที่มีสำนักงานใหญ่และสองสาขาเจอปัญหาง่าย ๆ ระบบบัญชีอยู่ตึกหนึ่ง ฐานข้อมูลสต็อกอยู่อีกตึก และคนที่ต้องใช้ทั้งสองอยู่ตึกที่สาม การเช่าสายส่วนตัวระหว่างทุกที่แพงมาก การเปิดแต่ละระบบสู่อินเทอร์เน็ตทั้งหมดก็ไม่ฉลาด Site-to-Site VPN แก้ปัญหานี้โดยเชื่อมเครือข่ายผ่านอินเทอร์เน็ตสาธารณะด้วยอุโมงค์เข้ารหัส ทำให้ทั้งสามตึกทำงานเหมือนเป็นส่วนหนึ่งของเครือข่ายส่วนตัวเดียวกัน

บทความนี้อธิบายสถาปัตยกรรมด้วยภาษาเรียบง่าย เกตเวย์ทำอะไร อุโมงค์และเส้นทางทำงานอย่างไร รูปแบบที่พบบ่อยมีอะไรบ้าง วางแผนที่อยู่ IP อย่างไร จะเกิดอะไรเมื่อลิงก์ล้ม แนวทางนี้เหมาะกับงานแบบไหนและไม่เหมาะแบบไหน เขียนสำหรับเจ้าของกิจการ ผู้จัดการสำนักงาน และเจ้าหน้าที่ไอทีมือใหม่ที่กำลังประเมินแนวคิดนี้ ถ้าต้องการเวอร์ชันสำหรับเชื่อมเครือข่ายที่บ้านกับอีกแห่ง ดูบทความคู่กันเรื่อง Site-to-Site VPN สำหรับบ้าน ส่วนบทความนี้เน้นการใช้งานในธุรกิจและองค์กร

Site-to-Site VPN คืออะไร และไม่ใช่อะไร

ในการออกแบบแบบ site-to-site แต่ละสถานที่มีเกตเวย์ มักเป็นไฟร์วอลล์หรือเราเตอร์ที่เชื่อมสถานที่กับอินเทอร์เน็ตอยู่แล้ว เกตเวย์สองตัวตกลงเรื่องกุญแจ สร้างอุโมงค์เข้ารหัส และส่งข้อมูลของทั้งเครือข่ายผ่านอุโมงค์นั้น คอมพิวเตอร์ เครื่องพิมพ์ และเซิร์ฟเวอร์ที่แต่ละสถานที่ไม่รู้ด้วยซ้ำว่ามี VPN พวกมันส่งข้อมูลไปยังที่อยู่ฝั่งตรงข้าม และเกตเวย์จัดการส่วนที่เหลือ

นี่คือข้อแตกต่างสำคัญจาก VPN ที่คนส่วนใหญ่รู้จัก VPN ส่วนบุคคลหรือ Remote Access VPN รันซอฟต์แวร์บนอุปกรณ์เครื่องเดียวและเชื่อมอุปกรณ์นั้นกับเซิร์ฟเวอร์ ส่วน Site-to-Site VPN รันบนโครงสร้างพื้นฐานและเชื่อมเครือข่าย พนักงานที่สาขาไม่ต้องล็อกอิน VPN เพราะเครือข่ายของพวกเขาอยู่ข้างในอยู่แล้ว บทความ VPN ธุรกิจเทียบกับ VPN ส่วนตัว วางสองแบบไว้เทียบกัน

สิ่งที่มันไม่ใช่

• ไม่ใช่เครื่องมือความเป็นส่วนตัวสำหรับท่องเว็บ มันไม่ซ่อนกิจกรรมของคุณจากบริษัทหรือผู้ให้บริการอินเทอร์เน็ตของคุณแบบที่ VPN ส่วนบุคคลตั้งใจทำ
• ไม่ใช่ตัวแทนของความปลอดภัยภายในแต่ละสถานที่ ทุกอย่างที่มาถึงเครือข่ายหนึ่งจากอีกเครือข่ายถือว่าเชื่อถือได้ เว้นแต่กฎกำหนดไว้เป็นอย่างอื่น
• ไม่ได้เร็วโดยอัตโนมัติ อุโมงค์ถูกจำกัดด้วยการเชื่อมต่ออินเทอร์เน็ตของทั้งสองสถานที่และความสามารถของเกตเวย์ในการเข้ารหัส

อุโมงค์ถูกสร้างอย่างไร

Site-to-Site VPN ส่วนใหญ่ใช้ IPsec ซึ่งเป็นชุดมาตรฐานที่อธิบายใน RFC 4301 เกตเวย์ตกลงความสัมพันธ์ที่ปลอดภัยก่อน แล้วจึงใช้มันปกป้องข้อมูลจริง วิธีมาตรฐานสำหรับการเจรจาคือ IKEv2 ซึ่งอธิบายใน RFC 7296 บทความ IKEv2 และ IPsec อธิบายด้วยภาษาที่ใกล้ตัวกว่า

โดยสรุป กระบวนการมีสองขั้น

1. การยืนยันตัวตนและตกลงกุญแจ เกตเวย์แต่ละตัวพิสูจน์ตัวตนต่ออีกฝ่ายด้วยกุญแจที่ใช้ร่วมกันล่วงหน้าหรือใบรับรองดิจิทัล และตกลงกุญแจสำหรับการเข้ารหัส ขั้นนี้บางครั้งเรียกว่าอุโมงค์ควบคุม
2. การปกป้องข้อมูล เกตเวย์ใช้กุญแจเหล่านั้นสร้างการเชื่อมต่อย่อยที่ส่งข้อมูลจริง แต่ละการเชื่อมต่อตั้งไว้สำหรับคู่เครือข่ายเฉพาะ

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

คู่มือของอุปกรณ์มีรูปแบบการออกแบบสองแบบ

รูปแบบ	วิธีตัดสินว่าอะไรต้องป้องกัน	เหมาะกับ	ข้อควรระวัง
Policy-based	รายการกฎที่จับคู่เครือข่ายต้นทางและปลายทาง	สองสถานที่ที่ช่วงที่อยู่คงที่และเรียบง่าย	กฎเพิ่มพูนเมื่อเพิ่มเครือข่าย และกฎที่ไม่ตรงกันสองฝั่งทำให้ล้มเหลวแบบเงียบ
Route-based	อินเทอร์เฟซอุโมงค์เสมือน และตารางเส้นทางกำหนดว่าอะไรใช้มัน	หลายสถานที่ การกำหนดเส้นทางแบบไดนามิก การสำรอง	ต้องมีความรู้เรื่องเส้นทาง และเส้นทางผิดอาจส่งข้อมูลผิดทาง

การออกแบบแบบ route-based โดยทั่วไปขยายง่ายกว่า จึงครอบงำเมื่อธุรกิจมีมากกว่าสองถึงสามสถานที่

รูปแบบการจัดวาง point-to-point, hub-and-spoke และ mesh

วิธีจัดวางอุโมงค์สำคัญพอ ๆ กับวิธีสร้างอุโมงค์หนึ่งเส้น

• Point-to-point สองสถานที่ หนึ่งอุโมงค์ เรียบง่ายและแก้ปัญหาง่าย เหมาะกับสำนักงานใหญ่ที่มีสาขาเดียว หรือบริษัทที่มีโกดังแยก
• Hub-and-spoke มีสถานที่ศูนย์กลางเป็น hub และอุโมงค์ไปยังแต่ละสาขาเป็น spoke ข้อมูลระหว่างสาขาผ่าน hub จำนวนอุโมงค์น้อยและมีจุดเดียวสำหรับใช้กฎ แต่ hub กลายเป็นจุดล้มเหลวเดี่ยวและคอขวด
• Full mesh ทุกสถานที่มีอุโมงค์ไปยังทุกสถานที่อื่น ข้อมูลระหว่างสาขาไปตรงและเร็ว จำนวนอุโมงค์เพิ่มเร็วมาก ห้าสถานที่ต้องการสิบอุโมงค์ สิบสถานที่ต้องการสี่สิบห้า การจัดการจึงเป็นภาระ เว้นแต่อุปกรณ์ทำให้เป็นอัตโนมัติ
• Partial mesh ใช้ hub-and-spoke สำหรับข้อมูลส่วนใหญ่ และเพิ่มอุโมงค์ตรงเฉพาะระหว่างสถานที่ที่คุยกันมาก
• เชื่อมกับคลาวด์ อุโมงค์หนึ่งเส้นหรือมากกว่าจากออฟฟิศไปยังเครือข่ายเสมือนของผู้ให้บริการคลาวด์ ทำให้เซิร์ฟเวอร์ที่โฮสต์ที่นั่นปรากฏเป็นส่วนหนึ่งของเครือข่ายส่วนตัว

กฎที่เป็นประโยชน์คือเริ่มจากรูปแบบที่ง่ายที่สุดที่ตรงกับการเคลื่อนย้ายข้อมูลจริงของคน ถ้าสาขาคุยแต่กับสำนักงานใหญ่ hub-and-spoke ก็เพียงพอ

วางแผนที่อยู่ IP ก่อนอย่างอื่น

เหตุผลที่พบบ่อยที่สุดของอาการ "อุโมงค์ขึ้นแล้วแต่ไม่มีอะไรใช้ได้" คือปัญหาที่อยู่ แต่ละสถานที่ต้องมีช่วงส่วนตัวของตัวเอง และช่วงต้องไม่ซ้อนกัน RFC 1918 กำหนดช่วงส่วนตัวที่ใช้ภายในเครือข่ายส่วนใหญ่

ลองดูตัวอย่าง สองสำนักงานใช้ 192.168.1.0/24 เหมือนกัน คอมพิวเตอร์ในออฟฟิศ A พยายามเข้า 192.168.1.20 นั่นคือเครื่องพิมพ์ในออฟฟิศของตัวเองหรือเซิร์ฟเวอร์ในออฟฟิศ B มันแยกไม่ออก จึงสันนิษฐานว่าเป็นของท้องถิ่น และไม่เคยใช้อุโมงค์เลย

กฎการวางแผนที่ใช้ได้จริง

1. ให้ทุกสถานที่มีช่วงที่ไม่ซ้ำกัน เช่น 10.10.0.0/24 สำหรับสำนักงานใหญ่ 10.20.0.0/24 สำหรับสาขาแรก และ 10.30.0.0/24 สำหรับสาขาที่สอง
2. เผื่อที่สำหรับการเติบโต ช่วงเล็กที่ใช้หมดภายหลังบังคับให้ต้องกำหนดเลขใหม่อย่างเจ็บปวด
3. เก็บตารางช่วงที่อยู่ง่าย ๆ ไว้ในเอกสาร และอัปเดตเมื่อมีอะไรเปลี่ยน
4. หลีกเลี่ยงช่วงที่เราเตอร์ตามบ้านใช้เป็นค่าเริ่มต้น เพราะพนักงานอาจใช้ Remote Access VPN จากบ้านและชนกับมัน
5. ถ้ามีการซ้อนอยู่แล้ว การแปลที่อยู่ที่เกตเวย์ช่วยแมปช่วงของสถานที่หนึ่งไปเป็นอีกช่วงได้ แต่เพิ่มความซับซ้อน การกำหนดเลขใหม่ให้สถานที่หนึ่งมักสะอาดกว่าถ้าไหว

จะเกิดอะไรเมื่อบางอย่างล้มเหลว

อุโมงค์ที่ส่งข้อมูลระบบบัญชีของคุณเป็นส่วนหนึ่งของโครงสร้างพื้นฐานสำคัญ จึงควรวางแผนรับมือความล้มเหลว

• อินเทอร์เน็ตขัดข้องที่สถานที่หนึ่ง อุโมงค์หลุด พนักงานที่นั่นเข้าระบบระยะไกลไม่ได้ อินเทอร์เน็ตเส้นที่สอง แม้จะเล็ก ช่วยฟื้นได้ เกตเวย์ที่รองรับสองช่องทางออกจะสลับเองอัตโนมัติ
• เกตเวย์เสีย อุปกรณ์สำรองหรือเกตเวย์คู่ในโหมดความพร้อมใช้งานสูงช่วยให้อุโมงค์ยังอยู่
• Dead peer detection เกตเวย์ตรวจว่าอีกฝั่งยังมีชีวิตอยู่ และสร้างอุโมงค์ใหม่เมื่อไม่ใช่ ตรวจให้แน่ใจว่าเปิดใช้งานอยู่
• กุญแจหรือใบรับรองหมดอายุ อุโมงค์อาจหยุดตอนเที่ยงคืนเพียงเพราะใบรับรองหมดอายุ ใส่วันหมดอายุไว้ในปฏิทิน
• ปัญหา MTU แพ็กเก็ตที่เข้ารหัสใหญ่ขึ้นเล็กน้อย ถ้าเกินที่เส้นทางรับได้ บางข้อมูลผ่านและบางข้อมูลค้างอย่างลึกลับ บทความ ปัญหา MTU ของ VPN อธิบายอาการ และ RFC 1191 อธิบายกลไกเส้นทางเบื้องหลัง
• การเฝ้าติดตาม การตรวจง่าย ๆ ที่ ping ระบบฝั่งตรงข้ามอุโมงค์ทุกนาทีและแจ้งเตือนคนดูแล ให้สัญญาณเตือนล่วงหน้า

กรณีใช้งานทั่วไป

กรณีใช้งาน	อุโมงค์ทำอะไร	ทำไม Site-to-Site VPN เหมาะ
สำนักงานใหญ่และสาขา	ให้สาขาเข้าไฟล์ร่วม ระบบบัญชี และระบบโทรศัพท์	ระบบส่วนกลางชุดเดียว ไม่เปิดสู่อินเทอร์เน็ต
โกดังหรือโรงงาน	เชื่อมเครื่องจักรและระบบสต็อกกับสำนักงานหลัก	อุปกรณ์ที่ลงซอฟต์แวร์ VPN ไม่ได้ก็ยังเชื่อมต่อได้
ร้านค้าและ POS	เชื่อมเครื่องคิดเงินกับฐานข้อมูลกลางหรือเกตเวย์ชำระเงิน	ไซต์เล็กเหมือนกันหลายแห่ง การรับส่งข้อมูลคาดเดาได้
ย้ายขึ้นคลาวด์	เชื่อมออฟฟิศกับเครือข่ายเสมือนในบริการคลาวด์	เซิร์ฟเวอร์บนคลาวด์ดูเหมือนเครือข่ายภายใน
การควบรวมและพันธมิตร	ให้สององค์กรมีลิงก์แคบไปยังระบบเฉพาะ	จำกัดการเข้าถึงให้เฉพาะระบบที่จำเป็นได้
สำรองข้อมูลและทำสำเนา	ย้ายข้อมูลไปสถานที่ที่สองทุกคืน	สำเนาเข้ารหัสไปยังอีกที่หนึ่ง

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

สามสถานการณ์

กลุ่มคลินิก สถานพยาบาลมีคลินิกหลักและคลินิกสาขาสองแห่ง เวชระเบียนผู้ป่วยอยู่ที่เซิร์ฟเวอร์ในคลินิกหลัก แต่ละสาขามีไฟร์วอลล์ที่สร้างอุโมงค์ไปยังคลินิกหลักแบบ hub-and-spoke พนักงานที่สาขาเปิดระบบเวชระเบียนได้เหมือนเป็นเครื่องในพื้นที่ เกตเวย์ยังจำกัดว่าอุปกรณ์ใดเข้าเซิร์ฟเวอร์เวชระเบียนได้ ทำให้โน้ตบุ๊กของแขกที่ห้องรอเข้าไม่ได้ เมื่อสาขาหนึ่งสายไฟเบอร์ขาด ไฟร์วอลล์สลับไปใช้เน็ตมือถือสำรอง และอุโมงค์กลับมาภายในหนึ่งนาที

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

โรงงานเล็กที่เช่าหน่วยที่สอง ช่างฝีมือเช่าโรงงานที่สองอีกฝั่งเมือง เขาต้องการรายการสต็อกและเครื่องพิมพ์ร่วมที่หน่วยแรก เราเตอร์เล็กคู่หนึ่งกับอุโมงค์ point-to-point ทำงานนี้ได้ เนื่องจากผู้ให้บริการอินเทอร์เน็ตของที่สองใช้ที่อยู่ร่วมกัน เราเตอร์ตัวหนึ่งจึงรับการเชื่อมต่อขาเข้าไม่ได้ จึงตั้งให้สถานที่ที่สองเป็นฝ่ายเริ่มอุโมงค์เสมอ บทความ VPN กับ CGNAT อธิบายว่าทำไมจึงเป็นเช่นนั้น

ข้อผิดพลาดที่ควรเลี่ยง

• ใช้ช่วง IP ส่วนตัวเดียวกันที่สองสถานที่
• ใช้รหัสผ่านร่วมที่อ่อนแอเส้นเดียวกับทุกอุโมงค์
• เปิดอุโมงค์ให้ทั้งเครือข่ายทั้งที่ต้องการแค่หนึ่งหรือสองระบบ
• ลืมกฎไฟร์วอลล์ภายในอุโมงค์ อุโมงค์คือข้อมูลที่เชื่อถือได้ เว้นแต่คุณกรอง
• ข้ามการเฝ้าติดตาม ทำให้สัญญาณแรกว่าอุโมงค์เสียคือโทรศัพท์จากพนักงาน
• ใช้เฟิร์มแวร์เกตเวย์เก่า เกตเวย์หันหน้าสู่อินเทอร์เน็ตและเป็นเป้าหมายบ่อย
• สร้าง full mesh สำหรับหกสถานที่โดยไม่มีแผนจัดการอุโมงค์
• ใช้อุโมงค์แทนการควบคุมการเข้าถึงรายบุคคล Site-to-Site VPN เชื่อใจเครือข่าย จึงควรเพิ่มการควบคุมที่เข้มขึ้น ซึ่งอยู่ในหัวข้อ Zero Trust เทียบกับ VPN

สรุป

Site-to-Site VPN เชื่อมทั้งเครือข่ายผ่านอุโมงค์เข้ารหัสที่สร้างระหว่างเกตเวย์ โดยมากใช้ IPsec และ IKEv2 พนักงานและอุปกรณ์ไม่ต้องรันซอฟต์แวร์ VPN ความสำเร็จขึ้นกับการวางแผน ช่วงที่อยู่ที่ไม่ซ้ำกัน รูปแบบที่ตรงกับการรับส่งข้อมูลจริง การออกแบบแบบ route-based เพื่อรองรับการเติบโต กฎที่แคบ อินเทอร์เน็ตเส้นที่สองสำหรับสถานที่สำคัญ และการเฝ้าติดตามที่บอกเมื่ออุโมงค์ล่ม มันปกป้องลิงก์ระหว่างสถานที่ ไม่ใช่สิ่งที่เกิดภายในเครือข่ายแต่ละแห่ง ดังนั้นต้องรักษาความปลอดภัยส่วนอื่นไว้

หากต้องการเครื่องมือส่วนตัวสำหรับอุปกรณ์ของคุณเองเมื่อเดินทางด้วย หน้าราคา แสดงตัวเลือกแบบเติมเงินง่าย ๆ สำหรับบุคคล