검색
검색

동일한 컴퓨터의 OpenVPN 클라이언트 및 서버-클라이언트가 연결되어있을 때 서버에서 연결을 허용하지 않습니다.

khofm 에 게시 Dev
6
khofm

저는이 커뮤니티에 처음 왔으며 누군가가 저를 도울 수 있기를 바랍니다. 필요한 정보를 모두 게시하지 않은 경우 알려주십시오.

상태:

  • 유료 VPN 공급자에 대한 OpenVPN 클라이언트 (tun1)로 작동하는 Linux 서버 (라즈베리 파이, 192.168.1.2)가 있습니다. Linux 서버를 기본 게이트웨이 (192.168.1.2)로 사용하여이 VPN 연결을 LAN 클라이언트와 로컬로 공유합니다. 이것은 문제없이 작동합니다.

  • 동일한 Linux 서버에서 WAN 클라이언트가 연결할 수 있도록 별도의 openVPN 인스턴스 (VPN 서버, tun0)를 실행하고 있습니다. 유료 VPN 공급자에 대한 VPN 클라이언트 연결이 설정되지 않는 한 아무런 문제없이 작동합니다.

  • 내 궁극적 인 목표는 별도의 openVPN 서버 (tun0) 인스턴스를 통해 연결하는 WAN 클라이언트와 유료 VPN 연결 (tun1)을 공유하는 것입니다.

내 로컬 네트워크 설정 체계 :

여기에 이미지 설명 입력

문제:

  • openVPN 클라이언트와 openVPN 서버 인스턴스는 동시에 실행하지 않는 한 정상적으로 작동합니다. openVPN 클라이언트가 유료 VPN 공급자에 연결되는 즉시 WAN 클라이언트는 openVPN 서버에 연결할 수 없습니다.

  • 로그 파일을 검토 한 결과 유료 VPN 연결이 설정 되 자마자 WAN 클라이언트 핸드 셰이크가 실패한다는 것을 알았습니다. 이 유료 VPN 연결이 설정되면 모든 나가는 인터넷 트래픽이 터널 (tun1)을 통해 라우팅되므로 클라이언트의 핸드 셰이크 요청이 응답되지 않은 상태로 유지되기 때문이라고 생각합니다. 나는 이것을 해결하는 방법을 모른다.

ifconfig

pi@server:~ $ ifconfig -a
eth0      Link encap:Ethernet  HWaddr b8:27:eb:f2:c1:98
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth1      Link encap:Ethernet  HWaddr 58:82:a8:8d:9a:fa
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:203 errors:0 dropped:0 overruns:0 frame:0
          TX packets:165 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:22948 (22.4 KiB)  TX bytes:24938 (24.3 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.77.0.1  P-t-P:10.77.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.130.1.70  P-t-P:10.130.1.69  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

iptables

pi@server:~ $ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:1199

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  10.77.0.0/24         anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

경로 -n (하면된다 TUN1 tun0 / 하지 실행 및 연결되지 않음)

pi@server:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

경로 -n (tun0이 실행 중이고 연결된 경우)

pi@server:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
10.77.0.0       10.77.0.2       255.255.255.0   UG    0      0        0 tun0
10.77.0.2       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

경로 -n (tun1이 실행 중이고 연결된 경우)

pi@raspi-cyberghost:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.130.0.133    128.0.0.0       UG    0      0        0 tun1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
10.77.0.0       10.77.0.2       255.255.255.0   UG    0      0        0 tun0
10.77.0.2       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.130.0.1      10.130.0.133    255.255.255.255 UGH   0      0        0 tun1
10.130.0.133    0.0.0.0         255.255.255.255 UH    0      0        0 tun1
107.183.241.2   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
128.0.0.0       10.130.0.133    128.0.0.0       UG    0      0        0 tun1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

OpenVPN 클라이언트 (tun1)가 연결되어있는 동안 연결을 시도 할 때 OpenVPN 서버 (tun0) 오류 로그

Tue Mar 21 08:06:19 2017 us=593849 172.56.28.50:24844 TLS: Initial packet from [AF_INET]172.56.28.50:24844, sid=d25df6fb 2136a7cc
Tue Mar 21 08:07:19 2017 us=128339 172.56.28.50:24844 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 21 08:07:19 2017 us=128603 172.56.28.50:24844 TLS Error: TLS handshake failed
Tue Mar 21 08:07:19 2017 us=129254 172.56.28.50:24844 SIGUSR1[soft,tls-error] received, client-instance restarting
khofm

내 솔루션을 찾았습니다. 문제는 두 개의 라우팅 테이블을 구축해야한다는 것입니다. 하나는 Pi로 들어오는 트래픽 (및 해당 응답)을 처리하고 다른 하나는 Pi에서 나가는 트래픽 (및 해당 응답)을 처리합니다.

이 두 번째 라우팅 테이블은 나를 위해 해결했습니다.

ip rule add from 192.168.1.2 lookup 10           # Pi server
ip route add default via 192.168.1.1 table 10    # LAN router

이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.

침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제

에서 수정
0

몇 마디 만하겠습니다

0리뷰
로그인참여 후 검토

관련 기사

Related 관련 기사

뜨겁다태그

보관