SoftEther SecureNAT: DHCP와 NAT는 두 가지 결정

SecureNAT는 가상 DHCP와 가상 NAT를 실행하며, 각각 따로 실패할 수 있습니다. 허브를 탓하기 전에 임대, 그다음 외부 경로와 리졸버를 확인하세요.

SecureNAT는 하나의 체크박스로 두 서비스를 켜며, 이 기능에 대한 혼란의 대부분이 여기서 나옵니다. 가상 DHCP 서버는 클라이언트에 주소, 마스크, 게이트웨이, 그리고 종종 리졸버를 제공합니다. 가상 NAT는 서버 호스트 자체의 네트워크 스택을 사용해 그 게이트웨이 너머로 패킷을 전달합니다. 두 서비스는 설정에서 나란히 있고 독립적으로 실패합니다. 클라이언트가 완벽한 임대를 받고도 동작하는 경로가 없을 수 있고, 경로는 동작하지만 설정이 잘못된 리졸버를 가리킬 수도 있습니다. 이들을 두 가지 결정으로 검증하면 진단이 짧아집니다.

하나의 체크박스 뒤에 있는 두 서비스

가상 DHCP 쪽은 설정 질문에 답합니다. 이 클라이언트가 이 가상 허브 안에서 어떤 설정을 받는가. 가상 NAT 쪽은 전달 질문에 답합니다. 클라이언트가 허브 밖 주소로 패킷을 보낼 때 서버가 이를 변환해 전달하는가. 전자는 허브에 국한되며 상위 네트워크가 필요 없습니다. 후자는 전적으로 호스트에 달려 있습니다.

가상 호스트 인터페이스는 두 번째가 아니라 첫 번째 결정에 속합니다. 그 주소는 흔히 기본값으로 192.168.30.1 같은 것인데, DHCP 서비스가 제공하는 게이트웨이입니다. 서버의 공용 수신 주소가 아니며, 둘을 혼동하면 그 네트워크에 존재하지 않는 기계를 향한 방화벽 규칙과 클라이언트 설정이 생깁니다.

결정 1: 주소를 누가 공급하는가

가상 DHCP가 켜져 있으면 클라이언트는 설정한 풀에서 임대를 받아야 하며, 게이트웨이는 가상 호스트 인터페이스, 리졸버는 지정한 것이어야 합니다. 클라이언트의 상태 문구가 아니라 임대를 확인하세요. «연결됨»은 터널을 설명할 뿐 주소 할당을 뜻하지 않습니다.

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

다른 것을 디버깅하기 전에 알아 둘 실패 유형이 두 가지 있습니다. 이전 설계에서 남은 고정 주소를 가진 클라이언트는 그 주소를 유지하고 임대를 무시하며, 이는 DHCP가 응답을 거부하는 것처럼 보입니다. 그리고 브리지된 세그먼트에 두 번째 DHCP 원본이 있으면 같은 클라이언트를 두고 경쟁해 주소가 간헐적으로 바뀌고, 문제를 재현할 수 없는 지원 대기가 생깁니다.

풀 중복도 여기에 해당합니다. 가상 DHCP 풀이 호스트의 LAN 서브넷이나 다른 허브의 풀과 겹치면 클라이언트는 모호하게 라우팅되는 주소를 받고, 이후의 모든 시험은 결론을 내지 못합니다.

결정 2: 가상 게이트웨이 너머로 누가 전달하는가

가상 NAT가 켜져 있으면 허브에서 나가는 트래픽을 서버가 변환해 호스트의 라우팅 테이블로 보냅니다. 즉 전달 사슬은 클라이언트에서 가상 게이트웨이로, 가상 NAT에서 호스트 스택으로, 호스트 스택에서 기본 경로로 이어집니다. 각 고리는 다른 고리를 건드리지 않고도 끊어질 수 있으며, 실패의 흔적은 서로 다릅니다.

두 번째 결정은 허브를 반드시 떠나야 하는 것으로 시험하세요. 허브 안에 있는 것으로는 안 됩니다. 가상 게이트웨이에 핑을 보내는 것은 첫 고리만 증명할 뿐입니다.

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

이름 해석은 되는데 공용 주소로의 연결이 실패한다면 DHCP가 아니라 전달 사슬에 있는 것입니다. 둘 다 실패하면 먼저 리졸버를 확인하세요. 도달할 수 없는 내부 주소로 밀어 넣은 리졸버는 동작하는 경로도 완전히 끊긴 것처럼 보이게 합니다.

SecureNAT의 전달은 서버 프로세스가 구현하며, 브리지와 함께 쓰는 커널 전달 경로가 아닙니다. 편리하지만 브리징보다 느리고, 호스트 자체의 방화벽 규칙과 라우팅 결정이 변환된 트래픽에도 그대로 적용된다는 뜻이기도 합니다. 가상 NAT는 호스트의 정책을 우회하지 않고 그것을 사용합니다.

호스트 자체의 경로는 세 번째 문제

위의 모든 것은 서버 호스트가 목적지에 도달할 수 있다고 가정합니다. 동작하는 상위 경로가 없거나, 외부 정책이 제한적이거나, 해당 주소 체계가 없는 호스트는 허브 설정이 아무리 정확해도 두 번째 결정에서 실패합니다. SoftEther 탓으로 돌리기 전에 호스트를 터널 밖에서 따로 확인하세요.

SecureNAT는 서버에 연결된 모든 네트워크에 도달할 권한도 아닙니다. 자신에게 도달한 트래픽을 변환하고 전달할 뿐이며, 호스트가 무엇에 도달해도 되는지는 여전히 호스트의 방화벽과 라우팅 일입니다. 터널에 접근 부여를 맡기는 설계는 잘못된 규칙 하나만으로 과도하게 허용하게 됩니다.

주소 체계는 별도의 확인이 필요합니다. 동작하는 IPv4 DHCP 예시는 빌드에 모든 IPv6 기능이 있다는 것을 증명하지 않으므로, 이중 스택 동작을 약속하기 전에 실제로 실행하는 버전의 설명서를 읽으세요. 설명서의 SecureNAT 절은 현재 릴리스의 가상 NAT와 DHCP 기능을 다룹니다.

각 결정을 그 자체의 시험으로 검증하세요

첫 번째 결정은 임대 확인으로 받아들이세요. 풀 안의 주소, 가상 호스트 인터페이스와 같은 게이트웨이, 설정한 리졸버. 두 번째는 클라이언트에서 나가는 요청과 서버의 NAT 테이블 확인으로 받아들이세요. 세션 수가 늘어나는 것만이 변환이 실제로 일어나고 있음을 보여 주는 유일한 직접 증거입니다.

그다음 분리를 설계 메모에 기록하세요. 어느 구성 요소가 주소를 공급하고, 어느 구성 요소가 전달하며, 트래픽이 어느 호스트 인터페이스로 나가는지. 재시작이 동작을 바꾸면 그 메모가 셋 중 무엇을 볼지 알려 줍니다. 모두 재시작하고 증상이 옮겨 가기를 바랄 필요가 없습니다.

또 하나의 결정도 기록에 남겨야 합니다. 오늘 내리지 않더라도. SecureNAT와 로컬 브리지는 같은 허브에 대한 서로 다른 설계이며, 둘 다 필요한 허브는 다른 계획이 필요한 허브입니다. 의도적으로 선택하고 이유를 적어 두면, 다음 사람이 실행 중인 설정에서 역으로 추론할 필요가 없습니다.

관련 글