☰

OpenVPN 클라이언트를 통해 LAN 서브넷으로 라우팅

tag-icon • tag-icon linux openvpn route
OpenVPN 클라이언트를 통해 LAN 서브넷으로 라우팅

OpenVPN 클라이언트를 통해 연결된 LAN 서브넷으로 라우팅하려고 합니다.

해당 명령을 사용하는 데 문제가 있습니다 route. 이해할 수 없습니다. OpenVPN 링크가 설정되고 ping클라이언트를 연결할 수 있습니다.

VPN 서버의 LAN 서브넷에 경로를 추가하려고 하면 다음 오류가 발생합니다.

# route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.9.0.6 dev tun0
SIOCADDRT: No such process

라우팅 테이블은OpenVPN 서버가 있는데 10.9.0.0/24, 무엇이 문제인지 잘 모르겠습니다.

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         ve108.csr2.lga1 0.0.0.0         UG    0      0        0 eth0
10.9.0.0        10.9.0.2        255.255.255.0   UG    0      0        0 tun0
10.9.0.2        *               255.255.255.255 UH    0      0        0 tun0
204.145.81.0    *               255.255.255.0   U     0      0        0 eth0

추가 정보:

# ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0e:cf:20:c1:24 brd ff:ff:ff:ff:ff:ff
    inet 204.145.81.11/24 brd 204.145.81.255 scope global eth0
    inet6 fe80::20e:cfff:fe20:c124/64 scope link 
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.9.0.1 peer 10.9.0.2/32 scope global tun0

ping라우팅하려는 VPN 클라이언트 에 액세스할 수 있는데 왜 이 문제가 발생하는지 이해할 수 없습니다. 내가 아는 한 경로를 추가할 수 있어야 합니다.

# ping -c 1 10.9.0.6
PING 10.9.0.6 (10.9.0.6) 56(84) bytes of data.
64 bytes from 10.9.0.6: icmp_req=1 ttl=64 time=24.0 ms

--- 10.9.0.6 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.008/24.008/24.008/0.000 ms

자세한 내용은 다음과 같습니다.OpenVPN 클라이언트, VPN 서버에 연결하세요. 내가 라우팅하려는 네트워크가 이 클라이언트에 있습니다.

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         greece-gw.secus 0.0.0.0         UG    2      0        0 eth0
10.9.0.1        10.9.0.5        255.255.255.255 UGH   0      0        0 tun0
10.9.0.5        *               255.255.255.255 UH    0      0        0 tun0
loopback        localhost       255.0.0.0       UG    0      0        0 lo
192.168.0.0     *               255.255.255.0   U     0      0        0 eth1
198.50.241.0    *               255.255.255.0   U     0      0        0 eth0

VPN 서버에 정상적으로 도달합니다.

# ping -c 1 10.9.0.1
PING 10.9.0.1 (10.9.0.1) 56(84) bytes of data.
64 bytes from 10.9.0.1: icmp_seq=1 ttl=64 time=24.0 ms

--- 10.9.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.017/24.017/24.017/0.000 ms

IP 전달을 활성화합니다.

# sysctl -a | grep forwarding
net.ipv4.conf.all.forwarding = 1

iptables전달을 허용하도록 설정했습니다 .

# iptables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  tun0   eth1    0.0.0.0/0            0.0.0.0/0

클라이언트 인터페이스의 구성은 다음과 같습니다.

# ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:5f:f2:1e brd ff:ff:ff:ff:ff:ff
    inet 198.50.241.113/24 brd 198.50.241.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe5f:f21e/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:c6:b8:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fec6:b8fd/64 scope link 
       valid_lft forever preferred_lft forever
4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN 
    link/sit 0.0.0.0 brd 0.0.0.0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none 
    inet 10.9.0.6 peer 10.9.0.5/32 scope global tun0
       valid_lft forever preferred_lft forever

답변1

불행하게도 웹 도구에는 종종 끔찍한 오류 메시지가 표시됩니다. 내가 알 수 있는 한, 커널이 싫어하는 점은 게이트웨이를 사용하여 경로를 추가하려고 하지만 게이트웨이를 "로컬"로 간주하지 않는 경우입니다. 다음을 수행해야 합니다.

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.9.0.2 dev tun0

