Ubuntu에서 다음 명령을 실행할 때:
curl -v --insecure -XGET 'https://user:pass@IP_ADDR:PORT/SOME_FILE.php'
나는 다음과 같은 결과를 얻습니다.
* Hostname was NOT found in DNS cache
* Trying IP_ADDR...
* Connected to IP_ADDR (IP_ADDR) port PORT (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
몇 분 후에 나는 이것을 얻었습니다:
* Unknown SSL protocol error in connection to IP_ADDR:PORT
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to IP_ADDR:PORT
CentOS에서 동일한 작업을 시도했지만 여전히 멈췄 Client Hello
지만 결국 다음과 같은 결과를 얻었습니다.
curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received
원인이 무엇인지, 해결 방법을 아는 사람이 있나요?
답변1
잘못 구성된 MTU로 인해 동일한 문제가 발생했지만 다른 가능한 원인이 많이 있습니다.
핵심은 에지 라우터의 트래픽을 스니핑하는 것입니다. 여기서 요청하는 서버(GitHub.com)로 전송된 ICMP 메시지를 볼 수 있습니다.분열. 이로 인해 연결이 엉망이 되어 재전송, ACK 중복 등이 발생할 수 있습니다.
ICMP 패킷에는 MTU of next hop
이상한 값 1450이 포함된 필드가 있습니다. 일반적인 값은 1500입니다.
라우터를 확인했는데 인터페이스 중 하나(이더넷 터널)에 해당 값이 MTU로 포함되어 있으므로 라우터는 모든 인터페이스 중 가장 작은 MTU를 다음 홉으로 사용했습니다. 이 인터페이스를 제거하면(사용되지 않음) SSH 핸드셰이크가 다시 작동하기 시작했습니다.
답변2
OpenVPN을 통해 두 개의 인프라를 연결할 때도 동일한 문제가 발생했습니다.
Curl은 https/http에서 작동하지 않습니다.
Charlie의 솔루션이 저에게 효과적입니다.
나는 이 링크를 클릭했습니다:https://www.sonassi.fr/help/troubleshooting/setting-Cordirect-mtu-for-openvpn.
따라서 올바른 MTU를 찾으려면 다음 명령을 사용할 수 있습니다.
bryan@debian-dev11@ping -c 1 -M do -s 1472 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 1472(1500) bytes of data.
1480 bytes from 10.0.0.5: icmp_seq=1 ttl=126 time=6.19 ms
여기서 1472는 테스트한 MTU입니다.
및 MTU 오류 응답
bryan@debian-dev11:~$ ping -c 1 -M do -s 1474 10.0.0.5
PING 10.0.0.5 (10.0.0.5) 1474(1502) bytes of data.
ping: local error: Message too long, mtu=1500
대상 서버의 방화벽은 icmp/echo 요청을 수락해야 합니다.
내 특별한 경우에는 두 개의 NAT 규칙을 차례로 통해 두 개의 라우터 뒤에 있습니다. 패킷이 최종 호스트에 도달하면 최종 호스트는 원래 IP가 아닌 게이트웨이 너머로 누락된 부분을 요청합니다. 따라서 요청이 원래 호스트에 도달할 수 없습니다.
답변3
내 생각엔 https를 전혀 사용할 수 없는 서버에서 https: 포트를 사용하려고 하는 것 같습니다. 이 경우 서버는 여전히 HTTP 요청이 끝나기를 기다리고 있는 반면, 클라이언트는 서버가 SSL 핸드셰이크를 계속하기를 기다리고 있습니다. 브라우저를 사용하여 https로 정확히 동일한 URL에 액세스할 수 있는지 확인하세요.
답변4
논평할 포인트가 충분하지 않지만 Charlie의 답변은 변장 설정 문제를 해결하는 데 도움이 되었습니다. 하지만 내 경우에는 ppp0 연결이 나가기 때문에 장치를 제거할 수 없습니다.
이 경우 직접 또는 dhcpd 구성을 통해 다른 클라이언트의 MTU를 ppp0 장치 값(1492)으로 줄이는 데 도움이 되었습니다. 이 경우 증상은 이메일을 받으려고 할 때의 TLS 핸드셰이크 문제(일부 서버에만 해당) 및 다른 클라이언트의 비디오 스트리밍 문제입니다.