Định tuyến một mạng con chi nhánh qua cổng ra Internet SonicWall của trụ sở chính

Điện thoại của chi nhánh nên đi ra qua trụ sở chính trong khi máy tính xách tay của chi nhánh tiếp tục dùng WAN cục bộ, và chỉ chính sách định tuyến sẽ không đáp ứng được điều đó. Một tuyến đường chi nhánh có thể chọn đường hầm, nhưng chính sách đường hầm phải chấp nhận lưu lượng, trụ sở chính phải chuyển tiếp và dịch nó, và phản hồi phải quay lại cùng đường. Thiếu bất kỳ điều nào trong ba điều đó và triệu chứng sẽ là một tập con máy khách mất Internet đúng trong lúc đường hầm đang hoạt động.

Bắt đầu từ bộ chọn, không phải tuyến đường

Chính sách định tuyến khớp theo nguồn, vì vậy nguồn phải ổn định trước mọi thứ khác. Đặt các thiết bị đã chọn vào một nhóm địa chỉ do quản trị viên duy trì hoặc, tốt hơn, trên một phân đoạn chuyên dụng mà tư cách thành viên theo vai trò của thiết bị. Khi vòng quay DHCP thông thường có thể chuyển một địa chỉ khớp sang máy khác, chính sách lặng lẽ chọn nhầm máy khách, và báo cáo đầu tiên thường là về duyệt web chậm mà thực ra là một đường vòng.

Đặt tên nhóm theo chính sách mà nó phục vụ, không theo tầng hay phòng ban, vì quy tắc định tuyến sẽ tồn tại lâu hơn cả hai. Ghi lại thiết bị nào nằm trong đó và ai được phép thêm một thiết bị.

Thêm chính sách chi nhánh, rồi bảo vệ thứ tự của nó

Trên SonicWall của chi nhánh, một chính sách tuyến đường chọn nhóm nguồn, đặt tên các đích dự định và đặt giao diện đường hầm làm cổng, và đó chính là mục đích của thiết kế giao diện đường hầm được hỗ trợ. Giữ các quy tắc cho đích cục bộ và riêng tư ở trên quy tắc Internet rộng, vì kết quả khớp đầu tiên thắng và một tiền tố riêng tư bị đẩy vào đường hầm chỉ đến trụ sở chính để bị bỏ đi. Cũng giữ tuyến đường của chính tường lửa tới đối tác VPN của nó, nếu không việc vận chuyển đường hầm sẽ theo chính sách mà nó phụ thuộc. Không điều nào trong số này buộc bạn phải chuyển đổi mọi đường hầm dựa trên chính sách hiện có; giao diện đường hầm là một lựa chọn được hỗ trợ trong số nhiều lựa chọn.

Thứ tự là phần thay đổi do tai nạn. Bất kỳ ai thêm ngoại lệ đều phải chèn nó lên trên quy tắc rộng, và bất kỳ ai sửa quy tắc rộng đều có thể đảo ngược toàn bộ thiết kế chỉ bằng một lần lưu. Viết thứ tự dự định bên cạnh chính sách và kiểm tra lại sau khi cập nhật firmware, vì cách đặt tên giao diện và hiển thị chính sách thực sự thay đổi giữa các bản phát hành.

Hoàn tất đường đi tại trụ sở chính

Chính sách đường hầm tại trụ sở chính phải chấp nhận lưu lượng mà tuyến đường chi nhánh hiện chọn. Một bộ chọn liên văn phòng giới hạn trong LAN riêng của trụ sở chính không phải là sự cho phép mang các đích công cộng tùy ý, nên chính sách cần nguồn của chi nhánh và dải đích mà bạn thực sự định. Sau đó trụ sở chính chuyển tiếp lưu lượng đến đó lên đường truyền Internet của mình theo các quy tắc truy cập riêng, và ví dụ về cổng ra trung tâm của SonicWall bao gồm việc dịch nguồn cho mạng từ xa tại WAN trung tâm. Không có bản dịch đó, phía xa sẽ thấy một địa chỉ chi nhánh riêng tư và không có tuyến đường quay lại.

Các phản hồi là nửa còn lại của hợp đồng. Chúng phải quay lại qua đường hầm hoặc qua bản dịch có trạng thái được tạo cho chúng, và lưu lượng đến các trang riêng tư có thể cần xử lý NAT khác với cổng ra công cộng. Giữ các quy tắc đó có thể phân biệt được, vì một quy tắc dịch rộng che giấu mọi nguồn nội bộ sẽ làm cho việc ghi nhật ký và khắc phục sự cố sau này khó đọc hơn nhiều.

Quyết định nhóm làm gì khi đường hầm sập

Nếu cổng ra trung tâm là yêu cầu chứ không phải tùy chọn, quay về WAN cục bộ là một thất bại về tuân thủ ngay cả khi người dùng vẫn trực tuyến. SonicOS ghi nhận một tuyến đường bỏ giao diện đường hầm là cách được hỗ trợ để ngăn lưu lượng đã chọn đi theo một đường thay thế không mong muốn.

Khớp phạm vi và mức ưu tiên của tuyến đường đó với bản phát hành đã cài, và kiểm tra nó bằng cách hạ đường hầm thay vì tin vào nhãn. Một nhóm không bao giờ được ra ngoài cục bộ nên thất bại theo hướng đóng, trong khi một nhóm nơi tính sẵn sàng quan trọng hơn có thể quay lại một cách hợp lệ; cả hai đều là quyết định, và không cái nào nên xảy ra theo mặc định.

Xác minh từ ba máy khách, rồi khôi phục sạch sẽ

Ping tới cổng trung tâm kiểm tra sai thứ, vì nó xuất phát từ tường lửa chứ không phải từ một máy khách đã chọn. Hãy kiểm tra từ các thiết bị, và kiểm tra ba trong số chúng: một thiết bị đã chọn, một thiết bị thông thường nên ở lại cục bộ, và một thiết bị phụ thuộc vào dịch vụ cục bộ.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

So sánh nơi yêu cầu công cộng thực sự xuất hiện. Một máy khách đã chọn nên đến Internet qua cổng ra của trụ sở chính, và một máy khách thông thường vẫn nên hiển thị địa chỉ riêng của chi nhánh ở phía xa; 203.0.113.10 là một địa chỉ tài liệu được dùng làm đại diện cho đích mà bạn quan tâm. Đưa DNS vào cùng lượt, vì một máy khách hỏi bộ phân giải của chi nhánh có thể tạo ra một tìm kiếm bắt nguồn từ bộ định tuyến với nguồn khác và do đó tuyến đường khác.

Khôi phục là thứ tự chính sách đã lưu cộng với nhóm địa chỉ. Khôi phục thứ tự trước đó, gỡ nhóm khỏi chính sách, và kiểm tra lại cả hai lớp thiết bị. Giữ cấu hình đã xuất cùng với bản ghi thay đổi, vì kỹ sư tiếp theo cần biết quy tắc nào là rộng trước khi ai đó sửa nó.