VPN 주소의 Samba: 리스너가 사라지는 이유

공유는 오전 내내 동작했고, 점심때 터널이 다시 연결된 뒤 같은 UNC 경로가 이제 시간 초과가 나는데, 서버로 보내는 ping은 여전히 응답한다. 공유 정의는 바뀐 것이 없고 VPN도 켜져 있다. 바뀐 것은 Samba가 바인딩했던 로컬 주소이며, 인터페이스가 다시 만들어진 뒤 그 주소는 존재하지 않는다. 이 실패 방식은 권한 문제가 아니라 리스너의 수명 주기 문제다.

공유는 터널이 다시 시작될 때까지 동작한다

서비스를 주소에 바인딩하면 그 소켓이 해당 주소의 수명에 묶인다. 터널 인터페이스가 파괴되고 다시 만들어지면 이전 주소가 사라지고, 거기에 바인딩된 소켓도 함께 사라진다. 서비스는 계속 실행되지만 클라이언트가 라우팅되는 곳에서는 아무것도 수신하지 않는다.

새 주소가 ICMP에 응답하면 ping은 여전히 성공할 수 있어서 공유가 죽은 동안에도 도달성은 괜찮아 보인다. 사람들을 방화벽으로 보내는 것은 바로 이 하나의 오해를 부르는 성공이다.

도달성은 바인드 주소가 아니다

여기서 세 가지 결정이 섞인다. 경로는 클라이언트 패킷이 도착하는지를 정한다. 수신 소켓은 로컬 주소에서 무언가가 그것을 받아들이는지를 정한다. 공유 구성과 파일 시스템 권한은 그 다음에 무슨 일이 일어나는지를 정한다. 인터페이스가 다시 만들어질 때 깨지는 것은 두 번째뿐이다.

VPN 풀의 주소도 자동으로 로컬 바인드 주소가 되지는 않는다. 그것은 클라이언트의 것이지 파일 서버의 것이 아니다. 파일 서비스에 ping은 좋지 않은 시험이다.

문서에서도 이 소유자들을 분리해 두어라. VPN 풀의 향후 변경이 Samba 편집을 요구해서는 안 되고, 공유 권한 변경이 터널 재시작을 요구해서도 안 된다.

대신 안정적인 주소에 바인딩하라

더 안정적인 설계는 Samba를 영구 주소에 두고 VPN이 클라이언트를 그리로 데려가게 한다. 터널이 흔들려도 서버 주소는 변하지 않으므로 리스너가 인터페이스를 따라갈 필요가 없고, 그러면 허용은 VPN 경로와 호스트 방화벽이 강제한다. 이들은 바로 그 일을 위해 만들어졌다.

반드시 터널에 바인딩해야 한다면 설치된 릴리스의 계약을 이해하라. interfaces와 bind interfaces only 매개변수는 같은 것이 아니며, 바인딩 문서는 간헐적인 인터페이스에 대해 경고한다. 일부 플랫폼에는 동적 리스너 처리가 있지만, 그것은 가정할 것이 아니라 검증할 능력이다. 흔들림 전후에 표를 읽고 두 출력을 비교하라.

ss -ltnp | grep ':445'

재연결을 시험하라, 초록불이 아니라

서비스 시작 후만이 아니라 재연결 후에 리스너를 검증하라. 터널을 다시 만들고 수신 표를 읽어 클라이언트가 라우팅되는 주소에 소켓이 있는지 확인하라. 초록 터널 표시와 통과한 구성 점검은 둘 다 증명하지 않는다.

smbclient -L //files.corp.example -U alice

그다음 클라이언트에서 허용된 작업 하나와 거부된 경로 하나를 실행하고, 두 번째 재연결 후에 반복하라. 공유가 첫 흔들림까지만 동작한다면 바인딩이 여전히 인터페이스 수명에 묶여 있고 설계가 고쳐지지 않았다. 바인딩이나 서비스 주소를 바꾸면 증상은 다시 나타나지 않는다.