SOPHOS FIREWALL: VPN AND SD-WAN ZERO DOWNTIME FAILOVER

Tổng quan

Bài viết này sẽ mô tả cách thực hành tốt nhất để xây dựng khả năng kết nối giữa nhiều kết nối với các phương pháp failover cao và tiếp cận zero downtime, đồng thời đi kèm với ví dụ và tình huống thực tế.

Chúng tôi đang mở rộng về các tính năng mới và cũ của SFOS (Sophos Firewall OS) và cách sử dụng chúng để hiện đại hóa kết nối mạng. Hướng dẫn này cung cấp một hướng dẫn về cách xây dựng và mở rộng mạng riêng của bạn. Cấu hình có thể thay đổi tùy thuộc vào cấu hình cụ thể của bạn.

Tất cả các bước trong hướng dẫn này đều có thể được tự động hóa bằng Sophos Central Orchestration trong trường hợp triển khai lớn hơn. Vì lý do tùy chỉnh và học hỏi, chúng tôi muốn đặc biệt làm nổi bật toàn bộ cấu hình trong hướng dẫn.

1.Sản phẩm và điều kiện tiên quyết

Quyền read-write trên giao diện quản trị web của SFOS cho các tính năng liên quan.
Phiên bản 19.5 trở lên và không yêu cầu đăng ký riêng biệt.
Phiên bản 20 đã được sử dụng trong hướng dẫn sau đây.

2.Sơ đồ mạng

Để mô tả sơ đồ mạng và các tính năng đang hoạt động, chúng tôi xây dựng một ví dụ mạng.

Wiesbaden là trụ sở chính (HQ – Headquarters) của chúng tôi với kết nối Dual WAN.
Berlin và Hamburg là các chi nhánh của chúng tôi với một kết nối WAN duy nhất.
Chúng tôi sử dụng một cấu trúc mạng hình sao, và tất cả các địa điểm kết nối đến trụ sở chính.

Ngoài ra, chúng tôi đang kết nối đến Third-Party VPN Site, điều này là trách nhiệm của chúng tôi.

Best Practice: Sử dụng location name làm hostname cho thiết bị SFOS để phân biệt web admin console trong khi cấu hình.

Lưu ý: Trên các ảnh chụp màn hình sau đây, chúng tôi đang di chuyển giữa Wiesbaden và Hamburg. Hostname sẽ được hiển thị ở góc phải trên cùng.

3.Cấu hình

VPN

Mục tiêu của chúng tôi trong phần VPN là tận dụng đầy đủ cả hai kết nối WAN.

Chúng tôi sẽ sử dụng phương pháp Route Based VPN với XFRM interface để tận dụng 4 tunnel. Mỗi địa điểm sẽ xây dựng lên 2 tunnel.

Ví dụ, chúng ta sẽ đi qua quá trình cấu hình của một trong những tunnel.

Để thuận tiện trong triển khai, chúng tôi đang xây dựng các tunnel trên cả hai đầu đồng thời, do đó chúng ta có thể copy/paste cấu hình giữa mỗi Firewall và tránh bất kỳ lỗi nào.

Chúng tôi đang sử dụng Route Based VPN Tunnel (được gọi là XFRM hoặc Tunnel Interface).

Wiesbaden là trụ sở chính và ở chế độ (Respond only).
Các Profile đã được định nghĩa là IKEv2 (Internet Key Exchange Protocol Version 2) và có thể được chọn trên mọi cài đặt SFOS.
Authentication Type là RSA Key được xác định bởi tunnel, Vì RSA Key cung cấp cấp hình nhanh chóng thông qua copy/paste và không yêu cầu quản lý external key.

Ở Hamburg, chúng tôi khởi tạo kết nối và chọn các cài đặt tương tự.

RSA Key được xác định mặc định từ từng thiết bị riêng lẻ và mong đợi remote key từ thiết bị đối tác.

Phần cuối cùng là sự kết hợp giữa cổng liệt kê trên thiết bị local và (remote) gateway address.

Interface được liệt kê là WAN interface trên tường lửa cục bộ, chúng tôi sẽ chọn cho tunnel này là WAN1 (Fiber). Gateway address cho WAN IP / FQDN của vị trí remote (WAN1 của Hamburg).