또는:

route add -net 192.168.0.0 netmask 255.255.255.0 dev tun0

커널 라우팅을 구성하는 것 외에도 openvpn 자체 내에 라우팅을 추가해야 합니다. 이는 클라이언트의 ccd 파일에 있는 "iroute" 지시문을 사용하여 수행됩니다.

답변2

다른 검색을 하는 동안 우연히 이 질문을 발견했는데, OP가 액세스를 시도한 것 같습니다.서브넷원격 OpenVPN 서버에 연결합니다.

나의 대답 가설터널모드, 아니브리지된모델. (OpenVPN은라우터,하나도 아니야변화.)

제가 올바르게 이해했다면 --client-config-dir이 경우에는 ("CCD")를 사용해야 합니다. route서브넷 주소 범위를 포함하는 기본 구성에 지시문이 있어야 합니다.그리고CCD 파일 중 하나 iroute("i" 참고)가 다음에 속하는 것으로 올바르게 식별됩니다.저것외딴. (OpenVPN 로그를 보고 인식되는지 확인한 다음 해당 경로가 현재 컴퓨터에 존재하는지 확인할 수 있습니다.)

다른 서브넷에서 이 서브넷에 액세스하는 경우(즉OpenVPN 클라이언트를 실행하는 컴퓨터가 아닌,반품OpenVPN 컴퓨터에 "게이트웨이로" 트래픽을 보내는 로컬 서브넷 내의 고정 경로입니다. 이는 각 클라이언트 컴퓨터에서 정의하거나 보다 편리하게 로컬 라우터에서 정의할 수 있습니다.

트래픽 흐름은 다음과 같습니다.

  • 원격 서브넷을 ping합니다.
  • 귀하의 컴퓨터 또는 라우터는 게이트웨이 역할을 하는 OpenVPN 박스로 트래픽을 전달합니다.(기능적으로 OpenVPN 터널은 라우터 역할을 하기 때문입니다.)
  • 해당 시스템의 지침에 따라 route트래픽이 장치로 전송되어 tunXOpenVPN이 실제로 트래픽을 선택할 수 있습니다.
  • 이 iroute지시문(및 해당 CCD)은 OpenVPN에 원격 서브넷이 존재하는지, 그리고 이를 어느 원격지로 보낼지 알려줍니다.(리모컨 하나만 사용해도 마찬가지입니다.)
  • 트래픽은 원격 측의 대상으로 라우팅됩니다.
  • 그리고 이제 모든 것이 거꾸로 일어나야 합니다! 원격 서브넷의 IP 주소를 사용하여 원격으로 핑 응답을 보내고 성공해야 합니다.처음부터 다시집.

OpenVPN에 직접 연결된 컴퓨터에서 핑하는 경우(클라이언트를 실행 중입니다)10.8.0.x, 귀하의 주소는 다음 과 같습니다 .이것또한 주소 범위는 모든 관련 장치에서 "왕복"으로 성공적으로 라우팅되어야 합니다.

이는 "기본 TCP/IP 라우팅 문제"이며 "문제의 라우터"가 OpenVPN인지 여부에 관계없이 발생합니다. 호스트가 서로 성공적으로 대화하면(응!), “네트워크에서 그들은 단지 라우터일 뿐입니다.”

tcpdump(또는 WireShark)는 traceroute당신의 가장 친한 친구입니다. 먼저, 암호화된 트래픽이 OpenVPN 호스트 간에 이동해야 하는 방식으로 이동하는지 확인해야 합니다.(물론 내용을 읽을 수 없어도 라우팅 여부는 알 수 있습니다.)그런 다음 터널 내부에서도 동일한 작업을 수행합니다. 패킷이 터널을 통해 전달되고 터널까지 도달하는지 확인하세요.그리고물러서세요. (별표가 인쇄되기 시작하면 traceroute아마도 해당 항목이 없다는 의미일 것입니다.취소특정 "홉"으로 라우팅합니다. 소포가 거기 도착했지만 거기에서 집으로 돌아갈 방법이 없었습니다. )

관련 정보