네트워크에서 장치를 찾는 데 유용한 최고의 핑 스윕 도구 10가지
빠른 LAN 검색, 플랫폼 간 스캔 및 IP 주소 관리를 위한 10가지 핑 스윕 도구를 비교해 보세요. 스윕을 통해 무엇을 알 수 있고 무엇을 알 수 없는지 알아보세요.
Zimbra 웹메일의 경우, 설정 하나만 높이는 것으로는 충분하지 않을 수 있습니다. 사용자가 발신 메시지에 대용량 파일을 첨부해야 하는 경우, 웹 업로드 제한, 사서함 SOAP 콘텐츠 제한, 그리고 MTA의 총 메시지 크기 제한을 함께 고려해야 합니다. 또한 서버별 재정의 설정이나 외부 프록시로 인해 요청 제한이 더 낮아지는 경우도 확인해 보세요.
예를 들어, 조직에서 사용자가 최대 25MiB 크기의 파일을 첨부하도록 허용한다고 가정해 보겠습니다. Zimbra의 크기 지침에서는 MIME으로 인코딩된 전체 메시지에 대해 원본 파일 크기의 약 150%를 허용하도록 권장합니다. 40MiB(41,943,040바이트)의 상한선을 설정하는 것이 해당 정책에 대한 적절한 시작 예시이며, 이는 테스트 및 저장 용량에 따라 달라질 수 있습니다. MIME 오버헤드는 메시지마다 다르므로 어떤 배수를 적용하더라도 모든 메시지가 허용된다는 보장은 없습니다.
zimbra현재 값을 검토하고 예시 정책이 사용자 환경에 적합한지 확인한 후, 다음 명령을 사용자 계정으로 실행하십시오 .
su - zimbra
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize zimbraMtaMaxMessageSize
zmprov mcf zimbraFileUploadMaxSize 41943040
zmprov mcf zimbraMailContentMaxSize 41943040
zmprov mcf zimbraMtaMaxMessageSize 41943040
postfix reload
이 명령은 전역 값을 설정합니다. 사서함 서버에 자체적으로 더 낮은 값을 재정의하는 경우 해당 서버도 확인하고 조정해야 합니다. 정확한 속성 및 재시작 동작은 Zimbra 릴리스 및 배포 버전에 따라 다를 수 있으므로 변경 사항을 광범위하게 적용하기 전에 설치된 버전과 비교하여 확인하십시오.
zimbraFileUploadMaxSize이 속성은 Zimbra에서 처리하는 파일 업로드를 제어하며, 내장 웹 프록시에서 허용하는 요청 본문도 포함합니다. Zimbra의 프록시 참조는 HTTP 및 HTTPS의 최대 본문 크기를 이 속성에 매핑합니다. 프록시 제한을 초과하는 요청은 HTTP 413 오류를 반환할 수 있습니다. 여러 사서함이 있는 환경에서는 이 속성을 전역적으로 또는 서버별로 설정할 수 있습니다.
zimbraMailContentMaxSize사서함 SOAP 인터페이스를 통해 전송되는 메시지 콘텐츠의 크기를 제어합니다. zimbraMtaMaxMessageSize표준 Zimbra 배포 환경에서 MTA(Postfix)가 허용하는 최대 전체 메시지 크기를 제어합니다. 이 크기에는 디스크에 저장된 원본 파일뿐만 아니라 메시지 헤더와 MIME으로 인코딩된 콘텐츠도 포함됩니다.
Zimbra 기술 센터의 크기 구성 관련 문서는 현재 개발 중인 문서로 명시되어 있습니다. 해당 문서의 설명과 명령어는 유용하지만, 설치된 Zimbra 버전에 맞는 속성 정의와 동작 방식을 확인하시기 바랍니다. 참고 자료는 Zimbra의 최대 메시지 크기 지침 과 Zimbra 프록시 변수 참조 입니다 .
오류 발생 원인에 맞는 설정을 사용하십시오. 첨부 파일 전송 중 즉시 거부되는 경우, 먼저 업로드 용량 제한 또는 웹 프록시 제한을 확인해야 합니다. 전송 또는 배달 중 메시지가 거부되는 경우, MTA 또는 수신자 서버에 문제가 있을 수 있습니다. 업로드는 성공했지만 나중에 전송에 실패하는 경우, MTA 용량 제한 또는 MIME 확장 설정에 대한 점검이 필요합니다.
모든 제한을 가능한 한 높게 설정하는 대신, 명확한 비즈니스 한계를 설정하십시오. 예를 들어, 사용자가 최대 25MiB 크기의 파일을 첨부해야 하는 경우, 40MiB라는 예시는 인코딩 및 메시지 오버헤드를 고려한 여유 공간을 제공합니다. Zimbra는 인코딩된 파일 크기 증가율이 고정된 비율이 아니므로 메시지 제한을 추정할 때 150%를 기준으로 삼을 것을 권장합니다.
메시지 크기가 클수록 큐 저장 공간, 대역폭 및 사서함 용량이 더 많이 사용됩니다. Zimbra는 Postfix 크기 제한이 지나치게 높으면 큐 파티션에 여유 공간이 부족하여 메일 배달 문제가 발생할 수 있다고 경고합니다. 또한 일부 버전에서는 Zimbra 크기 속성 값이 너무 높으면 서비스 문제가 발생할 수 있습니다. Zimbra는 범위를 벗어난 값으로 인해 웹 앱 및 관리 콘솔 오류가 발생하는 사례를 문서화했습니다. 용량 계획 없이 수 기가바이트의 상한값을 설정하기보다는 단계적으로 제한값을 늘리고 결과를 테스트하십시오.
모든 사서함 서버가 하나의 정책을 공유해야 할 때 전역 구성이 편리합니다. 하지만 서버 수준 값이 전역 설정을 재정의할 수 있습니다. 전역 값을 확인한 다음 영향을 받는 사용자를 처리하는 사서함 호스트의 값을 확인하십시오.
su - zimbra
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize
zmprov gs mailbox1.example.com zimbraFileUploadMaxSize zimbraMailContentMaxSize
실제 사서함 서버 이름으로 바꾸십시오 mailbox1.example.com. 서버별 값이 더 작고 정책에서 더 큰 크기를 허용하는 경우 해당 호스트를 업데이트하십시오.
zmprov ms mailbox1.example.com zimbraFileUploadMaxSize 41943040
zmprov ms mailbox1.example.com zimbraMailContentMaxSize 41943040
변경이 필요한 사서함 호스트에 대해서만 이 과정을 반복하십시오. 전역 구성을 수정한다고 해서 기존 서버 재정의가 제거되는 것은 아닙니다. 다중 서버 환경에서는 모든 해당 사서함 노드와 모든 MTA를 확인하십시오.
전역 MTA 속성을 변경하고 Postfix를 다시 로드한 후 각 Zimbra MTA에서 유효한 Postfix 값을 확인하십시오.
su - zimbra
zmprov gcf zimbraMtaMaxMessageSize
postconf message_size_limit
두 결과는 바이트 단위로 일치해야 합니다. LDAP 속성이 올바르지만 postconf여전히 이전 제한값이 표시되는 경우, 전체 재시작을 시도하기 전에 Zimbra MTA 구성 프로세스 및 로그를 검토하십시오. 재시작은 메일 서비스를 중단시킬 수 있으므로 설치된 릴리스 및 배포 토폴로지에 따라 필요한 경우에만 예약하십시오.
Zimbra 프록시는 HTTP 요청 본문 제한을 설정합니다 zimbraFileUploadMaxSize. 환경에 Zimbra 앞에 별도의 Nginx, Apache, 클라우드 게이트웨이 또는 보안 어플라이언스가 있는 경우 해당 구성 요소에 자체 업로드 제한이 있을 수 있습니다. 413 응답이나 프록시 로그 항목은 오류를 반환한 계층의 요청 본문 제한을 확인해야 한다는 단서입니다. Zimbra에서 생성한 프록시 파일을 직접 편집하지 마십시오. 지원되는 Zimbra 설정을 통해 변경하고 해당 버전에 맞는 구성 재생성 또는 재시작 절차를 따르십시오.
zimbraFileUploadMaxSize메일함 서버 재정의 및 프록시 제한을 확인하세요./var/log/zimbra.log거부, 초과, 제한 또는 경고 이벤트를 확인하는 것이 좋습니다.Postfix는 발신 SMTP의 경우 SMTP SIZE기능에서 허용되는 메시지 크기를 알릴 수 있습니다. 원격 메일 서버는 Zimbra가 메시지를 전송한 후 더 작은 값을 알리거나 메시지를 거부할 수 있습니다. Zimbra의 문제 해결 문서에서는 로컬 MTA 거부와 수신자 측 거부를 구분하는 방법을 설명합니다. Postfix의 메시지 크기 매개변수 참조 및 Zimbra의 MTA 크기 문제 해결 예제를 참조하십시오 .
이메일 첨부파일 용량 제한은 대용량 미디어 파일, 디스크 이미지 또는 프로젝트 아카이브를 배포하는 데 적합한 방법이 아닙니다. 수신자의 메일 시스템마다 메시지 총 용량 제한이 다를 수 있으며, 암호화된 메시지는 원본 첨부파일보다 크기가 더 큽니다. 용량 제한을 늘리면 저장 공간이나 전송 대기열 용량에 부담이 가중될 수 있으므로, 승인된 파일 공유 서비스를 통해 파일을 공유하고 권한이 부여된 링크를 이메일로 전송하는 것이 좋습니다.
새 정책에 포함된 테스트 파일이 내부 수신자에게 업로드, 전송 및 도착하고 Postfix에서 의도한 메시지 크기 값이 보고되면 변경 사항이 성공적인 것입니다. 특정 사용자 또는 서버 노드에서만 여전히 문제가 발생하는 경우 해당 사서함 서버 재정의 및 프록시 경로를 비교하십시오. 외부 수신자만 메일을 거부하는 경우 Zimbra의 제한을 다시 늘리기 전에 해당 수신자의 제한을 확인하십시오.
빠른 LAN 검색, 플랫폼 간 스캔 및 IP 주소 관리를 위한 10가지 핑 스윕 도구를 비교해 보세요. 스윕을 통해 무엇을 알 수 있고 무엇을 알 수 없는지 알아보세요.
SNMP 적용 범위, 매핑, 알림, 배포 모델 및 비용 대비 효과를 포함하여 성능 모니터링을 위한 6가지 네트워크 관리 도구를 비교합니다.
Windows, iPhone, Android용 Wi-Fi 분석 앱들을 비교해 보세요. 채널 혼잡도, 신호 범위, 히트맵, 네트워크 문제 해결 도구 등을 포함합니다.
종합적인 네트워크 관리 도구부터 특정 지연 시간 측정에 특화된 도구까지, 7가지 무료 오픈 소스 핑 모니터링 도구를 비교하고 가용성, 패킷 손실률, 기록 관리에 적합한 도구를 선택하세요.
네트워킹에서 QoS가 무엇을 의미하는지, DSCP 마킹과 트래픽 큐가 음성, 비디오 및 비즈니스 애플리케이션의 우선순위를 어떻게 지정하는지, 그리고 QoS로 해결할 수 없는 문제는 무엇인지 알아보세요.
Nmap의 --traceroute 옵션을 사용하여 홉을 인증된 호스트로 매핑하고, 홉 및 RTT 출력을 이해하고, 과도한 스캔 없이 누락된 응답 문제를 해결할 수 있습니다.
Windows 및 Linux용 안정적인 SFTP 서버 소프트웨어(OpenSSH, Bitvise, SolarWinds, SFTPGo 등)를 비교해 보세요. 보안 및 파일 전송 요구 사항에 맞는 최적의 솔루션을 찾아보세요.
서브넷 검색, DNS 및 DHCP 조정, 네트워크 인벤토리, 오픈 소스 IPAM을 위한 7가지 IP 주소 관리 도구를 비교합니다.
SolarWinds NPM, PRTG 및 OpManager를 비교하여 명확한 장치 범위, 유용한 성능 지표, 실행 가능한 알림을 통해 실용적인 네트워크 모니터링 시스템을 구축하십시오.
빠른 장치 검색, 플랫폼 간 IP 스캔 및 엔터프라이즈 IPAM을 위한 네트워크 스캐너 도구를 비교하고, 각 옵션을 네트워크에 맞게 선택하는 방법에 대한 지침을 제공합니다.