Ứng dụng trong không gian tên VPN không truy cập được từ LAN

Dịch vụ của bạn chạy trên máy, đường hầm đã lên, vậy mà trình duyệt trên bàn bạn vẫn chờ phản hồi. Không có gì hỏng theo nghĩa thông thường: ứng dụng đang lắng nghe bên trong một không gian tên mạng, và ngăn xếp đó vô hình với LAN. Loopback của nó thuộc về không gian tên, nên một máy khách trên máy khác không có địa chỉ nào chạm tới cổng. Một bước nhảy có chủ đích, hoặc một cặp veth, sửa được điều đó mà không phải di chuyển phần còn lại của máy chủ.

Vì sao không có gì trả lời trên địa chỉ LAN

Không gian tên là một ngăn xếp mạng hoàn chỉnh: giao diện, tuyến, quy tắc tường lửa và một loopback riêng. Tiến trình khởi chạy qua ip netns exec chỉ thấy ngăn xếp đó và không thấy gì khác, nên địa chỉ mà nó liên kết chỉ được phân giải bên trong không gian tên. 127.0.0.1 của chính máy chủ là một loopback hoàn toàn khác.

Đó là lý do curl trên máy chủ thất bại trong khi cùng lệnh đó bên trong không gian tên lại thành công. Ứng dụng vẫn khỏe; địa chỉ đơn giản là không tồn tại trong ngăn xếp của máy chủ.

Công bố một cổng bằng bước nhảy socat

socat bắc cầu hai ngăn xếp trong không gian người dùng, đủ khi chỉ có một cổng TCP phải đi qua. Phía máy chủ lắng nghe trên LAN và, với mỗi kết nối được chấp nhận, khởi chạy một socat thứ hai bên trong không gian tên nối tới loopback của ứng dụng. Tiến trình bên trong chạm tới ứng dụng đúng như một máy khách cục bộ sẽ làm. Không có gì thay đổi trong định tuyến của không gian tên, nên ứng dụng tiếp tục dùng đường hầm làm lối ra duy nhất.

socat TCP-LISTEN:9100,reuseaddr,fork EXEC:'ip netns exec vpn socat STDIO tcp-connect:127.0.0.1:9100',nofork

Tiến trình bên ngoài cần root hoặc quyền vào không gian tên. Nếu VPN sập, ứng dụng mất đường đi và cổng đã công bố thất bại ở trạng thái đóng, và đó là hành vi bạn muốn từ một nhà giam.

Dùng một cặp veth khi có hơn một cổng đi qua

Một cặp veth là câu trả lời đúng khi phải đi qua nhiều cổng hoặc giao thức, hoặc khi các máy chủ khác cần khởi tạo kết nối. Một đầu ở lại trên máy chủ, đầu kia chuyển vào không gian tên, và một /30 nhỏ cho cả hai bên một địa chỉ ổn định. Sau đó một tuyến trên máy chủ gửi địa chỉ của không gian tên qua cặp đó.

ip link add veth0 type veth peer name veth1
ip link set veth1 netns vpn
ip addr add 10.77.0.1/30 dev veth0
ip link set veth0 up
ip netns exec vpn ip addr add 10.77.0.2/30 dev veth1
ip netns exec vpn ip link set veth1 up

Đừng thêm tuyến mặc định qua máy chủ trừ khi bạn định phá nhà giam. Đường hầm phải tiếp tục là lối ra, nên qua cặp đó chỉ địa chỉ dịch vụ đã công bố là truy cập được. Cũng hãy cho không gian tên tệp phân giải riêng, vì ip netns exec đọc /etc/netns/vpn/resolv.conf và không có nó thì việc phân giải tên trong nhà giam là trống.

Kiểm tra từ máy khác, không phải từ máy chủ

Hãy chạy thử từ một máy thứ hai, vì máy chủ có thể chạm tới một bộ lắng nghe cục bộ qua những đường không nói gì về LAN. Trước tiên hãy kiểm tra ứng dụng thực sự liên kết với gì bên trong không gian tên, rồi kết nối từ bên ngoài tới địa chỉ đã công bố. Liên kết với mọi địa chỉ ở đó không mở rộng nhà giam, vì ký tự đại diện vẫn thuộc không gian tên và LAN không thể thấy nó.

ip netns exec vpn ss -lntp

Nếu kết nối từ máy chủ hoạt động còn từ LAN thì không, phần thiếu là bước nhảy hoặc tuyến, không phải địa chỉ liên kết. Hãy khởi chạy OpenVPN bên trong không gian tên thay vì di chuyển một thiết bị tun đang chạy vào đó, vì di chuyển giao diện sẽ tắt nó và có thể xóa những tuyến mà sau đó bạn không thể sửa từ bên ngoài. Giữ các lệnh phục hồi trên bảng điều khiển, không phải trong nhà giam.