Máy chủ Openvpn không chuyển tiếp lưu lượng ping từ tun0 đến eth0 cho phần còn lại của máy chủ trong mạng con

Hiện tại tôi có một máy chủ openvpn và thiết lập máy khách với tính năng kết nối (không bắc cầu)

Khi tôi cố gắng ping từ máy khách của tôi đến địa chỉ IP của máy chủ, nó hoạt động tốt. Nhưng khi tôi cố gắng ping phần còn lại của các máy chủ mạng con phía sau máy chủ openvpn, nó không hoạt động. Ai đó có thể phát hiện ra một cái gì đó rõ ràng sai trong thiết lập của tôi. . không làm việc.)

Theo những gì tôi hiểu, lưu lượng ping làm cho máy chủ vpn trên giao diện tun0, nhưng sau đó máy chủ vpn không chuyển tiếp nó qua eth0 đến máy chủ phù hợp và do đó máy chủ ping không thấy bất kỳ lưu lượng & gói nào bị hủy. Nhưng những gì có thể gây ra điều này? Có một cài đặt trong openvpn để chuyển tiếp lưu lượng truy cập từ tun0 đến eth0 không?

Đây là những gì tôi quan sát ...

Trên máy chủ máy khách openvpn:

> ping 10.10.146.8
PING 10.10.146.8 (10.10.146.8) 56(84) bytes of data.
<no further output>

Trên máy chủ máy chủ openvpn:

> sudo tcpdump -i tun0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
00:34:32.624639 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1863, length 64
00:34:33.634564 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1864, length 64
00:34:34.640753 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1865, length 64
00:34:35.648922 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1866, length 64
00:34:36.659062 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1867, length 64
00:34:37.665402 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1868, length 64
00:34:38.673295 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1869, length 64
00:34:39.685336 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1870, length 64
00:34:40.687703 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1871, length 64
00:34:41.695766 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 1644, seq 1872, length 64
> sudo tcpdump -i eth0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
04:14:48.583673 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 442, length 64
04:14:49.592908 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 443, length 64
04:14:50.600010 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 444, length 64
04:14:51.616401 IP 10.10.0.6 > 10.10.146.8: ICMP echo request, id 4807, seq 445, length 64

Trên máy chủ trong mạng con mà tôi đang cố gắng ping (10.10.146.8):

> sudo tcpdump -i eth0 'icmp[icmptype] = icmp-echo or icmp[icmptype] = icmp-echoreply'
sudo: unable to resolve host ip-10-10-146-8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
<no further output>

Syslog (nhật ký openvpn) đang nói:

Jul  8 00:36:25 ip-10-10-145-181 ovpn-server[1513]: xyz/<ip_address>:35315 UDPv4 READ [133] from [AF_INET]<ip_address>:35315: P_DATA_V1 kid=0 DATA len=132 
Jul  8 00:36:25 ip-10-10-145-181 ovpn-server[1513]: xyz/<ip_address>:35315 TUN WRITE [84]

netstat trên máy khách openvpn:

10.10.0.1       10.10.0.5       255.255.255.255 UGH       0 0          0 tun0
10.10.0.5       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.10.146.0     10.10.0.5       255.255.255.0   UG        0 0          0 tun0

netstat trên máy chủ openvpn:

10.10.0.0       10.10.0.2       255.255.255.0   UG        0 0          0 tun0
10.10.0.2       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.10.145.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Tôi có một tuyên bố trong cấu hình máy chủ openvpn để định tuyến lưu lượng từ phía máy khách và tôi thấy điều đó xảy ra.

push "route 10.10.146.0 255.255.255.0"

Thông tin bổ sung cho câu hỏi của Andrew

> echo "sysctl -a | grep 'forwarding = 1'" | sudo -s
error: permission denied on key 'vm.compact_memory'
error: permission denied on key 'net.ipv4.route.flush'
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.tun0.forwarding = 1
error: permission denied on key 'net.ipv6.route.flush'



> sudo iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         


> sudo iptables -L FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Cập nhật: Thực tế bây giờ tôi thấy lưu lượng truy cập trên eth0 trên máy chủ, nhưng lưu lượng đó không được đưa vào mạng và được máy chủ khác nhận. Tôi nghĩ rằng đây là vấn đề Amazon VPC.

Ok, tôi đã tìm ra điều này sau một vài giờ điều tra.

Vấn đề là với các thiết lập chuyển tiếp. Các gói được chuyển tiếp đến cổng eth0 không có địa chỉ IP nguồn chính xác của máy chủ trong mạng. Địa chỉ IP từ VPN.

05:07:43.991961 IP 10.8.0.6 > 10.10.146.8: ICMP echo request, id 3497, seq 499, length 64

Bạn có thể chuyển đổi điều đó bằng cách kích hoạt tương đương NAT (trên bộ định tuyến) trong hệ điều hành linux:

iptables -t nat -A POSTROUTING -o <eth0 or whatever else> -j MASQUERADE

Điều này đã khắc phục vấn đề cho tôi.

Vấn đề này có thể xảy ra khi cổng mặc định cho các máy chủ trên mạng LAN không phải là máy chủ OpenVPN. Trong trường hợp như vậy, các máy chủ cần một tuyến tĩnh cho các địa chỉ VPN để các câu trả lời đi đến máy chủ VPN thay vì cổng mặc định.

Trên máy chủ LAN, hãy kiểm tra các tuyến đường ( route printcho Windows, route -ncho Linux, ǹetstat -rncho Mac).

Tôi tìm thấy chủ đề này thông qua google, và cảm ơn thông tin này là hữu ích. Tôi có cùng một vấn đề chính xác, và thông tin này THAM GIA đã giải quyết nó.

Giả trang nó và nó đã làm việc. Nhưng với mục đích của tôi, điều này là không đủ tốt và không phải là giải pháp cũng không phải là Câu trả lời cuối cùng cho tôi, tôi vẫn đang cố gắng để nó được chuyển tiếp mà KHÔNG CÓ Masquerading. Đối với mục đích của tôi, nhận được kết nối một mình là KHÔNG TỐT. Bởi vì tôi cần IP nguồn cho mục đích nhận dạng và kiểm soát truy cập ghi nhật ký. Masquerading có nó kết nối nhưng chấp nhận một cách mù quáng. Kết nối luôn xuất hiện từ một địa chỉ IP FALSE duy nhất.

Tôi đã nhận được một máy chủ SQL, phải chấp nhận / từ chối các kết nối tùy thuộc vào địa chỉ IP nguồn sau khi đi qua VPN. Bạn cũng nên tiếp tục đăng nhập IP truy cập, để giúp theo dõi lỗi hoặc bảo mật chống hack.

Vẫn tự hỏi tại sao chuyển tiếp ở điểm cuối này của VPN sẽ không xảy ra trừ khi Masqueraded. Nghi ngờ có một tường lửa cục bộ hoặc vấn đề bảo mật gây ra.

Vui lòng chia sẻ một số kinh nghiệm hoặc đề xuất, khi bạn lướt đến chủ đề này. Cảm ơn.