SoftEther 로컬 브리지와 SecureNAT: 무엇을 켤까

SoftEther Manager를 열면 허브에 관한 첫 번째 진짜 결정은 체크박스가 아니라 토폴로지 문제입니다. 로컬 브리지는 그 허브를 물리 어댑터에 연결하고 기존 세그먼트가 주소를 공급하게 하며, SecureNAT는 허브에 자체 가상 라우터와 NAT, DHCP를 부여합니다. 둘 중 하나를 고르면 주소가 어디서 오는지, 어느 장치가 그 주소를 책임지는지가 달라집니다. 둘 다 켜 놓고 하나가 이기기를 바라는 것은 작동하던 랩이 지원 스레드가 되는 길입니다.

실제로 편집하고 있는 허브에서 시작하십시오

Manager는 서버와 허브의 트리를 보여 주는데, 클라이언트가 다른 이름의 허브에 연결되는데 기본 허브를 설정해 버리기 쉽습니다. 허브를 클릭해 이름을 읽고, 그 아래 나열된 세션이 서비스하려는 클라이언트인지 확인하십시오. 이 한 번의 확인이 나중에 프로토콜 탓으로 돌아가는 혼란의 대부분을 막습니다.

다음으로 클라이언트가 먼 쪽 끝에서 무엇을 필요로 하는지 결정하십시오. 브로드캐스트와 LAN 서비스를 동반한 공유 이더넷 동작은 브리지를 가리키고, 작은 주소 범위로 라우팅되는 사설 접근은 SecureNAT를 가리키며, 인터넷 출구는 두 구성 모두 서툴게 감당할 수 있는 라우팅 결정입니다.

무엇이든 클릭하기 전에 답을 적어 두십시오. 두 설정은 서로 바꿀 수 없고 되돌리는 데 결정하는 것보다 오래 걸리며, 이 분짜리 기록이 한 시간의 재연결을 아낍니다.

로컬 브리지가 주소 지정에 하는 일

로컬 브리지는 허브를 물리 어댑터에 연결하므로 허브는 그 이더넷 세그먼트의 일부가 됩니다. 클라이언트는 이미 세그먼트를 맡고 있는 대상에게서 주소를 받고, 게이트웨이는 세그먼트의 라우터가 됩니다. 클라이언트 입장에서는 사무실 LAN에 들어온 것이며, 그에 따르는 모든 도달성과 모든 노출을 함께 집니다.

이는 브리지에 적절한 드라이버 지원을 갖춘 실제 어댑터가 필요하고, 관리자가 그 세그먼트를 확장할 권한을 가져야 한다는 뜻입니다. VPN 로그인은 인증을 증명할 뿐 운영 VLAN에 호스트를 두는 권리를 증명하지 않습니다. 드라이버 이름이 의도한 어댑터와 맞는지 확인하십시오. 잘못된 포트를 브리지하면 세그먼트가 곧바로 내려가며, 어댑터 목록이 비어 있거나 브리지가 실패를 보고하면 원인은 보통 드라이버나 권한이고 암호가 아닙니다.

그래픽 트리가 모호할 때는 명령줄에서 브리지 표를 읽으십시오. 출력은 어댑터 이름을 알려 주지만 트리는 늘 그렇지 않습니다.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

세션이 연결된 채 브리지 목록이 비어 있다는 것은 클라이언트가 가상 허브 안에 있고 아직 아무것도 그것을 세그먼트로 확장하지 않는다는 유용한 그림입니다.

SecureNAT가 더하는 것과 감추는 것

SecureNAT는 허브에 가상 라우터와 NAT 기능, DHCP 서비스를 제공하며 모두 SoftEther 프로세스 안에 있습니다. 클라이언트는 가상 DHCP 범위에서 주소를 받고, 가상 라우터가 기본 게이트웨이를 맡고, 외부로 나가야 하는 트래픽은 변환됩니다. 물리 어댑터는 관여하지 않으므로 NIC 하나와 스위치 설정이 없는 호스트에서도 동작합니다.

대가는 가상 주소가 허브에 속하고 다른 무엇에도 속하지 않는다는 점입니다. 사무실 LAN의 머신은 도움 없이 클라이언트의 SecureNAT 주소로 라우팅할 수 없고, 출발지 주소를 기록하는 모든 것은 SoftEther 호스트의 변환된 주소를 봅니다. 접근 규칙이나 감사 추적이 클라이언트의 실제 주소에 의존한다면 그것은 세부 사항이 아니라 설계 변경입니다. 출발지 주소 규칙이 클라이언트를 아예 볼 수 있는지도 이것이 결정합니다.

DHCP 서버이기도 합니다. 이미 하나가 있는 세그먼트에서 돌리거나 같은 시점에 그 세그먼트를 브리지하면 응답자가 둘이 되고 임대가 예측 불가능해집니다. 설명서가 두 기능을 별개의 선택으로 다루는 이유가 바로 이것입니다.

다른 무엇을 켜기 전에 허브가 지금 무엇을 서비스하는지 확인하십시오. 각 명령은 의도가 아니라 현재 상태를 출력합니다.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

하나를 켜면서 다른 하나를 깨지 않기

구성을 고르고 켜고, 다른 하나는 끈 채로 두십시오. 브리지와 SecureNAT가 모두 활성인 허브는 같은 질문에 두 가지 답이 가능한 허브이며, 클라이언트는 먼저 도착한 쪽을 믿습니다. 한쪽에서 다른 쪽으로 옮길 때는 새 설정이 기존 세션에 적용된다고 가정하지 말고 이전 기능을 끄고 클라이언트를 다시 연결하십시오.

클라이언트 풀이 LAN 범위와 겹치지 않도록 변경 순서를 잡으십시오. 겹치는 서브넷은 연결은 되지만 아무것도 닿지 않는 터널의 두 번째로 흔한 원인이며, 두 주소 계획을 나란히 비교하기 전까지는 보이지 않습니다.

그다음 클라이언트에서 다시 연결해 무엇을 받았는지 읽으십시오. 허브가 보는 세션과 클라이언트가 보는 자기 네트워크는 같지 않으며, 새 임대를 강제하는 확실한 방법은 재연결뿐입니다.

클라이언트에서 게이트웨이와 리졸버 확인

인증이 성공했다는 것은 자격 증명이 동작하고 허브가 세션을 받아들였다는 뜻입니다. 무언가에 닿을 수 있는지는 말해 주지 않으며, 그것은 받은 주소, 마스크, 게이트웨이, DNS 서버에 달려 있습니다. 서버 설정을 다시 건드리기 전에 클라이언트에서 그 네 값을 읽으십시오.

Windows에서는 어댑터 세부 정보가 임대와 리졸버를 보여 주고, 라우팅 표가 터널이 정말 기본 경로인지 보여 줍니다.

ipconfig /all
route print -4
nslookup intranet.corp.internal

Linux 클라이언트에서는 같은 정보가 주소, 라우팅, 리졸버 파일에서 나옵니다. 기본 경로는 트래픽이 터널로 나가는지를 결정하는 값입니다. 게이트웨이가 사무실 라우터를 가리키는데 터널이 트래픽을 실어 나르기를 기대한다면, 토폴로지는 이름만 브리지이고 실제로는 끊어진 것입니다. 먼저 주소 공급원을 고치고, 다음으로 애플리케이션을 다시 시험하고, 그다음에야 다른 모드를 바꿀 것을 고려하십시오.