การขยายไซต์ VPN: ตามเส้นทางขากลับเลยเกตเวย์ไป

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

เกตเวย์ไกลเป็นจุดปลายของการเข้ารหัส

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

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

อ่านนโยบายอุโมงค์ทั้งสองทิศทาง

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

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

เพิ่มเส้นทางขาไปและยืนยันการอนุญาต

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

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

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

ทดสอบจากสาขา แล้วทดสอบเส้นทางเก่าซ้ำ

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

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

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