Một NIC hay hai? Quyết định bố trí giao diện của máy chủ VPN

Một bộ điều hợp vật lý là đủ cho nhiều máy chủ VPN, và đó cũng không phải thiết kế phổ quát. Kết nối được mã hóa đến trên bộ điều hợp đó, tiến trình VPN giải mã nó, rồi lưu lượng bên trong đi ra qua một giao diện ảo trước khi đến một dịch vụ cục bộ hoặc một LAN đã định tuyến. Việc đó có hiệu quả hay không phụ thuộc ba điều kiện: đích nằm ở đâu, LAN có đường quay về bể máy khách hay không, và một liên kết vật lý dùng chung có cho bạn sự cô lập mà bạn tuyên bố hay không. Trả lời ba điều đó thì số bộ điều hợp sẽ theo sau.

Ba điều kiện quyết định

Điều kiện thứ nhất là đích. Dịch vụ trên chính máy chủ VPN chỉ đến được qua giao diện đường hầm, trong khi máy chủ trên LAN cần chuyển tiếp và một đường quay về. Điều kiện thứ hai là đường quay về đó, vì thiết bị LAN phải biết cách đến bể máy khách, dù bằng một tuyến hay bằng dịch địa chỉ trên máy chủ.

Điều kiện thứ ba là sự tách biệt. Một bộ điều hợp nghĩa là mọi gói tin, có mã hóa hay không, đều dùng chung một liên kết và thường là một chuỗi chính sách, nên tuyên bố cô lập dựa vào phần cứng riêng không được một giao diện đáp ứng. Đó là sự thật về đường đi, không phải về cách hệ điều hành được cấu hình. Bạn vẫn có thể lọc lưu lượng đường hầm, nhưng không thể tuyên bố một ranh giới mà bạn không có.

Không điều nào trong ba điều nói về số cổng trên khung máy. Chúng nói về định tuyến, quyền sở hữu địa chỉ và mức độ thiết kế phụ thuộc vào tách biệt vật lý.

Hai bộ điều hợp vẫn là lựa chọn hợp lý khi vùng vật lý, đường lên riêng, thông lượng hoặc đường phục hồi ngoài băng tần biện minh cho chúng. Đó là những yêu cầu cụ thể, và nên nêu ra trước khi ai đó đặt mua phần cứng.

Khi dịch vụ chạy trên máy chủ VPN

Trường hợp đơn giản nhất không cần chuyển tiếp gì cả. Tiến trình nhận gói tin của máy khách trên giao diện đường hầm và trao chúng cho một ổ cắm cục bộ, và câu trả lời quay về theo cùng giao diện. Với máy chủ, địa chỉ trong bể máy khách là địa chỉ cục bộ thật.

Hai điều vẫn phải đúng: dịch vụ phải lắng nghe trên một địa chỉ mà đường hầm đến được, và tường lửa của máy chủ phải chấp nhận lưu lượng đến trên giao diện đường hầm. Cả hai đều thấy được trong các lệnh dưới đây.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Gắn dịch vụ chỉ vào địa chỉ công cộng, hoặc lọc giao diện đường hầm do nhầm lẫn, tạo ra một kết nối đến được máy chủ rồi chết. Điều đó trông như sự cố VPN và thường là quyết định về ổ cắm hoặc tường lửa.

Khi đích nằm trên LAN

Đây là nơi thiết kế một bộ điều hợp nhận tiếng là khó chiều. Máy chủ phải chuyển tiếp gói tin của máy khách về phía LAN, và thiết bị LAN phải gửi câu trả lời trở lại bể máy khách. Hoặc bạn mang bể đó như một tuyến trên LAN, hoặc bạn dịch địa chỉ nguồn trên máy chủ để câu trả lời quay về chính máy chủ.

Cả hai câu trả lời đều hợp lý và chúng thất bại theo cách khác nhau. Tuyến quay về giữ địa chỉ máy khách gốc hiển thị với đích, điều tốt cho nhật ký và xấu cho các quy tắc tường lửa giả định địa chỉ LAN. Dịch địa chỉ giữ LAN đơn giản và che giấu danh tính máy khách khỏi đích.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Đường đi không đối xứng là triệu chứng kinh điển: yêu cầu của máy khách đến, câu trả lời đi ra qua một bộ định tuyến khác, và kết nối hết thời gian mà không có lỗi ở cả hai đầu. Bắt gói ở cả hai phía trước khi kết luận bất cứ điều gì về đường hầm.

Tại sao một alias không tạo ra vùng thứ hai

Thêm một địa chỉ thứ hai vào cùng bộ điều hợp, hoặc tạo một giao diện dummy mô phỏng cổng thứ hai, thay đổi rất ít. Các gói tin vẫn đi ra qua cùng liên kết vật lý, cùng cổng chuyển mạch và thường cùng chuỗi tường lửa, nên không có ranh giới mới giữa chúng. Đó là tiện lợi cấu hình, không phải phân đoạn. Coi đó là ranh giới vùng chính là cách một tuyên bố cô lập chỉ tồn tại trên giấy.

Một vùng riêng cần sự tách biệt thật trên đường đi, và đó là yêu cầu mà bộ điều hợp thứ hai đáp ứng. Nếu một quy tắc phụ thuộc vào việc lưu lượng hướng tới VPN không bao giờ dùng chung miền quảng bá với lưu lượng hướng tới LAN, một sợi cáp không thể cho thuộc tính đó, dù máy chủ được đánh địa chỉ thế nào.

Khi một sản phẩm tài liệu hóa topo nhiều giao diện cho một chế độ cụ thể, hãy theo tài liệu của sản phẩm đó thay vì tự nghĩ ra cách lách. Các nhà cung cấp cũng thay đổi topo được hỗ trợ giữa các bản phát hành, thêm một lý do để đọc hướng dẫn hiện hành thay vì ảnh chụp màn hình của trình hướng dẫn cũ.

Kiểm tra bố trí so với lưu lượng bạn cho phép

Liệt kê các lớp lưu lượng mà máy chủ phải mang: máy khách đến máy chủ, máy khách đến LAN, máy chủ đến LAN, và kết nối bên ngoài được mã hóa. Mỗi lớp có nguồn, đích và giao diện, và bố trí phải đáp ứng cả bốn cùng lúc. Thiết kế xử lý ba trong số đó thường là thiết kế sinh ra phiếu hỗ trợ.

Sau đó xác nhận các giao diện thực tế và bản bắt gói thực tế, không phải sơ đồ trong tài liệu thiết kế. Các lệnh dưới đây in cả hai góc nhìn.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Nếu bản bắt gói bên ngoài cho thấy lưu lượng đã mã hóa và bản bắt gói bên trong cho thấy lưu lượng đã giải mã trên giao diện đường hầm trong khi bộ điều hợp vật lý mang cả hai, thì một NIC đang làm việc. Nếu bản bắt gói bên trong trống, vấn đề nằm ở đường hầm hoặc các quy tắc chuyển tiếp, không phải ở số bộ điều hợp. Quyết định topo từ hai bản bắt gói đó và bảng định tuyến, và thay đổi tiếp theo sẽ có thứ để so sánh.