Lưu ý: Chúng tôi đang sử dụng DNS hostname cho các remote peer. Dựa trên cài đặt của bạn, bạn có thể có các IP WAN khác nhau (Static IP or Dynamic DNS).

Best Practice: Bạn cũng có thể dùng bản ghi Dynamic DNS cho Gateway address hoặc một Wildcard (*) trong trường hợp bạn có một dynamic peer.

Ngoài ra, chúng tôi chỉ định loại Local ID là DNS và đặt tên chính xác cho cả hai. Điều này giúp xác định các tunnel. Bước này không bắt buộc nhưng được khuyến khích.

Chúng tôi sẽ thực hiện điều này bốn lần cho bốn tunnel tại trụ sở chính và hai lần ở mỗi địa điểm.

Để xác nhận điều này, chúng ta có thể kiểm tra trạng thái của tunnel trong phần tổng quan IPsec bằng cách điều hướng đến CONFIGURE>Site-to-site VPN>Tab IPsec.

Trụ sở chính

Vị trí Site riêng biệt

Đề xuất mapping XFRM Interface

Các XFRM Interface giống như một sợi cáp dài giữa hai thiết bị, và cả hai đầu của tunnel đều yêu cầu một địa chỉ IP.

Bạn không nên tái sử dụng cùng một dải mạng trên nhiều tunnel.
Cần phải thực hiện phân đoạn.

Một cách tiếp cận phổ biến là chia một subnet /24 thành nhiều subnet /30 như sau:

Đường hầm 1: 10.252.0.1/30 + 10.252.0.2/30
Đường hầm 2: 10.252.0.5/30 + 10.252.0.6/30
Đường hầm 3: 10.252.0.9/30 + 10.252.0.10/30
[…]
Đường hầm 64: 10.252.0.253/30 + 10.252.0.254/30

Cách tiếp cận này không đòi hỏi nhiều kế hoạch, nhưng nó khó nhận biết interface chính xác khi gặp sự cố.

Một cách tiếp cận thay thế trong hướng dẫn này là tạo các phân đoạn có thể đọc được cho mỗi tunnel. Chúng tôi gán cho mỗi tunnel một nhiệm vụ riêng.

XFRM Interface

Route Based Tunnel (Tunnel Interface) tạo ra một XFRM Tunnel interface. Trong Configuration >Network >Interfaces bạn sẽ thấy XFRM Interface dưới mỗi WAN Interface.

Lưu ý: bạn có thể click vào line màu xanh để mở rộng WAN Interface.

XFRM Interface là các mạng transfer. Bạn cần một địa chỉ IP ở cả hai đầu của tunnel, và nó phải ở trong cùng một phạm vi subnet.

Best Practice: Để có khả năng quan sát tốt hơn, tên XFRM Interface có thể khớp với tên tunnel.

Chúng tôi mạnh mẽ khuyến khích bạn thiết lập một kế hoạch chi tiết cho XFRM Interface.

Có nhiều cách tiếp cận để thực hiện cài đặt này, và cách tiếp cận của chúng tôi có thể chỉ là một ý tưởng và không phù hợp với cài đặt của bạn. Bạn nên bố trí mapping XFRM Interface trước khi bắt đầu cấu hình để tránh cấu hình sai.

SD-WAN gateway

Với các tunnel IPsec đã được thiết lập, chúng tôi muốn route traffic thông qua những tunnel đó.

Đối với routing, chúng tôi có nhiều cách tiếp cận như sau:

Static Routing
Dynamic Routing
SD-WAN Routing

Để xây dựng khả năng hoạt động liên tục và tận dụng cao của tất cả các WAN interface, chúng tôi quyết định sử dụng các đường tuyến SD-WAN.

Sẽ cần thiết lập sau đây:

Gateway
SD-WAN Profiles
SD-WAN Route

Sẽ cần một Gateway cho mỗi tunnel XFRM.

Chúng tôi chọn XFRM Interface mà chúng tôi muốn sử dụng và địa chỉ peer gateway IP.

Trong trường hợp này, interface là 10.20.10.1 và địa chỉ peer gateway IP là 10.20.10.2.

Bằng cách chọn Interface, dễ dàng xác định địa chỉ IP Local.
Sử dụng một bản gán XFRM /30, chúng ta có thể xác định địa chỉ IP tiếp theo sẽ là gateway.

