FortiGate sau NAT: local-gw, localid và IP công khai

Một FortiGate sau NAT có thể sở hữu 10.0.0.2 trên giao diện WAN của nó trong khi internet hiển thị nó là 198.51.100.40, và cả hai con số đều có thật. Địa chỉ mà thiết bị gắn vào và danh tính mà nó gửi trong quá trình xác thực IKE là những lựa chọn riêng biệt, được thực hiện trong các trường riêng biệt, cho các đối tượng riêng biệt. NAT viết lại địa chỉ bên ngoài trên đường đi; nó không viết lại một danh tính đã xác thực thành những gì peer ở xa mong đợi. Hầu hết các lỗi pha 1 ở dạng này đến từ việc đặt giá trị đúng vào trường sai.

Ba giá trị, ba chủ sở hữu

Bắt đầu bằng việc gọi tên ba giá trị và ai sở hữu mỗi giá trị. local-gw là địa chỉ mà FortiGate dùng làm nguồn cho IKE trên giao diện bên ngoài, và nó phải là địa chỉ mà thiết bị thực sự có. Điểm cuối công khai là địa chỉ của thiết bị NAT, thuộc về bên thực hiện việc dịch. Danh tính IKE là một chuỗi mà peer so sánh với cấu hình của chính nó, và nó không nhất thiết phải là địa chỉ IP.

Tên các trường đủ gần nhau để mời gọi sự thay thế, và đó chính là cái bẫy. localid và localid-type mô tả việc nhận dạng; local-gw mô tả việc ràng buộc cục bộ.

Một ví dụ làm cho sự khác biệt trở nên cụ thể. Trên FortiGate, mở config vpn ipsec phase1-interface, sau đó set interface "wan1" và set local-gw 10.0.0.2 — địa chỉ mà hộp sở hữu, và chính điều này giúp socket IKE ràng buộc thành công. Để local-gw ở 0.0.0.0 thì địa chỉ giao diện được dùng, thường là cùng một thứ nhưng kém tường minh hơn. Đừng đặt local-gw thành 198.51.100.40, vì thiết bị không sở hữu địa chỉ đó và socket sẽ không ràng buộc vào nó. Làm cho hai giá trị trông bằng nhau trên giấy không phải là cấu hình.

Bước 1: chọn danh tính mà peer sẽ chấp nhận

Bây giờ là danh tính, một quyết định khác. set localid lấy giá trị mà peer sẽ so sánh, và set localid-type cho FortiGate biết cách diễn giải nó: một địa chỉ, một FQDN, FQDN người dùng hoặc ID khóa. Với auto thiết bị suy ra nó, thường từ địa chỉ của giao diện đi ra, đúng là giá trị mà thiết bị NAT sắp thay đổi.

Chính cách suy ra đó là lý do danh tính tường minh quan trọng trong cấu trúc liên kết này. Nếu peer mong đợi danh tính địa chỉ, hãy đặt localid-type address và localid thành địa chỉ công khai mà peer sẽ thấy, sau đó xác nhận rằng peer chấp nhận giá trị đó như một danh tính chứ không phải đích định tuyến. Nếu peer mong đợi FQDN, hãy dùng localid-type fqdn và tên mà nó được cấu hình. Kiểm tra những gì thực sự được gửi bằng diagnose vpn ike gateway list, lệnh này hiển thị trạng thái cổng và các định danh đang dùng, không phải những gì bạn định gõ. Đừng cho rằng một tùy chọn loại danh tính chấp nhận địa chỉ không cục bộ tùy ý; trước tiên hãy kiểm tra ngữ nghĩa được ghi trong tài liệu của bản phát hành.

Bước 2: chuyển tiếp UDP 500 và 4500 tới thiết bị

