OpenVPN이 DNS를 밀어 넣은 뒤 로컬 Samba 공유가 사라졌다

Samba는 OpenVPN 이 연결되는 순간 로컬 공유를 잃지만, 터널이 원인인 경우는 거의 없습니다. 마운트는 정상이고 NAS도 켜져 있으며, 터널이 설치한 리졸버가 본 적 없는 이름에 대한 질문에 답하고 있습니다. Samba는 조회 순서의 앞부분에서 그 리졸버에 묻고, 그 답을 믿고, 아무것도 듣지 않는 주소로 연결합니다. 공유를 고치는 일은 마운트가 아니라 답을 고치는 일입니다.

각 단계에서 가장 많은 가능성을 배제하는 순서로 다섯 가지를 확인합니다.

짧은 이름에 누가 답하는가

파일 관리자가 아니라 운영체제에 물어보세요. resolvectl status 는 각 링크에 연결된 DNS 서버를 출력하고 어느 링크가 기본 경로인지 표시하며, 짧은 이름에 대한 질의는 응답한 서버를 보고합니다. NAS 이름에 대해 한 번, 사무실 도메인에 있다는 것을 아는 이름에 대해 한 번 실행하세요. 두 답이 서로 다른 서버에서 온다면 분리를 찾은 것입니다.

응답이 부정 응답이었는지 주소였는지 확인하세요. 부정 응답이면 Samba가 다른 메커니즘으로 넘어갔어야 하고, 고장은 다른 곳에 있습니다. 주소라면 Samba가 실제 장소에 연결해 아무것도 받지 못한 것입니다.

Samba가 잘못된 답을 믿는 이유

Samba는 name resolve order 로 정해진 고정 순서로 이름을 해석합니다. 대부분의 배포판에서 기본값에는 host 가 포함되며, 이는 DNS를 뜻하고 NetBIOS 브로드캐스트 같은 LAN 전용 메커니즘보다 먼저 실행됩니다. 그래서 리졸버를 밀어 넣는 터널은 건물 밖으로 나갈 일이 없던 단일 레이블 이름까지 포함해 모든 공유 이름에 대해 첫 거절 권한을 얻습니다.

보통 알 수 없는 이름은 부정 응답을 돌려주고 다음 메커니즘이 차례를 받습니다. 일부 리졸버, 특히 소비자 ISP와 공용 리졸버는 알 수 없는 이름에 검색 페이지나 광고 주소로 답합니다. 그 응답은 리졸버 라이브러리에 성공처럼 보이므로 Samba는 찾기를 멈추고 네트워크와 아무 관련이 없는 주소로 연결합니다.

결과는 오류 대화상자 없이 사라지는 공유입니다. 그 순서 어디에도 VPN 라우팅 실패는 없으므로 NAS에 ping은 여전히 되지만 NAS로 탐색은 되지 않습니다.

범위가 다른 두 가지 수리

좁은 수리는 밀어 넣은 리졸버를 유지하고 Samba가 그에게 물을 수 있는 내용을 바꿉니다. 데몬이 실제로 읽는 Samba 설정에 두 줄을 추가한 다음 서비스를 다시 시작하세요:

[global]
   name resolve order = wins lmhosts bcast
   dns proxy = no

그 목록에 host 가 없으면 공유 조회 경로에서 DNS가 빠지고, 단일 레이블 이름은 로컬 세그먼트에 남습니다. 사무실 이름은 다른 모든 프로그램에서는 여전히 정상적으로 해석됩니다. 이 설정은 Samba만 바꾸기 때문입니다. 대가는 Samba가 DNS를 전혀 쓸 수 없다는 것이므로, 정규화된 사무실 이름으로 지정된 공유는 문제가 됩니다.

넓은 수리는 원인을 없앱니다. 소유하지 않은 이름에 답하는 리졸버를 밀어 넣지 않거나, 사무실 접미사만 사무실 리졸버에 도달하도록 분할 DNS 정책을 밀어 넣으세요. 관리되는 네트워크에서는 브라우저와 패키지 관리자도 보호하므로 장기적으로 더 나은 답이지만, 서버 쪽 관리자 권한과 밀어 넣은 설정을 따르는 클라이언트가 필요합니다.

하나를 의도적으로 고르세요. 리졸버 변경은 모든 애플리케이션의 이름 해석을 한 번에 바꾸므로 변경 기록의 대상이며, 지원 통화를 위한 편집이 아닙니다.

접미사가 모든 것을 설명할 수 있다

클라이언트가 검색 접미사도 밀어 넣으면 짧은 로컬 이름이 질의되기 전에 사무실 도메인으로 다시 쓰입니다. 그렇다면 리졸버는 전혀 거짓말을 하지 않습니다. 사무실 이름에 대한 정당한 질문을 받고 올바른 답을 준 것입니다. 파일 관리자에서는 두 고장이 똑같이 보이므로 광고 주소 사례와 구분하려면 리졸버 출력에서 질의된 이름을 읽으세요.

여기서 해결책은 정규화된 로컬 이름을 쓰거나 로컬 접미사를 소유하는 분할 DNS 규칙을 추가하는 것입니다. 둘 다 Samba를 건드릴 필요가 없습니다.

다시 연결한 뒤 증명하세요

한 세션에서 세 이름을 시험하세요. 짧은 이름으로 로컬 공유, 이름으로 사무실 호스트, 그리고 평범한 웹사이트입니다. 첫 번째가 되고 두 번째가 깨지면 수리가 고장을 없앤 것이 아니라 옮긴 것입니다. 세 번째가 깨지면 리졸버 변경이 의도보다 멀리 갔고 이제 모든 조회가 의심스럽습니다.

그다음 터널을 끊었다가 다시 연결하고 세 가지를 모두 반복하세요. 밀어 넣은 옵션은 연결할 때마다 다시 적용되므로 실행 중에만 존재하던 수리는 설정 파일이 바뀌지 않은 채 사라질 수 있습니다. 어느 접미사를 어느 리졸버가 소유하는지와 적용 중인 조회 순서를 기록하고 날짜도 적어 두세요. 이것이 다시 나타날 때 다음 클라이언트 업데이트가 뻔한 용의자이기 때문입니다.

다섯 가지 확인을 모두 마친 뒤에도 공유가 실패하면, 다른 무엇을 바꾸기 전에 정확한 질의와 정확한 응답을 포착하세요. 그 두 줄이 리졸버 고장과 정말 존재하지 않는 이름을 구분하며, 쓸 수 있는 가장 빠른 인수인계 메모입니다.