OpenVPN을 사용하여 사이트 간 VPN을 구성했습니다. 터널은 잘 나오는 것 같지만(한 쪽 끝에서 다른 쪽 끝으로 핑을 보낼 수 있음) 양쪽 끝의 네트워크가 서로를 볼 수는 없습니다.
내 토폴로지는 다음과 같습니다.
Net1 (192.168.13.0/24)
|
|
|
192.168.13.35
ens160
-----------
OVPN Client
-----------
tun0
10.13.10.2
|
|
10.13.10.1
tun0
-----------
OVPN Server
-----------
ens160
10.1.121.6
|
|
Net2 (10.1.121.0/26)
클라이언트에서 서버로 핑을 보낼 수 있습니다.
srv# ping 10.13.10.2
PING 10.13.10.2 (10.13.10.2) 56(84) bytes of data.
64 bytes from 10.13.10.2: icmp_seq=1 ttl=64 time=5.46 ms
64 bytes from 10.13.10.2: icmp_seq=2 ttl=64 time=5.01 ms
클라이언트에서 Net1으로 이동할 수 있습니다(물론 적절한 경로를 추가한 후).
client#ping 10.1.121.8
PING 10.1.121.8 (10.1.121.8) 56(84) bytes of data.
64 bytes from 10.1.121.8: icmp_seq=1 ttl=63 time=48.0 ms
그러나 다른 방향으로 갈 수는 없습니다(서버에서 클라이언트 네트워크 -Net2-의 무언가를 핑하는 것). 서버에서 Net2의 클라이언트 IP에 접근할 수도 없습니다.
server#ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
^C
--- 192.168.13.35 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms
적절한 경로가 있습니다.
server# ip route
default via 10.1.121.1 dev ens160 onlink
10.1.121.0/26 dev ens160 proto kernel scope link src 10.1.121.6
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.1
192.168.13.0/24 via 10.13.10.2 dev tun0
client# ip route
default via 192.168.13.1 dev ens160 onlink
10.1.121.0/24 via 10.13.10.1 dev tun0
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.2
192.168.13.0/24 dev ens160 proto kernel scope link src 192.168.13.35
IPTables는 아무것도 차단하지 않습니다(모든 것이 ACCEPT로 설정됨).
client# iptables -L -vn
Chain INPUT (policy ACCEPT 56 packets, 3839 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 40 packets, 4343 bytes)
pkts bytes target prot opt in out source destination
server# iptables -L -vn
Chain INPUT (policy ACCEPT 736 packets, 75398 bytes)
pkts bytes target prot opt in out source destination
2 168 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 4 packets, 236 bytes)
pkts bytes target prot opt in out source destination
1 84 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 449 packets, 43393 bytes)
pkts bytes target prot opt in out source destination
터널 인터페이스에서 tcpdump를 실행하면 클라이언트에서 나가는 ICMP 패킷이 표시되지만 서버에서 들어오는 것은 표시되지 않습니다.
server# ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
16:57:40.262004 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 1, length 64
16:57:41.269165 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 2, length 64
16:57:42.277154 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 3, length 64
16:57:43.285163 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 4, length 64
client# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
두 끝점 모두 Ubuntu 16.04 Server LTS(x64, 대부분 기본값으로 설치됨)입니다.
저는 Linux 네트워킹에 대해 조금 알고 있다고 생각했는데... 제가 틀렸던 것 같습니다 :) . 왜 이것이 작동하지 않는지 전혀 모르겠고 시도할 수 있는 아이디어가 부족합니다. 누구든지 나에게 올바른 방향을 알려줄 수 있습니까?
감사합니다!
답변1
가 누락되었을 수 있습니다 iroute. 푸시 경로 이상에서는 iroute구성 파일이 필요합니다. 다음은 OpenVPN 매뉴얼 페이지에서 발췌한 내용입니다.
--route 네트워크 [넷마스크]
특정 클라이언트에 대한 내부 경로를 생성합니다. 넷마스크 매개변수가 생략된 경우 기본값은 255.255.255.255입니다. 이 지시문은 클라이언트가 연결되는 위치에 관계없이 서버에서 특정 클라이언트로 고정 서브넷을 라우팅하는 데 사용할 수 있습니다. 시스템 라우팅 테이블에도 경로를 추가해야 한다는 점을 기억하세요(예: --route 지시어 사용). 두 개의 경로가 필요한 이유는 --route 지시문이 패킷을 커널에서 OpenVPN으로 라우팅하기 때문입니다. OpenVPN에 들어가면 --iroute 지시문이 특정 클라이언트로 라우팅됩니다. 이 옵션은 --client-config-dir을 사용하여 클라이언트 인스턴스 구성 파일에서 지정하거나 --client-connect 스크립트를 사용하여 동적으로 생성되어야 합니다. --iroute 지시문은 --push "route ..."와도 중요한 상호 작용을 합니다. --iroute는 기본적으로 특정 클라이언트(이 클라이언트 A라고 함)가 소유한 서브넷을 정의합니다. 다른 클라이언트가 A의 서브넷에 도달할 수 있도록 하려면 --client-to-client와 함께 --push "route ..."를 사용하여 이를 적용할 수 있습니다. 모든 클라이언트가 A의 서브넷을 보려면 OpenVPN은 A를 제외한 모든 클라이언트에 이 경로를 푸시해야 합니다. 서브넷은 이미 A가 소유하고 있기 때문입니다. OpenVPN은 클라이언트의 서브넷 중 하나와 일치하는 경우 클라이언트에 경로를 푸시하지 않음으로써 이를 수행합니다. 노선.
각 클라이언트와 서버에 아래와 같은 구성 항목이 필요합니다.
경로 192.168.3.0 255.255.255.0
또한 여러 클라이언트 뒤에 여러 네트워크가 있는 경우 CCD를 확인해야 할 수도 있습니다.
클라이언트 구성 디렉터리
이 지시문은 OpenVPN 서버가 들어오는 모든 연결을 검색하여 클라이언트별 구성 파일을 검색하는 클라이언트 구성 디렉터리를 설정합니다(자세한 내용은 매뉴얼 페이지 참조). 이 디렉터리의 파일은 서버를 다시 시작하지 않고도 즉시 업데이트할 수 있습니다. 이 디렉터리의 변경 사항은 기존 연결이 아닌 새 연결에만 적용됩니다. 클라이언트별 구성 파일 변경 사항이 현재 연결된 클라이언트(또는 연결이 끊어졌지만 서버가 해당 인스턴스 개체의 시간 초과를 초과하지 않은 클라이언트)에 즉시 적용되도록 하려면 관리를 사용하여 클라이언트 인스턴스 개체를 종료합니다. 인터페이스(아래 설명). 그러면 클라이언트가 다시 연결되어 새 client-config-dir 파일을 사용하게 됩니다.
답변2
Fossil의 대답은 나에게 딱 필요한 것이었고 나는 이미 그것을 받아들였습니다. 같은 문제를 겪고 있는 다른 사람들을 위해 몇 가지 정보를 추가하고 싶습니다. 이전에 serverfault에서 질문을 받았지만 답변에 iroute에 대한 언급이 없기 때문입니다(한 가지 예) 또는 데드 링크(예:이 하나)
그래서... 우선 iroute에 대한 좋은 설명을 찾았습니다(그리고 그것이 필요한 이유).여기. 그러나 방금 링크가 끊어지는 위험에 대해 언급했으므로 아래에서 가장 중요한 아이디어도 언급하려고 합니다.
트래픽이 OpenVPN 터널을 통과하기에는 커널 경로가 충분하지 않은 것 같습니다. OpenVPN 클라이언트 뒤에 있는 LAN에 연결하려면 OpenVPN 내부 경로(iroute)도 필요합니다. 이는 server.conf의 client-configuration-dir 문을 사용하고 해당 하위 디렉터리에 있는 구성 파일에 iroute 문을 추가하여 추가됩니다.
내 경우에는 다음도 필요했습니다.
#Inside server.conf
client-configuration-dir my-config-dir
#Inside my-config-dir/client1 (same name as the client!)
#Tell OpenVPN that 192.168.13.0/24 is reachable via client1
iroute 192.168.13.0 255.255.255.0
이는 또한 흥미로운 문제를 제기합니다. OpenVPN이 커널 경로만 사용하여 작동할 수 없는 경우 언뜻 보기에는 ovpn 터널 위에서 라우팅 프로토콜을 실행하는 것이 불가능해 보입니다. 그런 솔루션(ovpn+rip/ospf)이 작동하는 사람이 있나요?