OpenVPN의 네트워크 구성
지난 글에서 설명한,
윈도우에 OpenVPN 설치 - 서버 측 구성
; https://www.sysnet.pe.kr/2/0/12224
윈도우에 OpenVPN 설치 - 클라이언트 측 구성
; https://www.sysnet.pe.kr/2/0/12225
방식으로 설치했으면 VPN 서버와 그 서비스에 접속한 클라이언트 PC는 다음과 같은 네트워크 구성을 갖게 됩니다.
OpenVPN은 저 그림에서 "VPN이 제공하는 가상 네트워크: 10.8.0.0"을 제공하기 위해 서버와 클라이언트 모두에 제품 설치 시 "TAP-Windows Adapter V9"이라는 Network Adapter를 생성합니다. (제어판의 "Network Connections"에서 확인할 수 있습니다.)
실제로 VPN 서버와 클라이언트 PC에서 ipconfig을 실행해 보면 각각의 네트워크 환경이 나옵니다.
// [서버]
C:\> ipconfig
Windows IP Configuration
...[생략]...
Unknown adapter Local Area Connection:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::a135:b01c:66f4:5d58%10
IPv4 Address. . . . . . . . . . . : 10.8.0.1
Subnet Mask . . . . . . . . . . . : 255.255.255.252
Default Gateway . . . . . . . . . :
...[생략]...
// [클라이언트]
C:\>ipconfig
Windows IP Configuration
...[생략]...
Unknown adapter Local Area Connection:
Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::2143:82b7:fd24:b855%89
IPv4 Address. . . . . . . . . . . : 10.8.0.6
Subnet Mask . . . . . . . . . . . : 255.255.255.252
Default Gateway . . . . . . . . . :
...[생략]...
따라서, (방화벽에서 Ping 허용이 되었다면) 서버는 클라이언트에게 ping 10.8.0.6으로, 클라이언트는 서버에게 ping 10.8.0.1로 접근 여부를 쉽게 확인할 수 있습니다.
그렇다면 이제 통신은 어떤 식으로 이뤄질까요? 이에 대한 힌트를, OpenVPN의 클라이언트 측에서 접속했을 때 출력한 로그를 통해 알 수 있습니다.
...[생략]...
Thu Jun 11 09:42:24 2020 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.5
...[생략]...
(클라이언트 측의) openvpn.exe가 실행하는 위의 명령어로 인해 (클라이언트 측의) 윈도우 운영체제에는 다음과 같은 route 테이블이 구성됩니다.
C:\> route PRINT -4
===========================================================================
Interface List
...[생략]...
79...00 ff ed bb 9a ae ......TAP-Windows Adapter V9
...[생략]...
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.19 291
10.8.0.0 255.255.255.0 10.8.0.5 10.8.0.6 25
10.8.0.4 255.255.255.252 On-link 10.8.0.6 281
10.8.0.6 255.255.255.255 On-link 10.8.0.6 281
10.8.0.7 255.255.255.255 On-link 10.8.0.6 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
...[생략]...
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
...[생략]...
===========================================================================
이로 인해 클라이언트 측에서는 "10.8.0.0" 관련 패킷이 발생하는 경우 "10.8.0.6" 주소를 소유한 Network Adapter(TAP-Windows Adapter V9)가 통신을 담당하게 됩니다. 하지만, 그 외의 주소에 대한 통신은 "192.168.0.19" 주소를 소유한 기존 Network Adapter가 처리합니다.
이런 상황에서는 웹 브라우저를 이용해 10.8.0.0 이외의 사이트에 접속하는 경우 클라이언트 측의 기존 네트워크 망을 이용해 통신을 하게 되고, 예를 들어 "
https://ipconfig.tools/en/"과 같은 사이트를 방문하게 되면 보이는 IP 주소가 OpenVPN을 사용하기 전과 달라지는 것이 없습니다.
물론, 대개의 경우 위와 같은 네트워크 구성은 VPN을 사용하려는 목적에 부합합니다. 하지만, 때로는 모든 통신을 VPN 서버 측의 네트워크로 라우팅 되는 것을 원할 수도 있습니다. (예를 들어,
비주얼 스튜디오의 업데이트 속도를 빠르게 하기 위해 VPN 서버 측의 네트워크를 사용하고 싶을 수 있습니다.)
이러한 구성을 OpenVPN에서 하려면, 서버 측의 server.ovpn 파일에 다음의 구성을 활성화해야 합니다
push "redirect-gateway def1 bypass-dhcp"
위의 설정으로 변경하고, 서버 측 OpenVPN을 다시 실행한 후, 클라이언트 측에서 연결을 다시 하면 이번에는 클라이언트 측의 연결 로그에 다음과 같은 route 명령어를 볼 수 있습니다.
Thu Jun 11 10:02:42 2020 C:\WINDOWS\system32\route.exe ADD 52.231.8.55 MASK 255.255.255.255 192.168.0.1
Thu Jun 11 10:02:42 2020 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4
Thu Jun 11 10:02:42 2020 Route addition via IPAPI succeeded [adaptive]
Thu Jun 11 10:02:42 2020 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.5
Thu Jun 11 10:02:42 2020 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Thu Jun 11 10:02:42 2020 Route addition via IPAPI succeeded [adaptive]
Thu Jun 11 10:02:42 2020 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.5
Thu Jun 11 10:02:42 2020 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Thu Jun 11 10:02:42 2020 Route addition via IPAPI succeeded [adaptive]
Thu Jun 11 10:02:42 2020 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.5
Thu Jun 11 10:02:42 2020 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
Thu Jun 11 10:02:42 2020 Route addition via IPAPI succeeded [adaptive]
이로 인해 라우팅 테이블의 설정이 바뀌는데,
C:\> route PRINT -4
===========================================================================
Interface List
89...00 ff ed bb 9a ae ......TAP-Windows Adapter V9
...[생략]...
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.19 291
0.0.0.0 128.0.0.0 10.8.0.5 10.8.0.6 25
10.8.0.0 255.255.255.0 10.8.0.5 10.8.0.6 25
10.8.0.4 255.255.255.252 On-link 10.8.0.6 281
10.8.0.6 255.255.255.255 On-link 10.8.0.6 281
10.8.0.7 255.255.255.255 On-link 10.8.0.6 281
...[생략]...
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
...[생략]...
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
...[생략]...
===========================================================================
보는 바와 같이 "Destination"의 설정에 "0.0.0.0" 항목이 2개로 늘어났는데 "10.8.0.6" Interface의 Metric이 "192.168.0.19"가 가진 291
보다 낮은 25로 설정되어 우선순위가 더 높아졌습니다.
그렇다면, 이제 웹 브라우저 등을 이용해 서버에 접속하려고 하면 "10.8.0.6"이 속한 네트워크로의 우선순위가 높아져 그쪽으로 패킷이 흐르게 됩니다. 하지만, 여기서 문제가 하나 발생합니다. VPN 서버는 "10.8.0.0" 네트워크로 흘러 들어오는 패킷을 자신이 기존에 속한 네트워크로 라우팅 하지는 않는다는 점입니다.
따라서, 이로 인해 "push "redirect-gateway def1 bypass-dhcp" 설정이 적용된 OpenVPN 네트워크에서는 클라이언트 측의 컴퓨터에서 웹 브라우징 등이 안 되는 문제가 발생합니다. (사실 설정에 따른 것이므로, 이것은 문제라고 볼 수 없고 의도된 현상입니다.)
이 문제를 해결하려면, VPN 서버 측에서 "10.8.0.0"으로 흘러온 패킷을 VPN 서버의 또 다른 네트워크 어댑터 - 즉, 인터넷이 연결된 네트워크 어댑터로 흘러들어가도록 만들어야 하고, 이것을 쉽게 할 수 있는 것이 바로 "ICS (Internet Connection Sharing)"를 설정하는 것입니다.
아래의 그림은,
VPN 서버 측에서 인터넷과 연결된 "Ethernet 2" 어댑터의 속성 창을 통해 ICS를 활성화시켜 "TAP-Windows Adapter V9"으로부터의 라우팅을 허용하게 만듭니다. 이렇게 구성이 되면, 웹 브라우저를 실행해 외부 사이트에 접속하는 경우, 가령 "
https://ipconfig.tools/en/" 등의 사이트를 방문하면 사용된 IP 주소가 VPN 서버 측의 IP인 것을 확인할 수 있습니다.
참고로, OpenVPN의 문제인지 ICS의 문제인지는 알 수 없으나 종종 클라이언트에서의 인터넷 접속이 잘 안 될 때가 있습니다. 그런 경우에는 서버 측의 ICS를 재활성하든가, 클라이언트 측의 VPN 접속을 다시 해보면 잘 되기도 합니다. (불안정한 원인을 잘 모르겠군요. ^^)
게다가 이론상 ICS로 인해 클라이언트 측의 네트워크 동작에 문제가 없어야 하는 것이 맞지만 웬일인지 오피스 제품의 Outlook을 실행했을 때 첫 화면에서 "We are unable to connect right now. Please check your network and try again later."라는 오류가 발생하는 걸로 봐서 100% 안정적인 통신이 보장된다고 볼 수 없습니다.
마지막으로, ICS와 함께 Bridge로 엮은 구성을 다룬 다음의 글을 소개하며 글을 마칩니다. ^^
Hyper-V Internal 네트워크 VM 의 인터넷 접속
; https://www.sysnet.pe.kr/2/0/1335
Hyper-V의 네트워크 유형 (2)
; https://www.sysnet.pe.kr/2/0/915
따지고 보면, OpenVPN의 네트워크 구성과 "
Hyper-V Internal 네트워크 VM 의 인터넷 접속" 글에서 다룬 네트워크 구성은 다를 바 없습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]