공용 Wi-Fi를 사용할 때 개인 정보 보호를 위해 OpenVPN 서버(Debian 8)를 실행하고 있습니다. 따라서 클라이언트의 모든 네트워크 트래픽은 VPN 연결을 통해 처리됩니다. 서버 및 클라이언트 구성은 다음과 같습니다.
서버 구성:
port 1194
proto tcp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
tls-auth /etc/openvpn/tlsauth.key 0
user nobody
group nogroup
server 10.11.12.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
persist-key
persist-tun
comp-lzo
status openvpn-status.log
verb 3
클라이언트 구성:
client
remote X.X.X.X 1194
proto tcp
dev tun
resolv-retry-infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
tls-auth /etc/openvpn/tlsauth.key 0
comp-lzo 0
verb 2
클라이언트에서 VPN 서비스가 시작되면 라우팅 테이블은 아래와 같이 변경됩니다.
라우팅 테이블(192.168.178.0/24는 공용 Wi-Fi를 나타냄):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.11.12.13 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.178.1 0.0.0.0 UG 1024 0 0 wlan0
10.11.12.1 10.11.12.13 255.255.255.255 UGH 0 0 0 tun0
10.11.12.13 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
128.0.0.0 10.11.12.13 128.0.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
X.X.X.X 192.168.178.1 255.255.255.255 UGH 0 0 0 wlan0
openvpn을 시작할 때 syslog의 관련 섹션:
ovpn-client[3395]: OpenVPN 2.3.4 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 1 2014
ovpn-client[3395]: library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
ovpn-client[3395]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
ovpn-client[3395]: Control Channel Authentication: using '/etc/openvpn/tlsauth.key' as a OpenVPN static key file
ovpn-client[3395]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3395]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
ovpn-client[3396]: Attempting to establish TCP connection with [AF_INET]X.X.X.X:1194 [nonblock]
ovpn-client[3396]: TCP connection established with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TCPv4_CLIENT link local: [undef]
ovpn-client[3396]: TCPv4_CLIENT link remote: [AF_INET]X.X.X.X:1194
ovpn-client[3396]: VERIFY OK: depth=1, [...]
ovpn-client[3396]: VERIFY OK: depth=0, [...]
ovpn-client[3396]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
ovpn-client[3396]: [VPN-Server] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TUN/TAP device tun0 opened
ovpn-client[3396]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
ovpn-client[3396]: /sbin/ip link set dev tun0 up mtu 1500
NetworkManager[556]: <info> (tun0): carrier is OFF
NetworkManager[556]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 15)
NetworkManager[556]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/14
ovpn-client[3396]: /sbin/ip addr add dev tun0 local 10.11.12.14 peer 10.11.12.13
NetworkManager[556]: <info> (tun0): link connected
ovpn-client[3396]: ERROR: Linux route add command failed: external program exited with error status: 2
ovpn-client[3396]: GID set to nogroup
ovpn-client[3396]: UID set to nobody
ovpn-client[3396]: Initialization Sequence Completed
NetworkManager[556]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[556]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[556]: <info> Activation (tun0) starting connection 'tun0'
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[556]: <info> devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[556]: <info> device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) started...
NetworkManager[556]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) starting...
NetworkManager[556]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) successful.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager[556]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
NetworkManager[556]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
NetworkManager[556]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[556]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[556]: <info> Activation (tun0) successful, device activated.
내 질문은 다음과 같습니다
라우팅 테이블이 맞나요? 나에게는 두 개의 기본 항목으로 인해 다소 이상해 보입니다. 또한 공용 Wi-Fi 라우터(tcpdump 사용)에서 트래픽을 기록할 때 모든 트래픽이 VPN을 통해 라우팅되는 것은 아닙니다.
ERROR: Linux route add command failed: external program exited with error status: 2syslog의 오류( )는 무엇을 의미합니까 ? 아마도 첫 번째 질문과 연결되어 있지 않을까요?
편집: 답변해 주셔서 감사합니다, Michal. 멀티캐스트/로컬/... 트래픽을 줄이기 위해 추가로 iptables를 사용하여 해당 트래픽도 삭제할 계획입니다.
다음과 같이 iptables 규칙을 사용하려고 합니다.
#!/bin/bash
GATEWAY="192.168.178.1"
iptables -F
# Allow loopback device (internal communication)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow DHCP communication with gateway
iptables -A INPUT -i wlan0 -p udp -s $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p udp -d $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT
# Allow ICMP communication with gateway
iptables -A INPUT -i wlan0 -p icmp -s $GATEWAY/32 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p icmp -d $GATEWAY/32 -j ACCEPT
#Allow VPN establishment
iptables -A OUTPUT -p tcp --dport 1194 -j ACCEPT
iptables -A INPUT -p tcp --sport 1194 -j ACCEPT
#Accept all TUN connections (tun = VPN tunnel)
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
#Set default policies to drop all communication unless specifically allowed
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
IMO, 이러한 규칙은 게이트웨이에서 할당된 IP를 가져오고 OpenVPN 서버에 대한 연결을 설정하고 해당 연결을 통한 모든 트래픽을 처리하는 데 충분해야 합니다. 그러나 VPN 연결도 사용해야 하지만 DNS는 작동하지 않습니다. 왜 작동하지 않나요?
dnsmasq다음 편집: VPN 서버에 로컬 네임서버( )를 설정합니다 . 서버 구성이 다음으로 변경되었습니다.
push "dhcp-option DNS 10.11.12.1"
대신에
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
dig +short serverfault.com @10.11.12.1VPN 서버 자체에서 실행할 때 호스트 이름을 성공적으로 검색할 수 있습니다. VPN( )을 사용하지 않는 다른 호스트에서 명령을 실행하는 경우에도 dig +short stackoverflow.com @X.X.X.X호스트 이름을 성공적으로 검색할 수 있습니다. 그러나 VPN에 연결된 클라이언트에서 명령이 실행되지 않으면( dig +short stackoverflow.com @10.11.12.1) 명령이 실패합니다( ;; connection timed out; no servers could be reached). 왜? Iptables는 모두 허용으로 설정됩니다.
답변1
- 라우팅 테이블은 괜찮은 것 같습니다. 측정항목 열을 확인하세요. 측정항목이 가장 낮은 경로가 선호됩니다. 라우팅 테이블에는 이제 두 개의 기본 경로가 포함되어 있으며 낮은 메트릭으로 인해 192.168.178.1보다 10.11.12.13이 선호됩니다. 물리적 인터페이스의 트래픽 정보 브로드캐스트/멀티캐스트 트래픽에 응답하는 청취 서비스가 있기 때문에 이는 정상적인 현상이기도 합니다. 이 트래픽은 VPN 인터페이스를 통해 이동할 수 없습니다. 이는 또한 로컬 네트워크를 사용하여 작업 속도를 높이는 일부 애플리케이션(예: dropbox, teamviewer, upnp, Microsoft 네트워크 환경 및 기타 여러 기능)의 표시이기도 합니다.
- 아마도 /sbin/route 또는 /usr/sbin/route에는 무언가를 할 수 있는 권한이 없었을 것입니다. 구성 파일의 지시어를 사용하여 openvpn의 서비스 권한을 사용자 none에게 떨어뜨렸기 때문입니다. 다시 연결한 후에는 그런 일에 대해 소리칠 수 있습니다. . 특히 서버 구성을 변경하고 전체 권한으로 클라이언트를 수동으로 다시 시작하지 않는 경우. 그것도 정상입니다.
추신. IP 주소로 원격을 사용하는 경우 resolv-retry-infinite가 필요하지 않습니다. 이는 의미가 없습니다.
편집: iptables 구성 나는 그것이 cleint의 iptables 구성이라고 가정합니다.
- NAT 테이블도 플러시해야 합니다.
iptables -F -t nat
- 다음 두 가지 이유로 인해 DHCP 통신에 대한 규칙이 필요하지 않습니다.
- DHCP 서비스는 일반적으로 iptables에서 다루지 않는 소위 원시 소켓을 사용합니다(지난번 확인했을 때 dhcpd, dhcpcd가 이를 사용하고 있었습니다).
- DHCP 메커니즘은 OpenVPN 프로토콜에서 구현되므로 실제 DHCP 통신이 없습니다. 즉, DHCP Rrequest, DHCP Offer, DHCP ACK, DHCP Pack을 의미합니다.
- TCP 모드에서 OpenVPN을 사용하는 것은 좋지 않습니다.http://sites.inka.de/bigred/devel/tcp-tcp.html
- 질문을 편집하고 다음 사항에 대해 알려주세요.
- 클라이언트(터널 통신)에서 VPN 서버(VPN IP 주소)를 ping할 수 있나요?
- 서버에서 netstat -l -u -n -p를 보여주세요(dnsmasq 데몬이 tun 인터페이스를 수신하고 있는지 알아야 합니다).
- VPN이 설정된 후 8.8.8.8에 ping을 보낼 수 있나요?