Mở cổng VPN không giúp client truy cập được LAN

Đường hầm được dựng lên, client xác thực thành công, nhưng LAN phía sau gateway vẫn vô hình. Quy tắc lẽ ra phải khắc phục điều này lại cho phép cổng VPN và hoạt động đúng như đã viết, bởi quy tắc đó chỉ điều khiển các gói tin hướng tới chính gateway. Lưu lượng của client tới một host phía sau gateway có đích khác và chuỗi khác. Việc đăng nhập thành công không thay đổi chuỗi nào trong hai chuỗi mà nhân hệ điều hành kiểm tra.

Hai chuỗi, hai đích đến khác nhau

Số phận của gói tin do nơi nó đi quyết định, không phải cách nó đến. Lưu lượng hướng tới một địa chỉ trên gateway được chuyển giao cục bộ và đánh giá bằng các quy tắc đầu vào. Lưu lượng mà gateway chuyển tiếp được đánh giá bằng các quy tắc chuyển tiếp. Cùng một giao diện đường hầm có thể tạo ra cả hai loại gói tin, vì vậy một quy tắc không thể bao phủ cả hai việc.

Toàn bộ lời đồn trong một câu: cho phép trình lắng nghe không nói gì về việc cho phép mạng phía sau nó. Đây là hai quyết định riêng biệt với bằng chứng riêng biệt, và một tên giao diện trên cả hai không hợp nhất chúng.

Quy tắc của trình lắng nghe thực sự cho phép gì

Các gói tin của trình lắng nghe kết thúc trong tiến trình VPN, và chính điều đó mới cho phép dựng đường hầm. Trang quản trị của gateway và một phản hồi chẩn đoán cục bộ cũng dùng đường vào riêng của máy chủ, vì thế phép thử tới gateway thành công trong khi mọi thứ phía sau nó thất bại. Cả hai kết quả đều đúng và không kết quả nào nói về LAN.

Khi tiến trình giải gói lưu lượng của client cho một đích khác, gói tin đi vào đường chuyển tiếp và cần được cho phép tại đó. Xác thực thành công quyết định client là ai; nó không quyết định client được đi đâu. Hai câu hỏi có chủ sở hữu, nhật ký và thông báo lỗi khác nhau.

Thử từ client, không bao giờ từ gateway

Một phép thử tạo trên gateway đi theo đường ra riêng của máy chủ và có thể thành công trong khi đường chuyển tiếp bị đóng. Hãy bắt đầu phép thử từ client và quan sát cả hai đầu của luồng.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Nếu yêu cầu xuất hiện trên tun0 mà không có gì tới được đích, gói tin bị bỏ sau khi đến, điều này chỉ ra các quy tắc chuyển tiếp hoặc bộ lọc của chính đích. Nếu trên tun0 hoàn toàn không có gì xuất hiện, client thậm chí không gửi nó vào đường hầm, và vấn đề là định tuyến trên client chứ không phải chính sách trên gateway. Hãy so sánh với một yêu cầu đi ra đúng cách và không trả về gì, đó là trường hợp đường quay về.

Chuyển tiếp cần ba thứ, không phải một

Chuyển tiếp trong nhân phải được bật, một quy tắc lọc phải chấp nhận luồng, và đích phải tiếp cận được cùng một đường để phản hồi quay lại. Nếu thiếu một trong ba, sự im lặng là như nhau từ góc nhìn của client.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Đọc ba kết quả cùng lúc. Số không ở kết quả đầu khiến hai kết quả kia không còn ý nghĩa, và chính sách bỏ mặc định ở kết quả thứ hai bỏ các gói tin của client trong khi lưu lượng của chính gateway vẫn chạy. Kết quả thứ ba cho thấy vì sao quy tắc của trình lắng nghe chưa bao giờ là vấn đề.

Giữ hai bộ quy tắc riêng biệt trong tài liệu

Hãy viết quy tắc của trình lắng nghe và quy tắc của dịch vụ được chuyển tiếp trên các dòng riêng, với chủ sở hữu và lý do riêng. Khi cổng VPN thay đổi hoặc một dịch vụ mới được công bố, sự tách biệt đó ngăn một thay đổi âm thầm mở rộng thay đổi kia.

Thay vì coi mỗi đồng đẳng đã xác thực là thành viên LAN tin cậy, hãy dùng các quy tắc hẹp cho những dải client và dịch vụ cần chúng. Ghi chú về chuyển tiếp của StrongSwan mô tả phía tuyến quay về và biên dịch của cùng ranh giới đó, đây lại là quyết định thứ ba.

Cuối cùng, hãy giữ các tầng thẳng khi người dùng bị từ chối. Nếu yêu cầu tới được máy chủ và ứng dụng từ chối tài khoản, hãy sửa quyền của ứng dụng ở tầng đó; mở rộng chuyển tiếp không thể cung cấp thông tin đăng nhập chia sẻ tệp và sẽ mở rộng quyền truy cập cho mọi người khác kết nối thành công.