Tôi đã có thể thiết lập một không gian tên mạng, thiết lập một đường hầm với openvpn và bắt đầu một ứng dụng sử dụng đường hầm này bên trong không gian tên. Cho đến nay rất tốt, nhưng ứng dụng này có thể được truy cập thông qua giao diện web và tôi không thể tìm ra cách định tuyến các yêu cầu đến giao diện web trong mạng LAN của mình.
Tôi đã làm theo hướng dẫn từ @schnouki giải thích cách thiết lập không gian tên mạng và chạy OpenVPN bên trong nó
ip netns add myvpn
ip netns exec myvpn ip addr add 127.0.0.1/8 dev lo
ip netns exec myvpn ip link set lo up
ip link add vpn0 type veth peer name vpn1
ip link set vpn0 up
ip link set vpn1 netns myvpn up
ip addr add 10.200.200.1/24 dev vpn0
ip netns exec myvpn ip addr add 10.200.200.2/24 dev vpn1
ip netns exec myvpn ip route add default via 10.200.200.1 dev vpn1
iptables -A INPUT \! -i vpn0 -s 10.200.200.0/24 -j DROP
iptables -t nat -A POSTROUTING -s 10.200.200.0/24 -o en+ -j MASQUERADE
sysctl -q net.ipv4.ip_forward=1
mkdir -p /etc/netns/myvpn
echo 'nameserver 8.8.8.8' > /etc/netns/myvpn/resolv.conf
Sau đó, tôi có thể kiểm tra ip bên ngoài của mình và nhận các kết quả khác nhau bên trong và bên ngoài không gian tên, đúng như dự định:
curl -s ipv4.icanhazip.com
<my-isp-ip>
ip netns exec myvpn curl -s ipv4.icanhazip.com
<my-vpn-ip>
Ứng dụng được bắt đầu, tôi đang sử dụng deluge cho ví dụ này. Tôi đã thử một vài ứng dụng với giao diện web để đảm bảo đó không phải là vấn đề cụ thể.
ip netns exec myvpn sudo -u <my-user> /usr/bin/deluged
ip netns exec myvpn sudo -u <my-user> /usr/bin/deluge-web -f
ps $(ip netns pids myvpn)
PID TTY STAT TIME COMMAND
1468 ? Ss 0:13 openvpn --config /etc/openvpn/myvpn/myvpn.conf
9302 ? Sl 10:10 /usr/bin/python /usr/bin/deluged
9707 ? S 0:37 /usr/bin/python /usr/bin/deluge-web -f
Tôi có thể truy cập giao diện web trên cổng 8112 từ trong không gian tên và từ bên ngoài nếu tôi chỉ định ip của veth vpn1.
ip netns exec myvpn curl -Is localhost:8112 | head -1
HTTP/1.1 200 OK
ip netns exec myvpn curl -Is 10.200.200.2:8112 | head -1
HTTP/1.1 200 OK
curl -Is 10.200.200.2:8112 | head -1
HTTP/1.1 200 OK
Nhưng tôi muốn chuyển hướng cổng 8112 từ máy chủ của mình sang ứng dụng trong không gian tên. Mục tiêu là mở trình duyệt trên máy tính trong mạng LAN của tôi và nhận giao diện web với http: // my-server-ip: 8112 (my-server-ip là ip tĩnh của máy chủ khởi tạo giao diện mạng)
EDIT: Tôi đã loại bỏ các nỗ lực của mình để tạo quy tắc iptables. Những gì tôi đang cố gắng làm được giải thích ở trên và các lệnh sau sẽ tạo ra HTTP 200:
curl -I localhost:8112
curl: (7) Failed to connect to localhost port 8112: Connection refused
curl -I <my-server-ip>:8112
curl: (7) Failed to connect to <my-server-ip> port 8112: Connection refused
Tôi đã thử các quy tắc DNAT và SNAT và ném vào một MẶT BẠC để có biện pháp tốt, nhưng vì tôi không biết mình đang làm gì, nên những nỗ lực của tôi là vô ích. Có lẽ ai đó có thể giúp tôi kết hợp công trình này.
EDIT: Sản lượng tcpdump của tcpdump -nn -q tcp port 8112. Không có gì đáng ngạc nhiên, lệnh đầu tiên trả về HTTP 200 và lệnh thứ hai chấm dứt với kết nối bị từ chối.
curl -Is 10.200.200.2:8112 | head -1
listening on vpn0, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 10.200.200.1.36208 > 10.200.200.2.8112: tcp 82
IP 10.200.200.2.8112 > 10.200.200.1.36208: tcp 145
curl -Is <my-server-ip>:8112 | head -1
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
IP <my-server-ip>.58228 > <my-server-ip>.8112: tcp 0
IP <my-server-ip>.8112 > <my-server-ip>.58228: tcp 0
EDIT: Chính @schnouki đã chỉ cho tôi một bài viết về Quản trị Debian giải thích một proxy TCP iptables chung . Áp dụng cho vấn đề hiện tại, kịch bản của họ sẽ như thế này:
YourIP=<my-server-ip>
YourPort=8112
TargetIP=10.200.200.2
TargetPort=8112
iptables -t nat -A PREROUTING --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort
iptables -t nat -A POSTROUTING -p tcp --dst $TargetIP --dport $TargetPort -j SNAT \
--to-source $YourIP
iptables -t nat -A OUTPUT --dst $YourIP -p tcp --dport $YourPort -j DNAT \
--to-destination $TargetIP:$TargetPort
Thật không may, lưu lượng giữa các giao diện veth bị thu giữ và không có gì khác xảy ra. Tuy nhiên, @schnouki cũng đề xuất sử dụng socatnhư một proxy TCP và điều này đang hoạt động hoàn hảo.
curl -Is <my-server-ip>:8112 | head -1
IP 10.200.200.1.43384 > 10.200.200.2.8112: tcp 913
IP 10.200.200.2.8112 > 10.200.200.1.43384: tcp 1495
Tôi vẫn chưa hiểu được sự xáo trộn của cổng lạ trong khi lưu lượng truy cập đang đi qua các giao diện veth, nhưng vấn đề của tôi đã được giải quyết.
vethcác thiết bị (mặc dù điều này rất thú vị, mặc dù ... ;-)). Bạn đã sử dụngtcpdumpđể kiểm tra các gói đến được bao xa? Nếutcpdump -i veth0không hiển thị bất cứ điều gì thìtcpdumo -i locó thể cần thiết.