Mở rộng site VPN: theo tuyến trở về phía sau cổng

Lưu lượng từ một chi nhánh kết thúc tại một cổng mà LAN của nó không chứa ứng dụng bạn được yêu cầu truy cập. Máy chủ nằm ở trung tâm dữ liệu thứ hai, bên kia một liên kết nội bộ mà VPN chưa bao giờ cấu hình. Thêm một tiền tố nữa vào cổng gần không làm gì cho trường hợp đó, vì cổng xa là điểm cuối mã hóa chứ không phải bộ định tuyến cuối cùng. Đường đi cần một tuyến đi tới, một sự chấp nhận ở biên bảo mật xa và một quyết định trở về ngay trong mạng của đích đến.

Cổng xa là một điểm cuối mã hóa

IPsec giữa các cổng bảo vệ lưu lượng giữa hai thiết bị bảo mật, và các địa chỉ bên trong đi qua đoạn đó dưới dạng mã hóa. Bên kia cổng xa, định tuyến thông thường tiếp quản, bao gồm mọi chính sách tồn tại giữa các trung tâm dữ liệu. Vì vậy đoạn được bảo vệ chỉ bao phủ một phần hành trình chứ không phải phần còn lại. Giả định ngược lại là cách một thiết kế kết thúc với một đường hầm khỏe mạnh và một ứng dụng không thể truy cập.

Vẽ đường đi thành ba phần: chi nhánh đến cổng gần, gần đến cổng xa, cổng xa đến ứng dụng. Mỗi phần có chủ sở hữu riêng và kiểu hỏng riêng.

Đọc cả hai chiều của chính sách đường hầm

Chính sách đường hầm thường được viết từ góc nhìn của phía cục bộ, và chính thói quen đó tạo ra các cấu hình một phần. Cả hai bên phải liệt kê nguồn của chi nhánh và đích đến như chúng sẽ xuất hiện bên trong đường hầm, kể cả mọi phép dịch mà thiết kế dự định. Chỉ cập nhật đầu gần tạo ra sự không khớp pha hai trông giống như lỗi định tuyến. Hãy so sánh hai bộ chính sách trước khi chạm vào bất kỳ tuyến nào.

Viết nguồn và đích đến dưới dạng địa chỉ thay vì tên site. Sự mơ hồ ở đây sẽ quay lại sau đó như một bất đối xứng khó hiểu.

Thêm tuyến đi tới và xác nhận sự chấp nhận

Cổng xa cần một tuyến tới mạng con của ứng dụng, và mọi bộ định tuyến giữa chúng phải chấp nhận nguồn của chi nhánh. Hãy kiểm chứng điều cổng xa thực sự có thay vì điều sơ đồ khẳng định.

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

Lệnh đầu tiên báo cáo giao diện ra và bước nhảy tiếp theo mà cổng xa sẽ chọn cho nguồn đó, một câu hỏi mà bảng định tuyến thông thường không thể trả lời. Dấu vết cho thấy gói dừng ở đâu, và sự đứt gãy sau cổng xa chỉ vào phần trung chuyển nội bộ chứ không phải đường hầm. Khi tuyến tồn tại mà lưu lượng vẫn biến mất, hãy bắt gói trên cổng xa và đọc địa chỉ nguồn đến, vì một địa chỉ bất ngờ nghĩa là việc dịch đang diễn ra ở đâu đó không có kế hoạch. Mọi địa chỉ ở đây là phần giữ chỗ, nên hãy thay bằng mạng con thật của chi nhánh, trung chuyển và ứng dụng.

Kiểm tra từ chi nhánh, rồi kiểm tra lại tuyến cũ

Việc chấp nhận cần một nguồn thật thay vì một phép dò từ cổng xa. Chạy kiểm tra từ một máy chủ trong chi nhánh và giữ các đích từng hoạt động trong cùng bài kiểm tra.

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

Phản hồi từ ứng dụng chứng minh cả tuyến đi tới và đường trở về cùng lúc, trong khi ping đến đích cũ chứng minh thay đổi không phá vỡ thứ đã hoạt động. Ghi lại địa chỉ nguồn mà ứng dụng ghi log, vì các quy tắc truy cập và mọi tuyến trở về phải khớp với giá trị đó. Ở nơi chi nhánh dịch trước đường hầm, địa chỉ trong chính sách và địa chỉ mà ứng dụng thấy khác nhau theo thiết kế, nên hãy ghi cả hai. Lặp lại bài kiểm tra sau khi đổi khóa hoặc thay đổi định tuyến, vì những tuyến này thường được xác thực một lần rồi bị lãng quên.

Giao một chủ sở hữu cho mỗi đoạn trong ba đoạn và cho tuyến trở về bên trong mạng đích. Một đường đi với bốn chủ sở hữu thất bại ở những khoảng trống giữa họ.