curl의 NTLM 프록시 로그인 진단
NTLM 프록시가 로그인을 거부하면 curl 빌드의 지원 여부, 프록시 인증 챌린지, 연결의 연속성을 확인하세요.
NTLM 프록시 인증에는 핸드셰이크가 필요하며, 사용자 이름을 한 번 붙이는 것으로 끝나지 않습니다. 계정 암호를 바꾸기 전에 프록시가 실제로 NTLM을 제공하는지, curl 실행 파일이 이를 지원하는지 확인하세요.
curl --version
실제 요청을 실행하는 파일의 기능 목록을 살펴보세요. 다른 curl 설치본, 컨테이너 이미지, 운영 체제 빌드는 인증 지원이 다를 수 있습니다.
프록시 전용 인증 방식을 선택하기
curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/
엔드포인트, 도메인, 사용자 이름은 예시입니다. 관리자가 제공한 형식을 사용하세요. 인수에 암호가 없으면 표시되는 명령에 비밀을 남기는 대신 curl이 입력을 요청할 수 있습니다.
최초 인증 챌린지는 협상의 일부일 수 있습니다. 이를 핸드셰이크 완료 후 거부되는 경우와 구분하세요. 프록시의 챌린지에 응답하려고 원본 서버용 NTLM 옵션을 사용하지 마세요.
진단에 연결 동작도 포함하기
NTLM은 연결 범위의 상태를 갖습니다. 핸드셰이크는 예상된 연결 경로를 따라 수행되어야 합니다. 각 단계 사이에서 연결을 계속 교체하면 완료되지 않을 수 있습니다.
libcurl을 사용하는 애플리케이션에서는 라이브러리가 인증과 연결 재사용을 관리하게 하세요. 서로 다른 ID로 인증된 연결을 교환 가능한 것으로 취급하는 범용 풀을 만들지 마세요. 여러 홉이나 중개 서비스가 있다면 필요한 연결 구성을 유지하는지 확인하세요.
지원 여부와 방식 선택이 올바르면 계정 형식, 도메인 정책, 민감한 정보를 제거한 서버 인증 로그를 조사하세요. 챌린지가 나오기 전의 시간 초과는 여전히 도달성 문제이며 NTLM 암호가 틀렸다는 증거가 아닙니다.
상세 추적에는 인증 토큰과 내부 이름이 포함될 수 있습니다. 로컬에서 사용하고 공유 전에 민감한 정보를 제거하세요. 공개 오류 보고서에는 원시 토큰 교환 내용이 필요하지 않습니다.