UniFi - USG 포트 포워딩 설정과 트러블슈팅¶
download at 2017-04-18T19:38:37Z origin
Overview
이 문서는 UniFi 시큐리티 게이트웨이에서 어떻게 포트 포워딩을 설정하고 동작하지 않을 때 트러블 슈팅하는 방법에 대하여 서술합니다.
포트 포워딩은 하나 이상의 포트를 WAN에서 USG 내부 호스트로 리다이렉션 하는 것을 말합니다. 인터넷에서 서버로 접근하는 가장 일반적인 방법입니다.
Table of Contents
포트 포워딩 환경설정
예제 네트워크 Overview
시작하기 전에 예제를 쉽게 따라하기 위해서 예제의 네트워크가 USG가 WAN으로 연결되어 있고 IP 192.0.2.117 값으로 인터넷 연결이 되어 있다고 가정합니다. UniFi 스위치로 LAN IP 172.16.0.1. 로 연결되어 있으며 LAN은 리눅스 서버로 172.16.0.7의 주소로 웹, SSH 서버가 구동중이다라고 가정합니다.
포트 포워딩 탭 열기
UniFi 보안 게이트웨이 (USG) 포트 포워딩은 컨트롤러의 장치 환경설정 패널에서 설정 가능합니다. 해당 패널로 이동하기 위해서는 다음 과정을 수행합니다:
- Devices 탭을 클릭합니다.
- 원하는 USG를 클릭합니다.
- 환경설정 패널에서 오른쪽의 Detail 탭을 엽니다. Configuration 를 클릭합니다.
- Port Forward 을 클릭하여 확장합니다. 아래의 이미지에 보이는 것과 같이 아무런 포트 포워딩 설저잉 없는 것을 확인할 수 있습니다.
- Create 클릭하여 첫번째 포트 포워딩 설정을 시작합니다.
포트 포워딩 환경설정 필드
포트 포워딩을 위해 필요한 필드는 다음과 같습니다:
Name: 참조 목적의 포트 포워딩 이름 (이름 외의 다른 의미는 없습니다.)
From: 이 필드는 포트 포워딩을 수행하는 시작지 주소를 의미합니다. 인터넷에서 내부 호스트의 어떤 곳이든 서비스를 하고 싶다면, 반드시 "Anywhere"를 선택해야합니다. 포트 포워딩을 수행할 시작지 IP나 네트워크를 제한하고 싶은 경우에는 해당 IP를 명시하는 것이 보안상으로도 좋습니다. 포트 포워딩을 수행 할 시작지 IP를 제한하고 싶다면 "Limited"를 선택하고 포워딩을 하고 싶은 IP 혹은 CIDR 마스크 서브넷(e.g., 100.70.60.0/24)을 입력합니다. 입력을 수행한 특정 IP 혹은 네트워크만 포트 포워딩을 허용합니다.
Note: 다중 시작지 IP 주소 혹은 서브넷을 제한하고 싶다면, 다중 포트 포워딩을 추가할 수 있습니다. "From"에 각각 IP와 서브넷을 추가합니다.
Port: 포트 포워딩을 수행할 external 포트를 필드에 입력합니다. 이 포트는 포워딩될 WAN의 IP의 포트입니다.
Forward IP: 포트 포워딩의 목적지 IP 주소를 입력합니다.
Forward Port: 트래픽이 포워딩될 내부 포트를 입력합니다.
Protocol: 포트 포워딩할 프로토콜을 TCP, UDP 또는 둘다 (Both)로 선택합니다. 대부분의 서비스는 TCP를 사용합니다. TCP, UDP 모두 필요하지 않는한, 둘중 하나를 명시하는 것이 좋습니다.
예제 웹 서버 포트 포워딩
이제 포트 포워딩 탭의 각 필드에 친숙해 졌으니, 포트 포워딩 예제를 생성합니다. 처음에는 리눅스 서버인 172.16.0.7의 HTTP 포트를 개방합니다.(TCP 80 포트)
Apply 버튼을 클릭하여 필드가 되도록합니다. 환경설정이 USG에 프로비저닝 되면, 포트포워딩을 시작합니다. 포트포워딩을 테스트 할 때에는 네트워크 바깥에서 테스트 합니다.
예제 SSH 포트 포워딩
이 예제에서는 외부 2222 포트를 리눅스 서버의 SSH 22번 포트로 포워딩합니다. SSH는 외부에서 내부로 접근하는 가장 일반적인 방법이므로 브루트포스 공격에 취약합니다. 실제 보안사항에서는 이렇게 설정하지 않지만(포트 스캐닝을 통해서 포트 포워딩과 관계없이 탐색하여 공격을 수행합니다.), 인증 오류와 같은 스팸 로그량을 줄이는 것에는 도움을 줄 수 있습니다. 시작지 주소 IP 또는 네트워크를 제한하는 것은 좋은 방법이지만, SSH 퐅르르 사용해야 한다면, 다른 방법을 사용해야 합니다.
Apply 버튼을 클릭하여 프로비저닝을 수행합니다. 프로비저닝 이후에는 인터넷에서 리눅스 서버인 192.0.2.117의 포트 2222로 접근 가능합니다.
포트 포워딩 리스트 뷰
이제 포트 포워딩 패널에서는 2개의 환경 설정 엔트리를 확인할 수 있습니다:
연필 아이콘을 클릭하여 수정할 수 있고, 휴지통 아이콘을 클릭하여 삭제할 수 있습니다.
Note: 수정, 삭제 버튼이 보이지 않는다면 스크롤바를 맨 밑으로 이동하여 보십시오. 아래의 "Showing X-Y of Z records"를 확인 한 뒤 스크롤을 오른쪽으로 이동하여 버튼을 확인할 수 있습니다.
포트 포워딩과 방화벽 룰
컨트롤러의 WAN IN 방화벽 룰에서 포트 포워딩과 관련된 트래픽을 통과시킬 수 있도록 룰을 추가할 수 있습니다.
이 룰들은 포트 포워딩과 연관되어 있고, 포트포워딩에서 해당 설정을 세팅하기 때문에 수정이 불가능합니다. 포트포워딩 룰을 수정, 삭제하면 룰도 따라서 변경됩니다.
포트 포워딩 트러블슈팅
포트 포워딩을 설정한 이후 제대로 동작하지 않는다면, 동작하지 않는 이유가 몇가지 있습니다. 대부분은 USG 바깥의 문제이지만, USG는 문제의 원인을 발견할 수 있는 강력한 도구를 제공합니다.
이 섹션에서는 포트포워딩이 예상한대로 동작하지 않을 때 사용 가능한 트러블 슈팅을 서술합니다.
환경설정 검증 과 테스트 방법론
먼저 포트포워딩 환경설정을 살펴봅니다. IP와 포트 번호에 오타가 있는지 확인합니다. UniFi 컨트롤러는 입력의 유효성 검사를 수행하지 않으므로 입력하기 이전에 주의깊게 살펴야 합니다. IP와 포트가 유효한 값인지 확인합니다.
포트포워딩을 테스트 할 때, 외부(인터넷)에서 테스트 하는 것인지 한번더 확인하십시오. 와이파이를 사용하지 않는 모바일 환경이 좋은 테스트 수단이 될 수 있습니다.
다음은 WAN과 LAN 포인트에서의 트러블 슈팅을 서술합니다.
WAN 트래픽 체크
포트 포워딩을 수행할 때 가장 먼저 해야할 트러블슈팅은 트래픽이 WAN 인터페이스에 도달하는가 입니다. USG의 WAN에 트래픽이 도달하지 않는다면 포워딩도 할 수 없습니다. tcpdump 와 같은 도구를 사용하여 패킷 캡처를 수행하십시오. 캡처할 때 트래픽이 네트워크에서 확인 가능한지 아닌지를 파악합니다. USG의 WAN 인터페이스는 eth0 , Pro에서는 eth2 입니다. 이 예제는 일반 USG를 대상으로 하기 때문에 eth0 을 사용합니다.
필터링을 수행하지 않는다면 tcpdump 결과는 암호화되어 확인하기 어려울 것입니다. 목적지 포트로 필터링을 수행하여 네트워크의 활성화된 트래픽이 무엇인지 확인할 수 있습니다. HTTP 포트 포워딩은 필요없는 노이즈를 제거하기 위해서 조금 더 까다로운 필터링이 필요합니다. 예제에서는 192.0.2.117 (USG WAN IP)의 목적지 호스트와 목적지 포트 80을 dst host 192.0.2.117 과 dst port 80 으로 필터링을 수행합니다.
USG에 SSH 접속을 통해서 다음의 명령어를 수행합니다:
cmb@usg1:~$ sudo tcpdump -ni eth0 dst host 192.0.2.117 and dst port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 17:44:00.904533 IP 198.51.100.114.51514 > 192.0.2.117.80: Flags [S], seq 2179876751, win 29200, options [mss 1460,sackOK,TS val 390060839 ecr 0,nop,wscale 6], length 0
결과 값은 USG WAN IP 192.0.2.117 주소의 포트 80으로 접속하려는 시도가 192.51.100.114에서 있다는 것을 확인할 수 있습니다. (시작지 주소의 포트는 임의의 값이 사용됩니다.) "Flags [S]" 필드는 SYN 패킷임을 의미하며, TCP 핸드셰이킹의 첫번째 패킷임을 알 수 있습니다. WAN으로의 요청이기 때문에 USG에 도달했다는 것을 확인할 수 있습니다. 캡쳐에서 아무것도 보이지 않는다면, 업스트림에서 트래픽이 도달하는 것을 막고있다는 사실을 알 수 있습니다. 아래의 트러블 슈팅가이드에서 "WAN으로 도달하지 않는 트래픽" 섹션을 확인하십시오.
WAN 트래픽을 확인하였다면 다음에는 LAN 트래픽을 검증합니다.
LAN 트래픽 체크
이제 WAN 트래픽을 검증하였으니 다음에는 LAN 트래픽이 LAN 인터페이스로 올바르게 도달하는지 확인합니다. 예제에서는 USG의 LAN 포트가 eth1 인터페이스르 사용합니다. USG pro를 사용한다면 LAN 포트는 eth0 이며, tcpdump 명령어를 수행할 때 해당 부분을 교체하여 입력합니다.
웹서버 내부 IP 포트 80으로 필터링을 수행합니다:
cmb@usg1:~$ sudo tcpdump -ni eth1 host 172.16.0.7 and port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 18:00:38.268095 IP 198.51.100.114.51519 > 172.16.0.7.80: Flags [S], seq 1565978093, win 29200, options [mss 1460,sackOK,TS val 390310233 ecr 0,nop,wscale 6], length 0 18:00:38.268351 IP 172.16.0.7.80 > 198.51.100.114.51519: Flags [R.], seq 0, ack 1565978094, win 0, length 0
WAN에서 캡쳐한것과 같은 SYN 패킷을 확인할 수 있습니다. 목적지 IP가 내부 서버 IP인 172.16.0.7로 변환된 것을 확인할 수 있습니다. 변환된 SYN 패킷은 LAN NIC에서 전송이 이루어졌다는 것은 포트 포워딩이 수행되었다는 것을 의미합니다. 패킷의 응답은 다시 서버로 전송하는데, 서버로 다시 돌아왔다면 이 부분이 문제일 수 있습니다. "Flags [R.]"은 서버가 RST ACK 를 응답으로 전송하는 것을 의미하며, 원격지 호스트에 응답할 포트가 존재하지 않음을 의미합니다. 웹서버를 확인하였을 때 nginx 서비스가 구동되지 않은 것을 확인하였습니다. 웹 서비스르 구동하고 다시 tcpdump 의 출력값을 확인해보면, 더 많은 출력을 확인할 수 있습니다. 성공적으로 연결을 수행했다면 다음의 결과가 출력될 것입니다. 데이터 통신의 양에 따라서 출력의 크기는 다르게 표시됩니다:
18:06:17.151027 IP 198.51.100.114.51523 > 172.16.0.7.80: Flags [S], seq 4065224865, win 29200, options [mss 1460,sackOK,TS val 390394972 ecr 0,nop,wscale 6], length 0 18:06:17.151269 IP 172.16.0.7.80 > 198.51.100.114.51523: Flags [S.], seq 2746330992, ack 4065224866, win 28960, options [mss 1460,sackOK,TS val 232937488 ecr 390394972,nop,wscale 7], length 0 18:06:17.152707 IP 198.51.100.114.51523 > 172.16.0.7.80: Flags [.], ack 1, win 457, options [nop,nop,TS val 390394972 ecr 232937488], length 0 18:06:17.155836 IP 172.16.0.7.80 > 198.51.100.114.51523: Flags [.], ack 110, win 227, options [nop,nop,TS val 232937488 ecr 390394973], length 0 18:06:17.157676 IP 198.51.100.114.51523 > 172.16.0.7.80: Flags [F.], seq 110, ack 1105, win 491, options [nop,nop,TS val 390394974 ecr 232937488], length 0 18:06:17.157904 IP 172.16.0.7.80 > 198.51.100.114.51523: Flags [F.], seq 1105, ack 111, win 227, options [nop,nop,TS val 232937488 ecr 390394974], length 0
가장 일반적인 오류 사레는 LAN 호스트가 포워딩된 트래픽에 응답하지 않는 것입니다. tcpdump 의 결과가 SYN 패킷을 LAN 호스트로 전송하였지만 다른 응답이 오지 않는 것이며, LAN 호스트에 무언가 문제가 있다는 것을 의미합니다. LAN 호스트 응답 없음 섹션을 확인하여 트러블 슈팅을 진행하십시오. tcpdump 명령어의 결과 값은 다음과 같습니다.
xxx18:09:46.403313 IP 198.51.100.114.51525 > 172.16.0.7.80: Flags [S], seq 1697746705, win 29200, options [mss 1460,sackOK,TS val 390447296 ecr 0,nop,wscale 6], length 0 18:09:47.400988 IP 198.51.100.114.51525 > 172.16.0.7.80: Flags [S], seq 1697746705, win 29200, options [mss 1460,sackOK,TS val 390447546 ecr 0,nop,wscale 6], length 0 18:09:49.403930 IP 198.51.100.114.51525 > 172.16.0.7.80: Flags [S], seq 1697746705, win 29200, options [mss 1460,sackOK,TS val 390448047 ecr 0,nop,wscale 6], length 0
WAN으로 도착하지 않는 트래픽
트래픽이 USG WAN 인터페이스에서 보이지 않는다면 무언가 USG 업스트림에서 차단되고 잇는 것입니다. 일반적으로 방화벽이나 다른 패킷 필터가 모뎀에 적용되어잇거나 업스트림 방화벽, 라우터에 문제가 있습니다. 모뎀 메뉴얼을 확인하여 올바르게 설정되었는지 확인합니다.
공통적으로 발생하는 다른 이유는 ISP 가 해당 포트를 차단하는 경우입니다. 상업용 인터넷 서비스는 일반적으로 어떤 포트도 차단하지 않지만, 가장 많이 사용하는 서버의 포트는 차단할 수도 있습니다.
LAN 호스트 응답 없음
LAN의 트래픽이 적절한 목적지로 발송되는 것을 위의 예제에서 확인하였습니다. SYN 패킷이 172.16.0.7 의 80 포트로 전송 되었습니다. 하지만 호스트는 어떠한 이유 때문에 응답을 하지 않았습니다. 일반적으로 호스트의 방화벽이 이 트래픽을 차단했기 때문입니다. 다른 가능한 이유로는 LAN 호스트가 기본 게이트웨이 설정 값이 없거나 다른 시스템의 게이트웨이를 바라보고 있을 때 문제가 발생합니다. USG 포트 포워딩이 올바르게 동작하게 하기 위해서는 USG 내부 IP를 올바르게 설정해야합니다.
관련 문서