SD-WAN profiles

Các Profile SD-WAN sẽ được tạo ra cho mỗi vị trí mà bạn muốn thực hiện kết nối.

Trong các Profile SD-WAN, chúng tôi chọn tất cả các địa điểm có thể áp dụng và chọn “Load Balancing”.

Phương pháp Load Balancing quyết định khi nào SFOS nên chọn một VPN Tunnel cụ thể.

Bạn sẽ tìm thấy thêm thông tin về Load Balancing trong Phụ Lục.

Ví dụ của chúng tôi, chúng tôi thiết lập gateway weight là 1 và 1 điều này dẫn đến cân bằng tải 50% / 50%. Trong cài đặt của bạn, độ ưu tiên có thể khác nhau dựa trên công suất truyền thông hoặc các tiêu chí khác như chi phí.

SLA strategy có thể thay đổi trong cài đặt của bạn và có thể được tùy chỉnh nếu cần. Bạn có thể giữ lại tất cả các cài đặt mặc định hoặc tùy chỉnh dựa trên nhu cầu của bạn.

Chúng tôi đang sử dụng IP LAN địa điểm peer làm mục tiêu thăm dò (192.168.130.1 là LAN Port1 của Hamburg Site).

SD-WAN Routes

Bước cuối cùng của chúng tôi là làm cho mạng có thể truy cập được. Chúng tôi sử dụng SD-WAN Routes để xây dựng tuyến đường giữa các địa điểm của chúng tôi.

Chúng tôi đã tạo một SD-WAN Route cho mỗi vị trí để có thể truy cập được.

Trong SD-WAN Routes, chúng tôi sử dụng IP Host Group làm destination và để phần còn lại là ANY. Bạn có thể tùy chỉnh điều này nếu bạn chỉ muốn định tuyến cụ thể.

Best Practice: Bằng cách sử dụng IP Host Group, chúng tôi luôn đảm bảo rằng tất cả các dải mạng của tất cả các địa điểm được định tuyến đúng cách.

Best Practice: Chúng tôi đang xuất bản và duy trì những đối tượng đó thông qua Sophos Central Firewall Management. Các mạng Hamburg, mạng Berlin và mạng Wiesbaden được tự động xuất bản trên tất cả các tường lửa để đảm bảo các đường tuyến được xuất bản. Việc thay đổi đối tượng trong Central sẽ thay đổi cả đường tuyến.

Bạn cũng có thể sử dụng các đối tượng mạng; chúng tôi nhận thấy việc sử dụng IP host group đơn giản hơn và ít nhạy cảm với lỗi hơn.

Firewall Rules

Chúng tôi sử dụng các quy tắc VPN to LAN và LAN to VPN trong hướng dẫn này.

Bạn nên xây dựng khái niệm quy tắc tường lửa dựa trên nhu cầu bảo mật của mình.

4.Redundancy and Zero Downtime

Proof of Concept

Nếu 1 client từ Berlin cố gắng liên lạc với 1 client ở Hamburg, chúng ta có thể xem kết nối đó trong phần Diagnostic – Packet capture.

Ở Wiesbaden, bạn sẽ thấy các gói tin đến từ XFRM3, đi ra khỏi XFRM1 và phản hồi từ XFRM1 quay trở lại XFRM3.

Lưu ý: Packet capture hiển thị gói tin mới nhất ở trên cùng – để đọc kết nối, bạn sẽ bắt đầu với phiên cuối cùng.

Mạng WAN1 của chúng tôi bị lỗi ở Wiesbaden, dẫn đến 2/4 tunnel bị lỗi. Tuy nhiên, mọi thứ đều có thể truy cập được thông qua kết nối khác.

Zero Downtime failover

Thiết lập của chúng tôi mặc định hỗ trợ zero-downtime failover trong trường hợp kịch bản failover nói trên. Khách hàng của chúng tôi sẽ không phát hiện ra failover sang tunnel khác và tất cả các kết nối vẫn hoạt động.

Chúng ta cũng có thể thấy điều này trong quá trình packet capture.

Trước khi failover, chúng tôi đã sử dụng XFRM1 và XFRM3.

