SoftEther SecureNAT: DHCP và NAT là hai quyết định

SecureNAT là một ô đánh dấu duy nhất bật hai dịch vụ, và đó là nguồn gốc của phần lớn sự nhầm lẫn về nó. Một máy chủ DHCP ảo cấp cho máy khách địa chỉ, mặt nạ, cổng và thường là một trình phân giải. Một NAT ảo chuyển tiếp gói ra ngoài cổng đó bằng chính ngăn xếp mạng của máy chủ. Hai thứ nằm cạnh nhau trong cấu hình và hỏng độc lập: máy khách có thể có bản cấp phát hoàn hảo mà không có đường hoạt động, hoặc có đường hoạt động với thiết lập trỏ tới trình phân giải sai. Kiểm tra chúng như hai quyết định, và chẩn đoán trở nên ngắn gọn.

Hai dịch vụ sau một ô đánh dấu

Phía DHCP ảo trả lời một câu hỏi cấu hình: máy khách này nhận thiết lập nào bên trong hub ảo này. Phía NAT ảo trả lời một câu hỏi chuyển tiếp: khi máy khách gửi gói tới địa chỉ ngoài hub, máy chủ có dịch và chuyển tiếp nó không. Cái thứ nhất là cục bộ với hub và không cần mạng phía trên. Cái thứ hai phụ thuộc hoàn toàn vào máy chủ.

Giao diện máy chủ ảo thuộc quyết định thứ nhất, không phải thứ hai. Địa chỉ của nó, thường mặc định là thứ như 192.168.30.1, là cổng mà dịch vụ DHCP cung cấp. Đó không phải địa chỉ lắng nghe công khai của máy chủ, và nhầm lẫn hai thứ tạo ra quy tắc tường lửa và thiết lập máy khách nhắm tới một máy không tồn tại trên mạng đó.

Quyết định 1: ai cấp địa chỉ

Nếu DHCP ảo được bật, máy khách nên nhận bản cấp phát trong vùng bạn đã cấu hình, với giao diện máy chủ ảo làm cổng và trình phân giải bạn đã cung cấp. Xem bản cấp phát chứ không phải văn bản trạng thái của máy khách, vì «đã kết nối» mô tả đường hầm chứ không phải việc gán địa chỉ:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Có hai kiểu hỏng đáng biết trước khi gỡ lỗi bất cứ điều gì khác. Máy khách còn địa chỉ tĩnh sót lại từ thiết kế trước sẽ giữ nó và bỏ qua bản cấp phát, trông như DHCP từ chối trả lời. Và nguồn DHCP thứ hai trên một đoạn có cầu sẽ tranh nhau cùng những máy khách đó, sinh ra địa chỉ chập chờn và một hàng đợi hỗ trợ không thể tái hiện vấn đề.

Các vùng chồng lấn cũng thuộc đây. Nếu vùng DHCP ảo chồng lên mạng con LAN của máy chủ hoặc vùng của hub khác, máy khách nhận địa chỉ được định tuyến mơ hồ, và mọi bài kiểm tra sau đó đều không kết luận được.

Quyết định 2: ai chuyển tiếp ra ngoài cổng ảo

Khi NAT ảo được bật, lưu lượng đi ra khỏi hub được máy chủ dịch và gửi qua bảng định tuyến của máy chủ. Nghĩa là chuỗi chuyển tiếp là: máy khách tới cổng ảo, NAT ảo tới ngăn xếp máy chủ, ngăn xếp máy chủ tới tuyến mặc định của nó. Mỗi mắt xích có thể hỏng mà không chạm vào các mắt khác, và dấu hiệu hỏng khác nhau.

Hãy thử quyết định thứ hai bằng thứ gì đó buộc phải rời hub, không phải bằng thứ cục bộ trong hub. Ping cổng ảo chỉ chứng minh mắt xích đầu tiên và không hơn:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Nếu phân giải tên hoạt động nhưng kết nối tới địa chỉ công cộng thất bại, bạn đang ở chuỗi chuyển tiếp chứ không phải DHCP. Nếu cả hai đều thất bại, hãy kiểm tra trình phân giải trước, vì một trình phân giải được đẩy xuống như địa chỉ nội bộ không thể tới sẽ khiến đường đang hoạt động trông như hỏng hoàn toàn.

Việc chuyển tiếp của SecureNAT do tiến trình máy chủ thực hiện, không phải đường chuyển tiếp trong nhân mà bạn dùng với cầu. Điều đó tiện và chậm hơn làm cầu, và cũng có nghĩa là quy tắc tường lửa và quyết định định tuyến của chính máy chủ vẫn áp dụng cho lưu lượng đã dịch. NAT ảo không vượt qua chính sách của máy chủ; nó dùng chính sách đó.

Đường đi của chính máy chủ là thứ thứ ba

Mọi điều trên giả định máy chủ đích có thể tới đích. Một máy chủ không có tuyến trên hoạt động, có chính sách ra ngoài hạn chế, hoặc không có họ địa chỉ đó sẽ hỏng ở quyết định thứ hai, dù cấu hình hub đúng đến đâu. Hãy kiểm tra máy chủ riêng, ngoài đường hầm, trước khi quy lỗi của nó cho SoftEther.

SecureNAT cũng không phải sự cho phép tới mọi mạng gắn với máy chủ. Nó dịch và chuyển tiếp lưu lượng tới được nó; quyết định máy chủ được tới đâu vẫn là việc của tường lửa và định tuyến trên máy chủ, và một thiết kế dựa vào đường hầm để cấp quyền truy cập chỉ cách việc cấp quá nhiều đúng một quy tắc tồi.

Các họ địa chỉ đáng được kiểm tra riêng. Một ví dụ DHCP IPv4 hoạt động không chứng minh mọi khả năng IPv6 có trong bản dựng của bạn, nên hãy đọc hướng dẫn cho phiên bản bạn thực sự chạy trước khi hứa hẹn hành vi ngăn xếp kép. Phần SecureNAT trong hướng dẫn bao gồm các chức năng NAT và DHCP ảo cho bản phát hành hiện tại.

Kiểm tra từng quyết định bằng bài kiểm tra riêng của nó

Chấp nhận quyết định thứ nhất bằng kiểm tra bản cấp phát: địa chỉ trong vùng, cổng bằng giao diện máy chủ ảo, trình phân giải đúng cái bạn đã cấu hình. Chấp nhận quyết định thứ hai bằng một yêu cầu ra ngoài từ máy khách cùng một cái nhìn vào bảng NAT trên máy chủ, vì số phiên tăng lên là bằng chứng trực tiếp duy nhất rằng việc dịch đang diễn ra chứ không chỉ là đã bật.

Sau đó ghi lại sự phân tách trong ghi chú thiết kế: thành phần nào cấp địa chỉ, thành phần nào chuyển tiếp, và lưu lượng ra ngoài qua giao diện máy chủ nào. Khi khởi động lại thay đổi hành vi, ghi chú đó cho bạn biết nên xem cái nào trong ba thứ, thay vì khởi động lại mọi thứ và hy vọng triệu chứng di chuyển.

Một quyết định nữa thuộc về hồ sơ, kể cả khi hôm nay bạn không đưa ra: SecureNAT và một cầu cục bộ là hai thiết kế khác nhau cho cùng một hub, và một hub cần cả hai là hub cần một kế hoạch khác. Hãy chọn có ý thức, ghi lại lý do, và người tiếp theo sẽ không phải kỹ nghịch cấu hình đang chạy để tìm ra nó.