☰

VPN을 통해 호스트에 연결된 Docker 호스트를 ping할 수 없습니다.

tag-icon • tag-icon linux networking openvpn docker centos-7
VPN을 통해 호스트에 연결된 Docker 호스트를 ping할 수 없습니다.

Docker 호스트이자 OpenVPN 서버인 CentOS 7과 클라이언트인 Ubuntu라는 두 개의 호스트가 있습니다. OpenVPN을 사용하여 클라이언트를 호스트에 연결하고 있지만 문제는 VPN 서버가 응답을 다시 보내지 않는다는 것입니다. 즉, 패킷을 다시 보내지 않는다는 것입니다. 클라이언트가 NAT 뒤에 있습니다. 양쪽의 방화벽을 확인했습니다. 모든 유형의 트래픽이 허용됩니다. 또 무엇을 확인해야 합니까? MTU가 확실히 원인은 아닙니다. 라우터로는 Mikrotik을 사용하고 있습니다.

클라이언트 구성:

remote <Server IP>
dev tun
rport 18999
lport 18999
proto udp
ifconfig IP1 IP2
secret /etc/openvpn/static.key 1
persist-tun
persist-key
keepalive 10 60
ping-timer-rem
verb 3
daemon
log-append /var/log/openvpn.log

서버측 구성:

ev tun.yasha
proto udp
local <someip>
lport 18999
rport 18999
secret /etc/openvpn/.keys/secret.key 0
ifconfig <IP2> <IP1>
user nobody # On CentOS
group nobody # On CentOS
persist-tun
persist-key
keepalive 10 60
ping-timer-rem
verb 6
daemon
log-append /var/log/openvpn.log

터널이 활성화된 동안 출력: 고객: IP R

default via 192.168.88.1 dev wlp3s0 proto dhcp metric 600 
10.8.0.1 dev tun0 proto kernel scope link src 10.8.0.2 
169.254.0.0/16 dev wlp3s0 scope link metric 1000 
192.168.88.0/24 dev wlp3s0 proto kernel scope link src 192.168.88.34 metric 600

IP

tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.2 peer 10.8.0.1/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::9b45:4bf5:f2d7:5375/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

섬기는 사람:

IP R

default via 217.12.XXX.X dev eno1 
10.8.0.2 dev tun.yasha proto kernel scope link src 10.8.0.1

ip a (머신에 인터페이스가 많아서 생략합니다)

tun.yasha: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.1 peer 10.8.0.2/32 scope global tun.yasha
       valid_lft forever preferred_lft forever
    inet6 fe80::4815:ef11:3756:faea/64 scope link flags 800 
       valid_lft forever preferred_lft forever

답변1

구성에서는 클라이언트의 터널에 대한 IP 주소만 구성했습니다.

주소는 /32 지점간 주소이므로 기본적으로 경로가 추가되지 않을 수 있습니다. (플랫폼마다 다를 수 있습니다.)

단순히 서버와 통신하고 싶지만 IP1기본적으로 작동하지 않는 경우 추가하는 것만으로도 route IP1충분합니다.

예를 들어 클라이언트 호스트의 모든 트래픽을 터널로 라우팅하려는 경우 redirect-gateway대신 이 옵션을 사용하는 것이 좋습니다.

후자의 경우 클라이언트 호스트가 터널을 통해 액세스할 수 있는 DNS 서버를 사용하는지 확인해야 합니다(참조 dhcp-option DNS). 또한 서버에서 터널과 NIC 간의 IP 전달을 활성화해야 합니다.

관련 정보