VPN을 통한 NetBIOS: 이름, 데이터그램, 세션은 별개의 서비스입니다
라우터에 관한 구호는 너무 넓습니다. 애플리케이션이 세 서비스 중 무엇을 쓰는지, 이름을 브로드캐스트로 푸는지 서버로 푸는지 확인하세요.
«NetBIOS는 라우터를 넘지 않는다»는 말이 설계를 이미 끝낸 것처럼 반복됩니다. 그렇지 않습니다. 브로드캐스트 이름 조회는 보통 자기 브로드캐스트 도메인 안에 머무르지만, NetBIOS 서비스는 라우팅이 아주 잘 되는 방향성 IP 트래픽도 사용할 수 있습니다. 쓸모 있는 질문은 NetBIOS가 라우터를 넘는지가 아니라, 애플리케이션이 세 서비스 중 어느 것을 쓰는지입니다.
하나의 유선 프로토콜이 아닌 소프트웨어 인터페이스
RFC 1001은 NetBIOS를 애플리케이션이 프로그램을 작성하는 인터페이스로 설명하며, 그 아래에 여러 전송이 있습니다. TCP/UDP 모델은 이름 서비스, 데이터그램 분배, 세션 서비스를 분리하고, IP 브로드캐스트가 있든 없든 동작하는 것을 명시적으로 지원합니다.
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
그 표가 이 구호가 실패하는 이유입니다. 이름이 있는 두 호스트 사이의 세션 서비스는 IP 대화이지만, 브로드캐스트 데이터그램은 그렇지 않습니다. 하나의 VPN 설계가 첫째를 만족하고 둘째를 만족하지 못할 수 있으며, 첫째를 증명하는 시험은 둘째에 대해 아무것도 말해 주지 않습니다.
노드 유형이 클라이언트의 요청을 결정합니다
RFC 1001의 브로드캐스트, 지점 간, 혼합 노드 모델은 호스트가 이름을 어떻게 푸는지 — 로컬 네트워크에 물어보거나, 이름 서버에 직접 물어보거나, 하나를 시도한 뒤 다른 하나를 시도하는 방식 — 을 설명합니다. 모델이 영향을 주는 것은 어떤 트래픽을 허용해야 하는지이며, 애플리케이션이 아예 동작하는지는 아닙니다.
관리되는 이름 서버 구성은 클라이언트에게 지점 간 경로를 주지만, 그것을 쓰도록 설정된 클라이언트에게만 줍니다. 네트워크 어딘가에 서버를 두는 것만으로 애플리케이션이 그 서버에 문의하게 되지는 않으며, 브로드캐스트 모드에 남겨진 클라이언트는 계속 로컬 세그먼트에 물어보다 시간 초과에 이릅니다. 서버 주소는 그 클라이언트가 존중하는 관리 경로를 통해 클라이언트 구성에 도달해야 합니다.
그러므로 해당 애플리케이션에 대해 세 가지 관찰, 곧 서버 이름을 주소로 어떻게 바꾸는지, 검색이나 메시징이 브로드캐스트를 쓰는지 방향성 종단점을 쓰는지, 실제 세션이 어떤 주소와 전송을 쓰는지의 세 가지를 기록하세요. 이것들은 서로 독립적인 사실이며 각각 고유한 해결책이 있습니다. 이름 해석이 한 번 성공한 것은 첫째에 대한 증거일 뿐입니다.
TCP/IP 위의 NetBIOS는 NetBEUI가 아닙니다
둘 다 레거시라고 불리기 때문에 혼동됩니다. TCP/IP 위의 NetBIOS는 서비스를 IP 패킷 안에 담아 나르며, 라우팅된 터널은 이미 그 패킷을 나릅니다. NetBEUI는 라우팅할 수 없는 2계층 프로토콜이며, IP 터널은 IP를 나른다는 이유만으로 임의의 이더넷 프레임을 나르지 않습니다.
IP 경로를 추가한다고 비IP 프레임이 IP 애플리케이션으로 바뀌지는 않습니다. 애플리케이션이 정말로 2계층 동작에 의존한다면 선택지는 명시적으로 경계 지어진 2계층 서비스이거나 애플리케이션 교체이며, 어느 쪽도 대신할 라우팅 변경은 없습니다.
과업을 만족하는 가장 작은 변경을 고르세요
승인된 DNS 이름과 명시적 UNC 경로로 접근하는 기존 SMB 공유에는 이더넷 확장이 필요하지 않습니다. 파일 서비스 과업과 탐색 경험은 서로 다른 요구 사항이며, 둘째만 이웃 목록에 의존합니다. 이름으로 공유에 접근하면 브로드캐스트 도메인을 터널 너머로 늘리지 않고도 과업이 해결됩니다.
탐색이 보통 실패하는 부분이며, 조용히 실패합니다. 경로로 공유를 열 수 있는데도 가까운 컴퓨터 목록이 비어 있는 경우가 있는데, 목록은 브로드캐스트 검색으로 채워지고 경로는 DNS를 쓰기 때문입니다. 목록이 필요하다고 판단하는 것은 파일이 필요하다고 판단하는 것과 다른 요구 사항입니다. 무엇이든 설계하기 전에 사용자가 실제로 어느 쪽을 요청했는지 적어 두세요.
오래된 애플리케이션이 정말로 브로드캐스트나 비IP 프레임을 요구한다면, 이름 있는 책임자가 있는 경계 지어진 2계층 서비스를 검토하거나 애플리케이션을 교체하세요. 브리지는 공유되는 장애 도메인과 정책 경계를 넓히며, 이는 NetBIOS라고 적힌 체크상자가 아니라 아키텍처 결정입니다. 터널이 날라야 할 구체적인 작업을 문서화하면, 관리자는 «Windows 네트워크 전체»를 추측하는 대신 요청을 평가할 수 있습니다.