Vì sao địa chỉ tunnel VPN của bạn không mở một cổng vào
Địa chỉ tunnel nhận diện máy khách của bạn với các peer có thể định tuyến tới nó, và không bao giờ tạo ra một trình lắng nghe. Hãy kiểm tra ràng buộc, tuyến đường về, rồi đến chính sách.
Kết nối với VPN của văn phòng, khởi động một dịch vụ nhỏ trên cổng 8443, gửi địa chỉ tunnel cho đồng nghiệp và quan sát kết nối thất bại trong khi máy khách vẫn báo là đã kết nối. Không có gì hỏng trong tunnel: địa chỉ đã được cấp, phiên đang hoạt động, và các gói tin lẽ ra chở câu trả lời đơn giản là không bao giờ được cho qua. Hãy thực hiện ba kiểm tra dưới đây theo thứ tự và dừng ở kiểm tra thất bại, vì mỗi kiểm tra có cách sửa khác nhau và chỉ một trong số đó liên quan đến VPN.
Bắt đầu từ nơi socket thực sự được ràng buộc
Trước khi bất cứ thứ gì được định tuyến, phải có thứ gì đó đang lắng nghe trên một địa chỉ mà bên gọi có thể chạm tới. Máy chủ phát triển là thủ phạm thường gặp, vì nhiều máy trong số đó mặc định ràng buộc vào loopback và chỉ chấp nhận các kết nối bắt nguồn từ cùng máy. Địa chỉ tunnel không thay đổi ràng buộc đó, và hệ điều hành sẽ từ chối kết nối rất lâu trước khi VPN can dự vào.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Đọc cột địa chỉ cục bộ thay vì trạng thái. 127.0.0.1:8443 nghĩa là chỉ loopback, và cách sửa là ràng buộc vào 0.0.0.0 hoặc chính địa chỉ tunnel. 0.0.0.0:8443 chấp nhận trên mọi giao diện, rộng hơn mức mà hầu hết mọi người dự định khi máy cũng có địa chỉ công cộng; 10.64.7.15:8443 là phiên bản hẹp chỉ lắng nghe nơi đồng nghiệp có thể tới. Cũng để ý tên tiến trình trong cùng đầu ra, vì một phiên bản sót lại từ lần thử trước là nguyên nhân phổ biến khiến cổng trông như đang mở và trả lời bằng nội dung sai.
Sau đó hỏi xem có gì định tuyến được tới địa chỉ đó không
Địa chỉ tunnel chỉ có ý nghĩa với các peer được cấu hình để gửi tiền tố đó vào tunnel. Máy của đồng nghiệp có bảng riêng, và nếu không có tuyến đường tới mạng con của tunnel, gói tin sẽ đi tới cổng mặc định và chết ở một nơi không hề biết địa chỉ đó tồn tại. Đây là câu hỏi định tuyến ở phía bên gọi, không phải quyền cho phép ở phía bạn.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Máy chủ giữa hai máy khách cũng quan trọng không kém. Trong thiết kế truy cập từ xa thông thường, mỗi máy khách mở một kết nối đi ra tới cổng và cổng giữ trạng thái của các luồng đó, nên câu trả lời quay về theo một đường mà nó đã biết. Kết nối từ máy khách này sang máy khách khác là một luồng mới mà cổng phải chấp nhận và chuyển tiếp, và nhiều triển khai cố ý tắt điều đó để giữ các máy khách tách biệt nhau. Dịch vụ VPN tiêu dùng thường tách biệt theo mặc định; cổng doanh nghiệp đôi khi cho phép theo nhóm.
Kiểm tra hướng trước khi thay đổi bất cứ thứ gì trên máy chủ. Nếu địa chỉ tunnel trả lời từ chính cổng nhưng không từ một peer, khác biệt là thiết lập máy khách-tới-máy khách của cổng, và không việc sửa tường lửa cục bộ nào thay thế được điều đó.
Cuối cùng, tìm chính sách cho phép luồng
Ba lớp chính sách nằm giữa một gói tin đã định tuyến và một dịch vụ trả lời: quyết định chuyển tiếp của máy chủ VPN, tường lửa của máy chủ, và bất kỳ nhóm bảo mật đám mây nào phía trước phiên bản. Cả ba phải đồng ý, và chúng thất bại theo những cách khác nhau, vì vậy triệu chứng trong bảng trên hữu ích hơn thông báo lỗi trong trình duyệt.
Tường lửa của máy chủ là lớp người ta quên sau một ràng buộc thành công, vì một quy tắc cho phép cổng trên giao diện LAN không tự động cho phép nó trên giao diện tunnel. Các quy tắc giới hạn theo giao diện là thiết kế đúng và cũng là nguyên nhân thường gặp của dịch vụ chạy được từ văn phòng mà không chạy được từ nhà. Hãy đọc phạm vi của quy tắc, không phải số cổng.
Lọc theo trạng thái giải thích trường hợp ngược lại. Một kết nối đi ra từ máy tính xách tay của bạn tạo ra trạng thái, và các câu trả lời cho nó được cho qua mà không cần quy tắc vào. Kết nối của đồng nghiệp là một luồng hoàn toàn mới không có trạng thái phía sau, nên nó cần sự cho phép rõ ràng. Sự bất đối xứng đó chính là toàn bộ lý do vì sao một phiên trình duyệt chạy được trên máy của bạn không nói gì về việc dịch vụ có truy cập được từ bên ngoài hay không.
Khi một kiểm tra thất bại, hãy đổi thiết kế chứ không đổi tunnel
Nếu yêu cầu là để đồng nghiệp mở dịch vụ cục bộ của bạn, câu trả lời trung thực thường là một cơ chế được xây dựng cho truy cập vào. Tunnel SSH ngược là cái nhỏ nhất: máy của bạn kết nối đi ra tới một máy chủ mà đồng nghiệp đã có thể tới, và trình lắng nghe tồn tại trên máy chủ đó.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Relay cần GatewayPorts clientspecified trong cấu hình máy chủ SSH của nó, nếu không trình lắng nghe được chuyển tiếp sẽ ràng buộc vào loopback trên relay và đồng nghiệp gặp lại đúng sự từ chối như trước. Với bất cứ thứ gì tồn tại lâu hơn một buổi chiều, bộ cân bằng tải hoặc ingress có kiểm tra sức khỏe và chứng chỉ cho tên đã công bố là công cụ tốt hơn, và tunnel từ site tới site có tuyến đường cho cả hai mạng con là câu trả lời đúng khi hai mạng thực sự cần nói chuyện với nhau.
Mỗi thiết kế đó làm cho sự phơi bày trở nên rõ ràng, và đó chính là điểm mấu chốt. VPN di chuyển các gói tin giữa những mạng mà bạn đã được ủy quyền sử dụng; nó không công bố một dịch vụ và không biến máy tính xách tay thành máy chủ hướng ra internet. Nhiệm vụ là quyết định lớp nào trong ba lớp cần thay đổi, và tunnel hiếm khi là một trong số đó.