Mac 공유가 VPN 너머로 보인다: 끌 것인가 숨길 것인가?

검색 목록은 알림으로 만들어지며, 알림은 접근 허가가 아닙니다. 누군가 멀리 떨어진 목록에서 노트북 이름을 보는 것은 멀티캐스트 질의가 보통 라우터에서 멈추는 경계를 넘었기 때문입니다. 그 통과는 항목이 나타나는 이유와 항목을 지우는 것이 서비스를 닫는 것과 같지 않은 이유를 모두 설명합니다. 무엇이든 바꾸기 전에 두 가지 중 어느 쪽에 실제로 반대하는지 정하십시오.

검색 항목이 실제로 무엇인가

Mac의 mDNS 응답자는 자신이 호스팅하는 서비스 유형에 대한 질의에 답하며, 그 응답은 이름, 포트, 몇 개의 텍스트 레코드를 담습니다. 질의한 클라이언트는 그 이름을 목록에 표시합니다. 교환 과정에서 연결이 성공할 것임을 증명하는 것은 없고, 허가를 주는 것도 없습니다. 목록은 이름에 대한 주장이지 접근에 대한 주장이 아닙니다. 그 구분이 무엇을 끌지, 아니면 게시를 멈출지를 결정합니다.

서비스마다 따로 등록되므로, 항목 하나가 사라진다고 모든 알림이 멈춘 것은 아닙니다. 파일 공유는 한 유형을, 화면 공유는 다른 유형을 등록하며, 프린터, 미디어 보관함, 개발자 도구도 각자 자기 유형을 등록합니다. 스위치 하나를 주 제어로 보기 전에 무엇이 등록되어 있고 어느 프로세스가 그것을 소유하는지 나열하십시오:

dns-sd -B _smb._tcp
lsof -nP -iUDP:5353

멀티캐스트는 무언가 브리지하지 않으면 로컬에 머문다

멀티캐스트 DNS는 UDP 5353의 링크 로컬 그룹으로 보내며, 라우터는 기본적으로 그 그룹을 전달하지 않습니다. 그래서 유니캐스트 트래픽을 라우팅하는 터널은 발견을 뒤에 남기고, 라우팅된 VPN의 Mac이 보통 원격 사이트에서 보이지 않는 이유가 여기 있습니다. 브리지된 터널이나 의도적으로 설정한 릴레이는 양쪽 끝을 하나의 브로드캐스트 도메인에 두어 이를 바꿉니다. 어느 설계인지는 터널의 속성이며, 그 위에 인쇄된 프로토콜 이름의 속성이 아닙니다.

서버 구성이 인터페이스를 브리지하는지 서브넷을 라우팅하는지 확인하십시오. 브로드캐스트에 의존하는 모든 프로토콜에서 둘은 다르게 동작합니다. 터널이 브리지되어 있으면 아무도 게시할 의도가 없던 것까지 여러 종류의 알림이 새어 나간다고 보십시오. 라우팅되어 있으면 원격 목록의 항목은 멀티캐스트 그룹이 아니라 릴레이나 유니캐스트 DNS 기반 발견을 통해 들어왔을 가능성이 큽니다. 그 경로들은 고치는 방법이 다르고, 멀티캐스트 포트를 막는 것은 그중 하나만 닫습니다.

서비스를 멈추는 것이 가장 깨끗한 경계

Mac이 파일을 제공할 일이 없다면 알림을 숨기려 하지 말고 지원되는 제어로 공유를 끄십시오. 멈춘 서비스에는 연결할 수 없고, 추측할 수도 없으며, 이름을 기억하던 옛 클라이언트도 닿지 못합니다. 그 속성이 더 강한 제어로 만들고, 네트워크의 협력을 전혀 필요로 하지 않습니다.

Apple의 파일 공유 안내서 는 공유 폴더, 허용된 사용자, 게스트 접근에 대한 권한 모델을 설명하고, 공유 패널은 현재 상태를 보여 줍니다. 서비스가 정말 필요할 때 이 셋을 검토하십시오. 존재해야 하는 공유는 범위를 정해야 하는 공유이기 때문입니다. 게스트 접근은 자격 증명 없이도 연결을 허용할 수 있기 때문에 따로 볼 가치가 있습니다. 그다음 서비스가 어느 인터페이스에서 수신하는지 확인하십시오. 모든 인터페이스에서 제공되는 공유는 터널에서도 제공됩니다.

서비스는 필요하지만 청중은 아닐 때

때로 공유는 정당하고 청중은 그렇지 않습니다. 서비스를 승인된 출처로 제한하고 발견은 별도의 더 약한 제어로 두는 것이 정직한 배치입니다. 방화벽 규칙, 사용자별 권한, 올바른 인터페이스에서의 수신은 숨긴 알림이 할 수 없는 방식으로 접근을 좁힙니다.

발견을 억제하는 것은 엄밀히 말해 겉치레입니다. 서비스는 이름을 아는 누구에게나 계속 응답합니다. 게시 자체가 문제라면 그것을 나르는 계층에서 제한하십시오. 직접 관리하는 네트워크에서는 어떤 서비스 유형이 경계를 넘어야 하는지 정하고 브리지, 릴레이, 필터를 그에 맞게 구성하는 일입니다. 포럼에서 브리지 필터 명령을 복사하는 것은 서버가 바로 그 스택과 그 터널 모드를 실행할 때만 동작하며, 관리하지 않는 네트워크에서는 원격 클라이언트가 무엇을 기억하는지 제어할 수 없다는 것이 정직한 답입니다.

원격 쪽에서 보라

Mac 자체 네트워크가 아니라 원격 쪽에서 시험하고, 캐시된 목록이 아니라 새 검색을 시험하십시오. 그다음 이름과 주소로 서비스에 직접 연결해 보십시오. 두 결과는 다른 질문에 답하기 때문입니다. 연결이 성공했는데 항목이 없으면 라벨을 숨긴 것이고, 연결이 실패하면 서비스를 닫은 것입니다. 새로 고침을 건너뛰면 캐시가 두 시험을 모두 거짓으로 만들므로 클라이언트를 새로 시작하십시오.

무엇을 바꿨는지, 그것이 세 제어 중 어디에 속하는지 적어 두십시오. 서비스 중지, 접근 제한, 발견 제한입니다. Mac이 여전히 보인다는 보고가 오면 그 기록이 보고가 오래된 것인지 다른 서비스가 자신을 알리는 것인지 알려 줍니다. 여기서 대부분의 놀라움은 아무도 켠 기억이 없는 두 번째 등록이며, 고장 난 제어가 아닙니다.

변경이 실패했다고 결론 내리기 전에 남은 등록을 다시 확인하십시오. 짧은 목록이 또 한 차례 추측보다 낫습니다.