SMB 클라이언트로서의 라우터와 패킷 포워더: 어느 쪽이 맞는가

SMB 트래픽을 전달하는 것은 그것을 종료하는 것과 같은 작업이 아니며, 한쪽을 하는 라우터가 다른 쪽을 감당하지 못할 수 있습니다. 전달이란 라우터가 내용을 한 번도 분석하지 않는 패킷을 옮긴다는 뜻입니다. 마운트란 라우터가 파일 클라이언트가 된다는 뜻이며, 함께 제공되지 않을 수 있는 소프트웨어, 보호해야 하는 자격 증명, 이제 자기 것이 된 장애 모드를 안고 갑니다. 둘 중 무엇을 고를지는 파일이 어디에 필요한가의 문제이지, 라우팅 플랫폼을 무엇을 설치하도록 설득할 수 있는가의 문제가 아닙니다.

전달과 종료는 다른 작업

전달 역할에서 라우터의 책임은 하나, 경로가 요구하는 정책을 적용하면서 클라이언트와 서버 사이에서 패킷을 전달하는 것입니다. 공유에 인증하지 않고, 파일 데이터를 캐시하지 않으며, 서버가 SMB2를 쓰는지 SMB3를 쓰는지도 따지지 않습니다. 스트림을 그렇게 깊이 읽지 않기 때문입니다. 공유에 닿을 수 없게 되면 사용자는 오류를 보고, 라우터는 라우팅을 계속합니다.

클라이언트 역할에서 라우터는 프로토콜 대화에 참여합니다. 다이얼렉트를 협상하고, 인증하고, 이름을 해석하고, 마운트 지점을 유지하며, 그 위에서 도는 모든 것에 로컬 파일 시스템 뷰를 제시합니다. 이것은 수명 주기를 가진 실제 서비스이며, 게이트웨이를 파일 워크플로의 의존 대상으로 만듭니다. 또한 그 의존 대상의 모든 장애 모드를 물려받으며, 부팅 시 대기와 만료된 자격 증명도 포함됩니다.

비교는 능력만의 문제가 아닙니다. 공유를 마운트할 수 있는 플랫폼이 곧 그래야 하는 플랫폼은 아니며, 하나도 마운트할 수 없는 플랫폼이 여전히 트래픽을 라우팅하기에 맞는 자리일 수 있습니다.

커널 CIFS 마운트에 실제로 필요한 것

Linux 기반 기기에서 커널 CIFS 클라이언트와 사용자 공간 클라이언트는 별개의 능력이며, 작은 이미지에는 둘 다 없는 경우가 많습니다. 커널 지원이 실행 중인 이미지에 있어야 하고, 마운트 도우미가 존재해야 하며, 서버와 협상한 SMB 다이얼렉트가 양쪽이 받아들이는 것이어야 합니다. 그 내용은 Linux CIFS 클라이언트 안내서가 커널 구조와 마운트 옵션을 설명하고 있으며, 벤더 빌드에 그것이 포함되어 있다고 가정하기 전에 옳은 참고 자료입니다.

능력 주위로 설계하기 전에 그 유무를 확인하고, 명령 이름의 존재가 아니라 버전을 확인하십시오. 패키지 목록의 모듈 이름은 동작하는 클라이언트와 같지 않습니다.

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

로드되는 커널 모듈과 버전을 보고하는 사용자 공간 도구가 있다고 해서 마운트가 VPN 키 갱신을 견딘다는 보장은 아닙니다. 그러니 그 점검은 입증이 아니라 출발 조건으로 다루십시오. 이미지가 SMB1 지원만 제공한다면 그것은 서버에서 켤 이유가 아니라 멈출 이유입니다.

자격 증명과 출처 정체성은 노트북의 것과 다릅니다

전달된 요청은 터널을 통해 노트북의 정체성을 나릅니다. 반면 라우터에서 만들어진 요청은 라우터 자체의 출처 주소, 리졸버 경로, 출력 필터링을 나릅니다. 그것들은 다른 방화벽 규칙, 다른 DNS 뷰, 서버 측의 다른 허용 목록에 떨어질 수 있습니다. 따라서 워크스테이션에서 동작하는 복제본은 라우터 자체의 마운트에 대해 아무것도 증명하지 않습니다. 마운트는 라우터 자체의 셸에서 시험하십시오. 그 뒤의 워크스테이션에서가 아닙니다.

그 역할이 승인된다면 라우터에 좁게 권한을 준 서비스 신원을 부여하십시오. 암호를 마운트 명령줄에 직접 두지 마십시오. 셸 기록에 남고, 마운트가 도는 동안 프로세스 표에도 나타납니다.

자격 증명은 플랫폼의 보호된 메커니즘으로 저장하고, 엄격한 권한의 파일에서 읽으십시오. 그 파일은 마운트를 실행하는 계정 말고는 읽을 수 없어야 합니다.

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

공유가 사라질 때 장애는 누구의 것인가

없는 원격 파일 시스템은 없는 경로와 다르게 동작합니다. 마운트는 그것을 건드리는 프로세스를 막을 수 있고, 터널이 생기기 전 부팅 시점에 실패할 수 있으며, 마운트 지점 아래에 로컬 디렉터리가 있으면 서버로 향한 쓰기가 엉뚱한 곳에 떨어질 수 있습니다. 이제 네트워크 팀이 떠안는 스토리지 장애이며, 팀이 원했든 아니든 마찬가지입니다. 아무도 그 소유권에 동의하지 않았지만, 마운트와 함께 찾아옵니다.

부팅 순서와 마운트 옵션을 그 현실에 맞춰 설계하십시오. 짧은 타임아웃과 문서화된 복구 단계를 갖춘 읽기 전용 마운트는 나머지 전부가 의존하는 쓰기 가능 마운트보다 변호하기 쉽습니다. 무언가 마운트를 시도하기 전에 터널이 올라오는지 확인하십시오. 그렇지 않으면 정전 후 첫 부팅이 멈춥니다.

상당한 파일 처리나 데이터를 더 내보내는 어떤 일에는 별도 호스트가 대개 더 분명한 소유 경계를 줍니다. 라우터는 라우팅을 계속하고, 파일 워크플로는 네트워크를 끌고 가지 않고도 재부팅할 수 있는 기계를 얻습니다.

결정을 실제 작업에 비추어 확인하십시오

어떤 작업이 파일을 필요로 하고 그 작업이 어디서 도는지 적으십시오. 답이 워크스테이션이라면, 공유를 라우팅하고 거기서 멈추십시오. 답이 기기 위의 서비스라면 첫 마운트 전에 클라이언트 능력, 지원 다이얼렉트, 자격 증명 경로를 확인하고, 그다음 기기가 정말 맞는 호스트인지 판단하십시오.

마운트된 뷰와 여유 공간을 라우터 자체에서 확인하십시오. 작업 부하가 그것들을 보는 곳이 거기입니다. 확인은 깨끗한 부팅 후만이 아니라 재연결 후에도 반복하십시오.

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

파일을 나열하면서도 가득 찼거나 읽기 전용인 파일 시스템을 보고하는 마운트는 새벽 2시에 어떤 장애를 만날지 이미 말해 주었습니다. 복구 경로도 확인하십시오. 깨끗하게 언마운트하고, 터널을 내리고, 다시 올린 뒤 기기를 재부팅하지 않고 다시 마운트하십시오. 그 순서가 매번 지원 사례를 필요로 한다면, 클라이언트 역할에 라우터는 잘못된 자리입니다.