Samba가 서버에 도달하는 VPN 클라이언트를 거부하는 이유

VPN 클라이언트가 파일 서버에 핑이 통하고 이름도 해석되지만 공유를 열 수는 없습니다. Samba 의 호스트 정책은 그 연결을 거부할 수 있는 네 계층 중 하나이고, 사람들이 가장 마지막에 편집하는 계층입니다. 허용 목록은 smbd 가 실제로 받는 원본 주소를 기준으로 평가되며, 그 주소는 클라이언트가 자기가 가지고 있다고 믿는 주소와 다를 수 있습니다. 그 원본을 정확히 파악하면 모호한 권한 문제가 한 줄짜리 설정 변경이 됩니다.

같은 메시지로 실패하는 네 계층

거부는 경로, 호스트 방화벽, Samba 호스트 정책 또는 SMB ID 중 하나에서 시작될 수 있습니다. 각 계층은 클라이언트에 거의 같은 내용의 메시지를 주기 때문에 추측만으로 반나절이 사라집니다. 확인을 네트워크에서 안쪽으로 정렬하면 추측의 대부분이 사라집니다.

전송부터 시작하세요. 포트 445 가 서버에 도달하지 않으면 어떤 Samba 설정도 의미가 없고, 서버 인터페이스에서의 캡처가 몇 초 만에 결론을 냅니다. 다음은 서버 자체의 호스트 방화벽이며, 허용된 원본도 smbd 가 보기 전에 버릴 수 있습니다. 이 둘을 통과한 뒤에야 허용 목록이 후보가 됩니다. 인증은 로그인 실패와 호스트 거부가 클라이언트에서는 둘 다 액세스 거부로 보이더라도 서버 로그에서는 다르게 나타나기 때문에 마지막입니다. 순서는 도구보다 중요하며, 각 계층에는 그 계층을 확인하는 명령이 있습니다.

smbd 가 실제로 보는 원본 주소를 찾으세요

라우팅 액세스에서는 서버가 보통 VPN 풀의 클라이언트 주소를 봅니다. 게이트웨이에서 원본 변환이 있으면 대신 게이트웨이의 LAN 주소를 보게 되고, 그 게이트웨이 뒤의 모든 클라이언트는 구분할 수 없게 됩니다.

이 차이가 허용 목록의 항목이 정책인지 구멍인지를 결정합니다. 변환된 게이트웨이 주소를 허용하면 그 뒤의 모두를 들이게 되며, 클라이언트별 규칙이 표현하려던 것은 거의 아닙니다. 원본은 서버에서 읽어야 하며, 클라이언트가 자기 주소에 대해 갖는 생각에서 읽지 마세요. 서버 인터페이스에서의 캡처가 이를 보는 가장 저렴한 방법이고, 같은 캡처가 패킷이 도착했는지도 증명합니다. 캡처는 패킷 수로 제한하고, 어떤 클라이언트를 추적하는지 알면 호스트 필터를 추가하세요. Samba 세션 표는 답의 나머지 절반으로, smbstatus -b 출력에서 각 세션 행의 클라이언트 열은 smbd 가 기록한 상대이고, 서비스에 실제로 도달한 주소를 가장 빠르게 확인하는 방법입니다.

sudo tcpdump -ni any -c 20 'tcp port 445'
sudo smbstatus -b
ss -tnp | grep ':445'

허용 목록을 Samba 가 읽는 방식으로 읽으세요

hosts allow 설정은 주소, 네트워크 또는 이름 목록을 받으며, 전역으로도 공유 안에도 놓일 수 있습니다. 당신에게 동등해 보이는 두 항목이 파서에게는 동등하지 않을 수 있으므로, 실효 설정이 점검 대상입니다. 그것은 통합된 보기이며, 우연히 편집한 파일이 아닙니다.

설명을 위한 두 접두사 쌍은 아래 줄과 같으며, 이것은 예시이고 이미 있는 항목을 대체하는 것이 아닙니다. 오늘 정당하게 연결하는 관리용과 애플리케이션 클라이언트는 남기고, 차단 목록이 있으면 같은 단계에서 읽으세요. 호스트가 받아들여지는지는 정책 전체에 달려 있으므로, 우선순위를 따지지 말고 정확한 클라이언트로 시험하세요. 호스트 허용은 공유 권한이나 파일 시스템 모드에 대해서도 말하지 않으며, 그것들은 별개의 관문입니다. 시험 도구의 성공은 호스트 정책이 그 원본을 허용한다는 뜻일 뿐, 그 이상은 아닙니다.

hosts allow = 192.168.50.0/24 10.90.0.0/24
testparm -s
testparm -s /etc/samba/smb.conf client.example 10.90.0.14

재부팅 후에도 남는 파일을 변경하세요

일반적인 Linux 호스트에서는 설정 경로가 고정되어 있고 재시작할 때 서비스가 다시 읽습니다. 라우터나 어플라이언스에서는 실행 중인 smb.conf 가 부팅 시 생성되는 경우가 많고, 손으로 한 편집은 다음 재부팅에서 사라집니다. 어플라이언스가 지원하는 사용자 지정 방식(보통 자체 설정 파일)을 사용하세요.

이 시점의 유혹은 한 스레드가 잘 된다고 보고했기 때문에 대체 펌웨어를 플래시하는 것입니다. 그것은 작은 정책 문제에 비해 큰 변경이고, 기기를 지원되는 상태 밖으로 옮깁니다. 먼저, 대부분의 어플라이언스가 자체 인터페이스로 허용 목록을 노출하므로 지원되는 제어를 확인하세요. 정말로 그렇지 않다면 그 제한은 다른 하드웨어를 택할 근거이며, 지원되지 않는 빌드를 택할 근거가 아닙니다.

어떤 파일을 바꿨고 무엇이 그것을 다시 만드는지 기록해, 다음 사람이 진단을 반복하지 않게 하세요.

허용된 클라이언트 하나와 제외된 클라이언트 하나를 시험하세요

원하는 결과만이 아니라 두 결과를 모두 시험하세요. 연결되는 허용 클라이언트는 변경이 작동함을 증명하고, 계속 거부되는 제외 클라이언트는 규칙이 그저 모두를 연 것이 아님을 증명합니다.

smbclient -L //fileserver -U alice
sudo testparm -s /etc/samba/smb.conf alice-laptop 10.90.0.14
sudo tail -n 40 /var/log/samba/log.smbd

연결이 smbd 에 도달하지 않으면 답은 라우팅이나 서버 방화벽에 있습니다. 호스트가 허용되었는데 로그인이 실패하면 문제는 ID 이고, 허용 목록을 더 넓혀도 도움이 되지 않습니다. 자세한 Samba 로그는 공유 경로와 계정 이름을 노출할 수 있으므로 진단 출력은 비공개로 두세요. 그러지 않으면 다음 결과가 아무것도 알려주지 않으므로 시도마다 한 계층만 바꾸세요.