
최근까지 잘 작동하던 이 웹사이트가 있습니다. 이제 사용자들은 iPhone 및 iPad에서 열리지 않는다고 보고하고 있습니다.
iOS에서 어떤 브라우저를 사용하더라도 작동하지 않습니다. 또한 Mac 컴퓨터에서 탐색할 때 Safari에서는 열리지 않습니다. 다른 브라우저는 잘 작동합니다(Mac OSX만 해당, iOS는 해당 안 됨).
서버 구성은 다음과 같습니다.
DigitalOcean + Ubuntu 18.04 + Nginx + PHP 7.3(Laravel) + SSL 암호화 + HTTP2 활성화
더 자세히 설명하기 전에 위와 동일한 유형의 구성을 사용하면 제대로 실행되고 모든 장치에서 액세스할 수 있는 또 다른 서버가 있다는 점을 언급하고 싶습니다. 분명히 도메인 이름과 IP 주소를 제외하면 구성 및 설정 측면에서 거의 동일합니다.
언급할 가치가 있다고 생각되는 또 다른 작은 추가 정보는 내 사용자가 이란에 있다는 것입니다.
제가 확인한 사항 목록은 다음과 같습니다.
- iOS 및 Mac에서 ping 명령을 사용하여 도메인에 액세스할 수 있습니다.
- IP 주소 자체에도 액세스할 수 있으며 사이트를 탐색하는 데 사용할 수 있으며 "잘못된 SSL 인증서" 경고만 표시됩니다.
- 도메인에 사용된 DNS는 모두 iOS 및 Mac에서 ping이 가능합니다.
- VPN 연결을 사용하면 해당 사이트에 접속할 수 있습니다. 도메인, IP, DNS 등 모든 것이 기술적으로 접근 가능하기 때문에 정말 이상합니다.
- VPN을 사용하는 것 외에도 SSL이 완전히 꺼지거나 비활성화된 경우에도 사이트에 액세스할 수 있습니다.
- Let's Encrypt SSL을 사용하는 다른 공개 웹사이트에는 모두 액세스할 수 있습니다. 따라서 Let's Encrypt 문제가 될 수 없습니다.
지금까지 시도한 내용은 다음과 같습니다.
- 수많은 인터넷 검색. 나는 심지어 동일한 유형의 문제를 가진 사용자를 만났습니다.여기그리고여기그리고여기
- HTTP2를 비활성화해 보았습니다.
- 방화벽 설정을 두 번 확인하고 비활성화해 보았습니다.
- GZIP을 비활성화해 보았습니다.
- ssllabs.com에서 SSL 테스트를 수행했는데 아무런 문제가 없으며 작업 서버와 동일합니다.
keepalive_disable "safari"
nginx 구성에서 사용해 보았습니다 .ssl_protocols
TLSv1.3만 허용하거나 TLSv1.0을 삭제하는 등 값 교환을 시도했습니다.- 사용해 보았습니다
ssl_session_cache
- 및
ssl_ecdh_curve
로 변경해 보았습니다 .auto
secp384r1
- 및
ssl_ciphers
로 변경해 보았습니다 .HIGH:!aNULL:!MD5;
EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
- 및
ssl_session_tickets
로 변경해 보았습니다 .on
off
- 사용해 보았습니다
Strict-Transport-Security
/etc/letsencrypt/options-ssl-nginx.conf
certbot에서 사용하는 댓글을 사용해 보았습니다.- 다른 HTTP에서 HTTPS로의 리디렉션 설정을 시도했습니다.
- 테스트할 때 사이트에 접속하려는 잘못된 캐시 시도가 없는지 확인하기 위해 비공개 탭을 사용했습니다.
- 구성 파일을 변경할 때마다 nginx를 다시 로드하고 다시 시작했습니다.
sudo reboots
단순한 재부팅 문제가 아닌지 확인하기 위해 많은 작업을 수행했습니다 .
최후의 수단으로 OS를 처음부터 다시 설치하고 서버를 다시 설정하는 수고도 겪었습니다. 여전히 작동하지 않습니다.그리고 아니요, 구성 파일을 복사하지 않았습니다. 모든 명령을 수동으로 수행하고 구성 파일을 신중하게 수정하여 이전 설정에서 문제가 발생하지 않도록 했습니다. 이는 또한 Let's Encrypt(cerbot 사용)에서 새로운 SSL 요청을 수행했음을 의미합니다. 새로운 것을 생성하는지 아니면 지난 번에 보낸 것을 보내주는지는 모르겠지만요.
편집 1: 여기에 뜬금없는 생각을 던져보고 싶습니다. 고급 네트워킹에 대해서는 잘 모르지만 이란 검열 방화벽의 무언가가 SSL 연결을 방해하여 Apple 장치의 연결 설정에 실패할 수 있습니다. Apple은 자체 방식이 엄격하고 Chrome 및 Firefox와는 달리 특정 SSL 연결이 필요하다고 들었습니다. 그 2개는 약간의 오류를 무시할 수 있지만 Apple 장치는 그렇지 않습니다.
편집 2: Wireshark가 탭핑되는 동안 Safari를 확인했습니다. 내가 무엇을 하든 단지 소수의 패킷만 교환되는 것 같습니다. 또한 nginx 구성에서 비활성화했는데도 Safari가 TLSv1.0을 사용하고 있는 것 같습니다. Safari가 서버와 통신하는 데 사용하지 않도록 완전히 끄는 방법을 정말로 모르겠습니다.
편집 3: 다른 SSL(comodo의 3개월 무료 SSL 평가판 프로그램 사용)을 사용해 보았으나 문제가 여전히 존재합니다... 일부 사람들은 SSL을 변경한 후 비슷한 문제를 해결했다고 말하는 것을 읽었습니다. 왜 그것이 나에게 효과가 없는지 모르겠습니다.
편집 4: DNS 문제인지 확인하기 위해 해당 도메인의 DNS 서버를 변경해 보기로 했습니다. 왜, 어떻게 변경했는지는 모르겠지만 Safari에서 사이트를 잠시 로드할 수 있었습니다. 그러나 얼마 후 다시 작동이 멈췄습니다.
편집 5: 내 사이트에서 Google Analytics와 같은 외부 스크립트 코드를 비활성화하는 것은 운이 좋지 않습니다(그 서비스가 이란인에 대해 차단되어 있기 때문입니다). 다시 한 번, 일부 사람들은 외부 스크립트를 비활성화하여 문제를 해결했다는 보고서를 읽었습니다.
편집 6: 나는 이것이 네트워킹이나 서버 구성 문제가 아니라고 믿기 시작했습니다. 정말 제3자가 요청을 방해하는 것 같습니다. 저는 Apple과 Apple이 네트워킹을 어떻게 처리하는지 모르지만, Apple 연결/패킷 협상으로 인해 일종의 위험 신호가 발생하고 있으며 이로 인해 이란의 검열/방화벽으로 인해 클라이언트 연결이 끊어지는 것 같습니다.
편집 7: 새로운 IP 주소로 서버의 데이터 센터도 변경했습니다. 문제는 여전히 존재합니다 :(
편집 8/var/log/nginx/error.log
: 로 설정했을 때의 출력 입니다 debug
. Safari 클라이언트에서 요청을 시작하면 다음 줄이 표시됩니다.
PHP 병목 현상 문제가 아닌지 확인하기 위해 php fpm을 비활성화하려고 했습니다. 또한 PHP fpm 구성 파일에 충돌 net.core.somaxconn
하거나 1024
증가하는 것과 같은 임의의 매개변수를 조정하려고 했습니다 . backlog
또한 Everythink를 사용하는 시스템이 정상적으로 보이는 것을 볼 때 htop
CPU 사용량이 급증하지 않고 특정 프로세스가 목록의 맨 위로 올라가는 경우도 없습니다.
편집 9: 웹서버 문제인지 확인하기 위해 Nginx를 Apache2로 교체했습니다. 글쎄, 그렇지 않았습니다.
답변1
귀하와 웹사이트 사이의 프록시가 의심스럽기 때문에 ssh에서 -L 옵션을 사용하여 프록시를 우회할 수 있습니까? 이는 프록시로 변경할 수 없는 귀하와 귀하의 웹사이트 사이에 보안 터널을 제공합니다.
예를 들어 데스크탑에서 다음을 실행합니다: ssh -L 2222:127.0.0.1:443[이메일 보호됨]
이 명령이 서버에 로그인되면 동일한 데스크탑에서 브라우저를 실행하여https://127.0.0.1:2222
이제 사이트와 해당 SSL 인증서가 표시되면 모든 것이 올바르게 설정된 것입니다. 터널을 사용하지 않을 때 SSL 연결을 중간에 변경하는 사람이 있습니다.
답변2
나설립하다내 문제에 대한 임시 해결책. 방금 서버를 다른 호스팅/데이터 센터로 옮겼습니다!
업데이트:실제로 몇달이 지나서 또 문제가 발생했는데... 어떤 기술적인 문제로 인해 문제가 발생하는지, 어떻게 해결해야 하는지 정말 모르겠습니다.
업데이트 2:IT 네트워킹 전문가와 이야기를 나눴는데 문제가 실제로 내 도메인 이름을 포착하는 정부 방화벽 규칙(허위/잘못된 검열)에 달려 있으며 내가 사용하는 웹 서버 구성이나 웹 호스팅이 무엇인지는 중요하지 않고 계속 차단되기만 한다고 말했습니다. 내 손이 닿지 않는 방화벽으로 인해.
답변3
인증서일 수도 있습니다. SubjectAlternativeName이 올바르게 설정되어 있습니까? DNS 이름으로 SubjectName만 사용하는 것은 더 이상 사용되지 않습니다. 인증서 고정, OSCP 스테이플링, HSTP 및 기타 비교적 새로운 TLS 설정을 사용합니까? 이로 인해 규제된 네트워크에서 문제가 발생할 수 있습니다.
일부 인터넷 사용자는 SSL 검사와 함께 프록시를 사용해야 합니다. 많은 기업 환경에서는 IronPort 또는 Bluecoat와 유사한 제품을 사용하여 보안 정책의 일부로 비밀 채널 및 맬웨어를 탐지합니다. 이를 수행하는 방법은 언더그라운드 잡지 Phrack 76의 기사에서 시작되었습니다. 이는 각 클라이언트가 신뢰하는 프록시의 추가 CA 루트 인증서를 갖고, 차례로 프록시가 대신하여 연결을 다시 시작하는 간단한 설정으로 요약됩니다. 각 클라이언트는 MIT의 "SSL 개방"을 통해 이란 및 중국과 같은 국가에서 인터넷을 전체적으로 모니터링합니다. 이로 인해 PFS가 없으며 서버의 암호화를 확인하는 클라이언트에 따라 여러 가지 작업이 실패할 수 있습니다. 변경되거나 SSL이 완전히 제거되기 때문입니다. 신경 쓰지 않는다면 언급된 옵션을 제거하여 서버 인증서 설정을 "내보내기 품질"로 다운그레이드할 수 있습니다.
답변4
@austin-dixon의 답변이 올바른 방향으로 가고 있습니다. 해당 테스트는 사용자가 있는 동일한 국가에서 수행되어야 하며, 해당 국가에 아직 있지 않은 경우에는 선택 사항이 아닐 수 있습니다.
최소한 Qualys SSL 테스트를 사용하여 구성의 유효성을 검사할 수 있습니다.https://www.ssllabs.com/ssltest/. 이 경우 문자 점수는 중요하지 않습니다. Handshake Simulation까지 아래로 스크롤하여 Apple 장치가 일반적인 상황에서 어떻게 작동할지 확인하세요.
어느 쪽이든 이미 의심하고 있는 사용자와 사이트 사이에 뭔가가 있다는 사실이 확인되었습니다. 개발자가 HTTPS를 완전히 비활성화하지 않는 한 이러한 상황을 해결할 수 있는 방법은 많지 않습니다. 중간에 있는 사람이 서버에 구성된 것보다 약한 암호화 제품군이나 낮은 TLS 버전을 요구할 수도 있지만, 이 경우 어떤 버전을 제안해야 할지 모르겠습니다.