Sau khi failover SFOS tự động chuyển sang thiết lập XFRM4 và XFRM2.

Điều quan trọng cần chú ý: Các source port của kết nối vẫn giống nhau – client vẫn kết nối với server và không ngừng (hoặc xây dựng lại) kết nối.

Lưu ý: “IN Interface” trong packet capture trong trường hợp SD-WAN failover được phản ánh không chính xác trong web admin. Đây là một vấn đề đã biết và chỉ mang tính thẩm mỹ.

SFOS sẽ tự động chuyển về kết nối VPN cũ nếu WAN1 online. Source port vẫn không thay đổi.

5.Third Party VPN

Việc kết nối đến Third Party có thể thay đổi tùy thuộc vào sản phẩm được sử dụng và mức độ ảnh hưởng của sản phẩm đó đối với tunnel. Thông thường, khách hàng chỉ nhận được một bộ quy tắc chính sách để sử dụng.

Trong ví dụ của chúng tôi, bên Third Party yêu cầu chúng tôi thực hiện NAT cho mạng của mình trong tunnel (masquerade), và nó cung cấp một phạm vi mạng mà chúng tôi muốn đạt được. Ngoài ra, chúng tôi nhận được một bộ rule yêu cầu về IPsec để tuân theo. Phần này cũng được mô tả trong phụ lục.

Chúng tôi đang xây dựng với Tunnel loại Site-to-Site (Policy Based) và khởi tạo kết nối.

Ở trong Gateway Settings, chúng ta phải chỉ định local và remote subnet.

Dựa trên yêu cầu, chúng ta sử dụng “ThirdPartyNetwork” như được quy định bởi ThirdParty và sử dụng Translated IP yêu cầu trong Local Subnet. Để giảm độ phức tạp của hướng dẫn này, chúng tôi không cung cấp ví dụ về những địa chỉ IP đó.

Chúng ta cũng cần tạo một NAT Rule.

NAT nó sẽ translate mọi traffic đến ThirdPartyNetwork và MASQ lưu lượng truy cập sang Translated IP.

Như bước cuối cùng, chúng ta cần tạo một IPsec Route trên dòng lện (CLI) cho destination network.

Lệnh có thể là: system ipsec_route add net <remote subnet> tunnelname <ipsec_tunnel>

system ipsec_route add net 192.168.3.0/255.255.255.0 tunnelname ThirdPartyTunnel

Lưu ý: Bạn có thể sử dụng “TAB” để tự động hoàn thành.

ThirdPartyRessource hiện có thể truy cập được từ Wiesbaden. Để có thể truy cập tới Berlin/Hamburg, chúng tôi cần có SD-WAN Route bổ sung.

SD-WAN Route này sẽ route traffic đi đến ThirdPartyNetwork thông qua Wiesbaden đến ThirdParty.

6.Scalability

Hướng dẫn của chúng tôi phản ánh cách thiết lập nhỏ hơn với 2 địa điểm từ xa, và chúng tôi muốn xem xét các tùy chọn để mở rộng hệ thống này đến các mạng lớn hơn.

Các bước để kết nối một New Location

Tạo 1 new location bao gồm các bước cấu hình sau đây:

IPsec Tunnel trên cả 2 thiết bị
IPsec XFRM Interface trên cả 2 thiết bị
Gateway trên cả 2 thiết bị
SD-WAN Profile trên cả 2 thiết bị
SD-WAN Route trên cả 2 thiết bị

Sử dụng SD-WAN Orchestration trong Sophos Central

Sophos central với xStream Protection License hỗ trợ SD-WAN Orchestration và tạo ra tất cả các điểm trên cho tất cả các thiết bị được quản lý.

Bạn sẽ tìm thấy thêm thông tin ở đây: Sophos Firewall: Managing Firewall and SD-WAN Orchestration

Dynamic Routing

Trong triển khai mạng lớn hơn, các quản trị viên có thể muốn sử dụng dynamic Routing thay vì các tuyến SD-WAN. Các tuyến SD-WAN cung cấp một cách dễ dàng để triển khai latency, jitter và packet loss và quyết định định tuyến mà không cần phải có kinh nghiệm với chính giao thức định tuyến. Bạn có thể tìm thêm thông tin về dynamic routing trong phụ lục.

7.Phụ lục