VPN을 통해 모든 트래픽을 리디렉션하고 싶지만 전혀 작동하지 않습니다.
섬기는 사람:RT-N16 [TomatoUSB v1.28.0000 MIPSR2-112 K26 USB AIO]
고객: 우분투 14.04.1
서버 구성:
# 자동으로 생성된 구성 악마 서버 10.8.0.0 255.255.255.0 원시 TCP 서버 포트 9999 tun21 개발 비밀번호AES-256-CBC 비교번호 활동적으로 지내기 15 60 동사 3 "경로 192.168.1.0 255.255.255.0"을 누릅니다. "dhcp -options DNS 192.168.1.1" 푸시 "리디렉션 게이트웨이 def1"을 누르십시오. ca.crt DH-PEM 인증서 서버.crt 키서버.키 상태 버전 2 상태 상태 # 사용자 정의 구성(이 부분이 주요 수정 사항인 것 같습니다): 고객 대 고객 "comp-lzo"를 누르세요. "리디렉션 게이트웨이"를 누르세요.
서버: ( iptables -L -t nat -n그냥 POSTROUTING 출력 체인)
체인 POSTROUTING(정책 승인) 대상 보호 선택 소스 대상 모두 변장 -- 0.0.0.0/0 0.0.0.0/0 SNAT 모두 -- 192.168.1.0/24 192.168.1.0/24 ~: 192.168.1.1
서버 로그:
2월 4일 21:19:38 r daemon.notice openvpn[1072]: [AF_INET]192.168.1.4:58170과 TCP 연결 설정 중 2월 4일 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 TLS: [AF_INET]의 초기 패킷 192.168.1.4:58170, sid=00fe6a02 33820233 2월 4일 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 확인 정상: XXXXXXXXXXXXXXXXXX 2월 4일 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 확인 정상: XXXXXXXXXXXXXXXXXX 2월 4일 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 데이터 채널 암호화: 256비트 키로 초기화된 암호 "AES-256-CBC" 2월 4일 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 데이터 채널 암호화: 160비트 메시지 해시 "SHA1"을 사용한 HMAC 인증 2월 4일 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 데이터 채널 복호화: 256비트 키를 사용하여 비밀번호 "AES-256-CBC" 초기화 2월 4일 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 데이터 채널 복호화: 160비트 메시지 해시 "SHA1"을 사용한 HMAC 인증 2월 4일 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 제어 채널: TLSv1, 비밀번호 TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048비트 RSA 2월 4일 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 [클라이언트] [AF_INET] 192.168.1.4:58170을 사용하여 피어 연결 시작 2월 4일 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI_sva: 풀에서 IPv4=10.8.0.6, IPv6=(활성화되지 않음)을 반환했습니다. 2월 4일 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI: 학습: 10.8.0.6 -> client/192.168.1.4:58170 2월 4일 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI: client/192.168.1.4:58170: 기본 가상 IP 10.8.0.6 2월 4일 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 PUSH: 수신된 제어 메시지: 'PUSH_REQUEST' 2월 4일 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 send_push_reply(): safe_cap=940 2월 4일 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 SENT CONTROL [클라이언트]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1, 리디렉션- 게이트웨이 def1, 경로 10.8.0.1, 토폴로지 net30, ping 15, ping-restart 60, ifconfig 10.8.0.6 10.8.0.5'(상태 = 1)
클라이언트 구성:
고객 원격 192.168.1.1 9999 ca.crt 인증서 클라이언트.crt 키클라이언트.키 비밀번호AES-256-CBC 카파툰 원시TCP 노바인더 인증 노캐시 스크립트 보안 2 영구 키 주장하다 사용자 없음 그룹 그룹 없음
클라이언트: ( netstat -nrVPN 활성화됨):
커널 IP 라우팅 테이블 대상 게이트웨이 Genmask 플래그 MSS 창 irtt Iface 0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0 10.8.0.1 10.8.0.5 255.255.255.255 윽 0 0 0 tun0 10.8.0.5 0.0.0.0 255.255.255.255 어 0 0 0 tun0 128.0.0.0 10.8.0.5 128.0.0.0UG 0 0 0 tun0 192.168.1.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 유 0 0 0 wlan0 192.168.1.1 192.168.1.1 255.255.255.255 윽 0 0 0 wlan0
클라이언트 로그:
Wed Feb 4 21:32:24 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] 2014년 12월 1일 구축 2015년 2월 4일 수요일 21:32:24 경고: 서버 인증서 확인 방법이 활성화되지 않았습니다. 자세한 내용은 http://openvpn.net/howto.html#mitm을 참조하세요. 2015년 2월 4일 수요일 21:32:24 참고: UID/GID 다운그레이드는 --client, --pull 또는 --up-delay에 의해 지연됩니다. 2015년 2월 4일 수요일 21:32:24 [AF_INET]192.168.1.1:9999 [nonblock]과 TCP 연결 설정을 시도했습니다. 2015년 2월 4일 수요일 21:32:25에 [AF_INET]192.168.1.1:9999와 TCP 연결을 설정했습니다. 2월 4일 수요일 21:32:25 2015 TCPv4_CLIENT 로컬 링크: [undef] 2015년 2월 4일 수요일 21:32:25 TCPv4_CLIENT 링크 원격: [AF_INET]192.168.1.1:9999 Wed Feb 4 21:32:26 2015 [zais.dnsd.me] [AF_INET]192.168.1.1:9999를 사용하여 피어 연결 시작 2015년 2월 4일 수요일 21:32:29 TUN/TAP 장치 tun0이 열렸습니다. 2월 4일 수요일 21:32:29 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 2015년 2월 4일 수요일 21:32:29 /sbin/ip 링크 설정 dev tun0 up mtu 1500 2월 4일 수요일 21:32:29 2015 /sbin/ip 주소 추가 dev tun0 로컬 10.8.0.6 피어 10.8.0.5 2월 4일 수요일 21:32:29 2015 GID가 그룹 없음으로 설정됨 2015년 2월 4일 수요일 21:32:29 UID가 없음으로 설정됨 2015년 2월 4일 수요일 21:32:29 초기화 시퀀스 완료 2015년 2월 4일 수요일 21:32:43 TUN/TAP 쓰기: 잘못된 매개변수(코드=22) 2015년 2월 4일 수요일 21:32:58 TUN/TAP 쓰기: 잘못된 매개변수(코드=22) 2015년 2월 4일 수요일 21:33:13 TUN/TAP 쓰기: 잘못된 매개변수(코드=22) 2015년 2월 4일 수요일 21:33:28 TUN/TAP 쓰기: 잘못된 매개변수(코드=22)
고쳐 쓰다:도와 주셔서 감사합니다. VPN이 현재 작동 중입니다(어떻게 작동하는지 확실하지 않지만 실제로 작동하려면 연결 후 약 5분 정도 기다려야 합니다. CPU/MEM이 충분하지 않은 등 라우터의 제한 때문일 수 있습니다).
답변1
어떤 이유로 터널이 열려 있는 동안 클라이언트는 현재 기본 경로를 삭제할 수 없으므로 라우팅 테이블에 두 개의 기본 경로가 생성됩니다.
터널이 나타나기 전에 현재 경로에 대해 더 낮은 메트릭(더 높은 숫자)을 지정하기만 하면 됩니다. Route -n 명령을 사용하여 측정항목을 볼 수 있습니다.
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.3.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0
9.15.64.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
0.0.0.0 9.15.64.1 0.0.0.0 UG 0 0 0 eth0
예를 들어, WLAN 인터페이스의 메트릭은 20이고 터널 경로의 메트릭은 0입니다. 귀하의 교통은 모두 터널을 따라 라우팅됩니다.
인터페이스에서 메트릭을 구성하려면 /etc/sysconfig/network-scripts 디렉터리에서 wlan 인터페이스 파일을 열고 METRIC=20이라는 매개변수를 추가하면 됩니다.
이 작업이 가능해야 합니다. 나중에 Route -n 명령을 사용하여 확인하십시오.
고쳐 쓰다:
이제 올바른 기본 경로가 있으므로 tcpdump 및 ping을 사용하여 문제를 해결할 차례입니다. 예를 들어, 다음 명령을 시도하고 원격 네트워크에 대해 몇 가지 ping을 수행해 보십시오.
# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
09:59:13.591764 IP 192.168.4.190 > 192.168.3.1: ICMP echo request, id 3154, seq 4, length 64
09:59:13.681290 IP 192.168.3.1 > 192.168.4.190: ICMP echo reply, id 3154, seq 4, length 64
09:59:14.592829 IP 192.168.4.190 > 192.168.3.1: ICMP echo request, id 3154, seq 5, length 64
09:59:14.680878 IP 192.168.3.1 > 192.168.4.190: ICMP echo reply, id 3154, seq 5, length 64
내 생각엔 에코 요청은 볼 수 있지만 에코 응답은 볼 수 없을 것 같습니다. 이는 원격 끝점이 패킷을 다시 라우팅하지 않음을 의미합니다. 또한 서버 구성 파일에서 라우팅을 수정해야 합니다.
업데이트 2
클라이언트가 터널을 통해 패킷을 라우팅하고 있다는 것이 tcpdump에서 분명하므로 문제는 패킷을 다시 라우팅하지 않는 원격 측에 있습니다.
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
09:19:28.964361 IP 10.8.0.6.57394 > 192.168.1.1.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
09:19:28.964382 IP 10.8.0.6.57394 > 8.8.8.8.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
09:19:28.964398 IP 10.8.0.6.57394 > 8.8.4.4.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
라우팅 테이블에 무슨 일이 일어나고 있는지 확인하려면 각 홉을 확인해야 합니다. 192.168.1.1부터 시작됩니다. 10.8.0.6으로 전송된 패킷을 어디로 라우팅할지 알고 있습니까?