
Debian 서버에 OpenVPN을 설정했습니다. 클라이언트는 연결할 수 있고, 클라이언트는 서버의 리소스(Samba 공유 및 인트라넷)를 ping하고 액세스할 수 있습니다.
그러나 서버는 클라이언트에 ping을 보낼 수 없습니다. 시간이 초과될 뿐입니다.
도표
Client OpenVPN assigned IP: 10.67.15.26
↓ UDP on 1194
Internet
↓
Router port-forwards 1194 to server
↓
Server LAN IP: 10.67.5.1
서버 OpenVPN 구성(관련 비트)
port 1194
proto udp
dev tun
server 10.67.15.0 255.255.255.0
push "route 10.67.5.0 255.255.255.0"
서버 라우팅 테이블
Destination Gateway Genmask Flags Metric Ref Use Iface
10.67.15.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.67.15.0 10.67.15.2 255.255.255.0 UG 0 0 0 tun0
10.67.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 10.67.5.254 0.0.0.0 UG 0 0 0 eth1
서버 방화벽
서버의 방화벽을 일시적으로 비활성화했으며 모든 체인의 정책이 ACCEPT이고 모든 전달 플래그가 설정되었습니다.
1 : /proc/sys/net/ipv4/conf/all/forwarding
1 : /proc/sys/net/ipv4/conf/default/forwarding
1 : /proc/sys/net/ipv4/conf/lo/forwarding
1 : /proc/sys/net/ipv4/conf/eth1/forwarding
1 : /proc/sys/net/ipv4/conf/tun0/forwarding
1 : /proc/sys/net/ipv4/ip_forward
테스트 사례:
클라이언트: ping 10.67.5.1
다른 리소스와 마찬가지로 작동합니다.
서버: ping 10.67.15.26
시간이 초과되었습니다.
답변1
서로 다른 두 클라이언트를 비교함으로써 두 가지 문제를 식별하고 해결할 수 있었습니다.
문제 1: 라우팅
어떤 이유로(그리고 이 문제를 해결했는지 잘 모르겠습니다) 서버의 라우팅 테이블이 해당 LAN(10.67.5.0/24)과의 경로를 계속 잊어버렸습니다. 이로 인해 모든 아웃바운드 LAN 트래픽이 OpenVPN LAN(10.67.15.0/24)으로 라우팅되지 않는 기본 게이트웨이를 통과하게 되었습니다. 이로 인해 LAN으로 향하는 OpenVPN 네트워크의 트래픽이 기본 게이트웨이에서 실패하게 되었습니다. 따라서 핑이 전송되었지만 응답이 삭제되었습니다.
편집하다:불행하게도 이 경로가 삭제된 원인이 무엇인지 모르겠습니다. 보시다시피 위의 라우팅 테이블에 있었습니다. /etc/network/interfaces에 경로 명령을 추가하려고 시도했지만 두 개의 중복되고 동일한 경로가 생겨서 다시 제거했습니다.그건 내꺼였어fwbuilder이 경로가 삭제되는 원인이 되는 구성: eth1 어댑터를 설정할 때 /24(LAN용) 대신 /32 넷마스크(즉, 호스트)를 지정했습니다.
Debian 클라이언트를 테스트하여 이를 알아낼 수 있었고 그 후에는 작동했지만 Windows 7 클라이언트는 작동하지 않았습니다.
문제 2: Windows 7 방화벽/구성
Windows 설정에는 두 가지 문제가 있었습니다.
Windows에는 TAP 어댑터에 대한 "회사" 개인 프로필 세트가 있어야 합니다.
2020-06-11 기준 업데이트
다음 두 가지 powershell 명령을 사용하여 인터페이스를 개인용으로 변경할 수 있습니다.
# this first one will let you see the available connections,
# find the interface index of the one you would like to change
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex NN -NetworkCategory Private
"네트워크 및 공유 센터"에는 (적어도) 2개의 "활성 네트워크"가 표시되어야 합니다. 무선 네트워크가 있었고 "식별되지 않은 네트워크"가 있었습니다. 후자는 OpenVPN TAP 장치이며 공원 벤치 아이콘이 있었습니다. 이는 신뢰할 수 없는 공개 장치로 취급되었음을 의미합니다. 이를 변경하려면 어댑터에 대한 기본 게이트웨이를 추가해야 합니다.
DOS/Cygwin 터미널 시작관리자로서. (Orb 시작 > CMD 검색 > 마우스 오른쪽 버튼 클릭 > 관리자 권한으로 실행).
그런 다음 route print -4
. 인터페이스 목록이 표시됩니다. 각 줄은 숫자로 시작하고 오른쪽에 이름이 표시됩니다. TAP-Win32 어댑터의 인터페이스 번호를 식별합니다. 내 나이는 17살이었어.
이제 경로를 추가합니다.
route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17
여기서 1.2.3.4는 OpenVPN 게이트웨이의 IP(이전 명령 출력의 게이트웨이 열에 표시됨)여야 하고 17은 TAP 인터페이스 번호여야 합니다. 이 -p
옵션은 경로를 영구적으로 만듭니다. 테스트를 위해 먼저 이것 없이 해봤습니다.이는 클라이언트의 OpenVPN 게이트웨이 IP가 연결 간에 변경되지 않을 것이라고 가정합니다..
이 작업을 완료하면 대화 상자가 나타나 새 네트워크를 분류할지 묻는 메시지가 나타납니다. 선택하다일하다.
이 시점에서 회사 LAN에서 클라이언트로 트래픽을 보낼 수 있었지만(netcat을 사용하여 테스트) 핑에 여전히 응답이 없었습니다.
Windows에 ping을 허용하도록 지시(ICMPv4)
Orb 시작 > 고급 보안이 포함된 Windows 방화벽 그런 다음 인바운드 규칙, 새 규칙...으로 이동합니다.
- 맞춤 규칙
- 모든 프로그램
- 프로토콜: ICMPv4
- 연결을 허용하세요
- 비공개 프로필에 적용
- 이름을 붙이다.
마침내 핑이 반환되었습니다.