Giá trị thứ ba thuộc về thiết bị NAT, và đó là giá trị mà mọi người quên kiểm tra. Điểm cuối công khai phải chuyển tiếp UDP 500 và UDP 4500 tới FortiGate, vì việc phát hiện NAT-T và ESP đóng gói theo sau đều phụ thuộc vào việc các cổng đó đến. Thiết kế này giả định ánh xạ một-một; chia sẻ một địa chỉ công khai theo cổng giữa nhiều peer là một cấu trúc liên kết khác với các giới hạn khác.

Xác nhận việc chuyển tiếp bằng một lần bắt gói chứ không phải bằng hy vọng: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 cho thấy gói có đến hay không và phản hồi có đi ra hay không.

Google Cloud VPN ghi nhận NAT một-một với NAT-T là cách bố trí được hỗ trợ cho peer sau NAT, và đó là ràng buộc cần thiết kế theo nếu đầu xa là một cổng Cloud VPN. Chia sẻ một-nhiều hoặc theo cổng không phải là cùng cấu trúc liên kết được hỗ trợ, và không mức tinh chỉnh danh tính cục bộ nào thay đổi điều đó. Nếu phía xa là thiết bị khác, tài liệu của chính nó xác định nó sẽ chấp nhận gì làm danh tính và có chịu được địa chỉ peer đã dịch hay không. Hãy đọc điều đó trước khi thay đổi một trường cục bộ, vì phía cục bộ không thể thương lượng một quy tắc mà phía xa không triển khai.

Bước 3: kiểm tra những gì pha 1 không giải quyết

Việc đi qua NAT đưa đường hầm lên, sự đồng thuận về danh tính quyết định peer có chấp nhận hay không, và định tuyến tiền tố bên trong quyết định cái gì thực sự đi qua. Một ID cục bộ đúng không thể cung cấp một tuyến tĩnh còn thiếu hay một bộ chọn lưu lượng còn thiếu.

Vì vậy hãy kiểm tra theo lớp. get vpn ipsec tunnel details cho thấy đường hầm có lên hay không và những bộ chọn nào đã được thương lượng, và sự không khớp giữa mạng con xa đã cấu hình với bộ chọn đã thương lượng là một vấn đề định tuyến trong bộ đồ pha 2. execute vpn ike gateway clear buộc thương lượng lại, nên bạn đang kiểm tra cấu hình hiện tại chứ không phải một phiên được thiết lập trước lần thay đổi cuối của bạn. Sau đó gửi lưu lượng tới một máy trong tiền tố xa và xác nhận các bộ đếm di chuyển, vì một đường hầm đang lên mà không cho gì đi qua trông giống hệt một đường hầm hoạt động cho đến khi bạn kiểm tra.

Giữ ba giá trị ở một chỗ trong ghi chú của bạn: địa chỉ cục bộ mà thiết bị sở hữu, điểm cuối công khai mà thiết bị NAT trình bày và chuỗi danh tính mà peer mong đợi. Chúng thay đổi vì những lý do khác nhau và vào những thời điểm khác nhau.

Việc đánh số lại thiết bị NAT không phải lý do để chạm vào local-gw của FortiGate, và việc thay đổi danh tính không phải lý do để đánh số lại bất cứ thứ gì. Trộn lẫn hai điều đó là cách một đường hầm đang hoạt động bị dựng lại trong một cửa sổ bảo trì không liên quan. Hướng dẫn NAT của Cloud VPN là tài liệu tham chiếu cho cấu trúc liên kết được hỗ trợ ở phía đó.

Bài kiểm tra phân định là nhàm chán và nhanh: bắt gói trên giao diện bên ngoài, xác nhận UDP 500 và 4500 đến từ peer, xác nhận danh tính trong trao đổi IKE khớp với những gì peer được cấu hình để mong đợi, rồi xác nhận các bộ chọn đã thương lượng bao phủ các mạng con bạn quan tâm. Nếu kiểm tra đầu tiên thất bại, nghi phạm là thiết bị NAT. Nếu kiểm tra thứ hai, đó là các trường danh tính. Nếu kiểm tra thứ ba, thì cả NAT lẫn danh tính chưa bao giờ là vấn đề.