NGINX를 SSL 및 HTTP/2로 구성
NGINX는 /etc/nginx/sites-available 디렉터리에 있는 파일을 사용하여 구성됩니다. 파일을 만들고 활성화해야 합니다. 파일을 만들 때 Mattermost 서버의 IP 주소와 Mattermost 웹사이트의 완전한 도메인 이름(FQDN)이 필요합니다.
SSL을 사용하면 Mattermost 클라이언트와 Mattermost 서버 간의 통신이 암호화되어 보안이 강화됩니다. 또한 NGINX를 HTTP/2 프로토콜을 사용하도록 구성할 수 있습니다.
SSL 없이도 HTTP/2를 구성할 수 있지만, Firefox와 Chrome 브라우저는 안전한 연결에서만 HTTP/2를 지원합니다.
원하는 인증서를 사용할 수 있지만, 이 지침은 무료 인증 기관 Let’s Encrypt 에서 인증서를 다운로드하고 설치하는 방법을 안내합니다.
Note
Let’s Encrypt이 활성화된 경우에는 Forward80To443 “config.json” 설정을 true 로 설정하여 Let’s Encrypt 인증을 완료하기 위해 방화벽을 통해 포트 80을 전달해야 합니다. 자세한 내용은 Let’s Encrypt/Certbot documentation 을 참조하십시오.
NGINX를 호스팅하는 서버에 로그인하고 터미널 창을 엽니다.
텍스트 편집기로 Mattermost
nginx.conf파일을 *root*로 열고,upstream backend의{ip}주소를 Mattermost(예:127.0.0.1:8065)로,server_name을 Mattermost의 도메인으로 업데이트합니다.
Note
Ubuntu에서 이 파일은
/etc/nginx/sites-available/에 있습니다. 이 파일이 없는 경우sudo touch /etc/nginx/sites-available/mattermost를 실행합니다.CentOS/RHEL에서 이 파일은
/etc/nginx/conf.d/에 있습니다. 이 파일이 없는 경우sudo touch /etc/nginx/conf.d/mattermost를 실행합니다.이 설명서의 예제에 포함된 IP 주소가 네트워크 구성과 일치하지 않을 수 있습니다.
만약 NGINX를 Mattermost와 동일한 머신에서 실행하고 NGINX가
localhost를 하나 이상의 IP 주소 (IPv4 또는 IPv6)로 해석하는 경우,localhost대신에127.0.0.1을 사용하는 것을 권장합니다.upstream backend { server {ip}:8065; keepalive 32; } proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off; server { listen 80 default_server; server_name mattermost.example.com; location ~ /api/v[0-9]+/(users/)?websocket$ { proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; client_max_body_size 50M; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; client_body_timeout 60; send_timeout 300; lingering_timeout 5; proxy_connect_timeout 90; proxy_send_timeout 300; proxy_read_timeout 90s; proxy_pass http://backend; } location / { client_max_body_size 50M; proxy_set_header Connection ""; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; proxy_read_timeout 600s; proxy_cache mattermost_cache; proxy_cache_revalidate on; proxy_cache_min_uses 2; proxy_cache_use_stale timeout; proxy_cache_lock on; proxy_http_version 1.1; proxy_pass http://backend; } }
기존의 기본 sites-enabled 파일을 제거하려면
sudo rm /etc/nginx/sites-enabled/default(Ubuntu) 또는sudo rm /etc/nginx/conf.d/default(RHEL 8)을 실행합니다.Mattermost 구성을 활성화하려면
sudo ln -s /etc/nginx/sites-available/mattermost /etc/nginx/sites-enabled/mattermost(Ubuntu) 또는sudo ln -s /etc/nginx/conf.d/mattermost /etc/nginx/conf.d/default.conf(RHEL 8)을 실행합니다.구성이 올바르게 완료되었는지 확인하려면
sudo nginx -t를 실행합니다. 오류가 발생하면 NGINX 구성을 검토하고/etc/nginx/sites-available/mattermost파일을 수정해야 합니다.sudo systemctl start nginx를 실행하여 NGINX를 다시 시작합니다.curl http://localhost를 실행하여 프록시를 통해 Mattermost를 확인합니다.
모든 것이 정상적으로 작동하면 Mattermost 가입 페이지의 HTML을 볼 수 있습니다. IP 또는 localhost로 액세스할 때 유효하지 않은 인증서가 표시됩니다. SSL 인증서가 올바르게 고정되었고 유효한지 확인하려면 완전한 FQDN 도메인을 사용하십시오.
sudo snap install core; sudo snap refresh core를 실행하여 Snap을 설치하고 업데이트합니다.sudo snap install --classic certbot을 실행하여 Certbot 패키지를 설치합니다.Certbot이 실행될 수 있도록 심볼릭 링크를 추가하려면
sudo ln -s /snap/bin/certbot /usr/bin/certbot을 실행합니다.DNS가 올바르게 구성되었는지 Dry-run을 실행하여 Let’s Encrypt 설치기가 정상적으로 실행되는지 확인하려면
sudo certbot certonly --dry-run을 실행합니다.
이 작업은 이메일 주소를 입력하고 TOS를 수락하고 이메일을 공유하며 certbot을 활성화하는 도메인을 선택하라는 메시지가 표시됩니다. 이를 통해 DNS가 이 서버를 올바르게 가리키고 인증서를 성공적으로 생성할 수 있는지 확인합니다. 이 작업이 성공하면 단계 12로 진행하십시오.
sudo certbot을 실행하여 Let’s Encrypt 설치기를 실행합니다. 이 작업은 certbot을 실행하고 선택한 사이트의 NGINX 구성 파일을 자동으로 수정합니다.SSL이 올바르게 구성되었는지 확인하려면
curl https://{your domain here}을 실행합니다.마지막으로, SSL 보안 설정을 기본 Let’s Encrypt 이상으로 수정하도록 config 파일을 편집하는 것을 권장합니다. 이는 위의 단계 2에서 사용한 파일과 동일합니다.
upstream backend { server {ip}:8065; keepalive 32; } proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off; server { server_name mattermost.example.com; location ~ /api/v[0-9]+/(users/)?websocket$ { proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; client_max_body_size 50M; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; client_body_timeout 60; send_timeout 300; lingering_timeout 5; proxy_connect_timeout 90; proxy_send_timeout 300; proxy_read_timeout 90s; proxy_http_version 1.1; proxy_pass http://backend; } location / { client_max_body_size 50M; proxy_set_header Connection ""; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_buffers 256 16k; proxy_buffer_size 16k; proxy_read_timeout 600s; proxy_cache mattermost_cache; proxy_cache_revalidate on; proxy_cache_min_uses 2; proxy_cache_use_stale timeout; proxy_cache_lock on; proxy_http_version 1.1; proxy_pass http://backend; } listen 443 ssl http2; # managed by Certbot ssl_certificate /etc/letsencrypt/live/mattermost.example.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/mattermost.example.com/privkey.pem; # managed by Certbot # include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot ssl_session_timeout 1d; # Enable TLS versions (TLSv1.3 is required upcoming HTTP/3 QUIC). ssl_protocols TLSv1.2 TLSv1.3; # Enable TLSv1.3's 0-RTT. Use $ssl_early_data when reverse proxying to # prevent replay attacks. # # @see: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_early_data ssl_early_data on; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:50m; # HSTS (ngx_http_headers_module is required) (15768000 seconds = six months) add_header Strict-Transport-Security max-age=15768000; # OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on; } server { if ($host = mattermost.example.com) { return 301 https://$host$request_uri; } # managed by Certbot listen 80 default_server; server_name mattermost.example.com; return 404; # managed by Certbot }
SSL 인증서가 올바르게 설정되었는지 확인하세요.
SSL 인증서를 https://www.ssllabs.com/ssltest/index.html 와 같은 사이트를 방문하여 테스트하세요.
빈 곳이나 인증서 경로에 대한 오류가 있는 경우 중간 인증서가 누락된 것으로 포함해야 합니다.
NGINX 구성 FAQ
웹소켓 연결이 403 오류를 반환하는 이유는 무엇인가요?
이는 크로스-오리진 검사에 실패한 것으로 보입니다. 웹소켓 코드에서 Origin 헤더가 호스트 헤더와 동일한지 확인하는 검사가 적용됩니다. 동일하지 않은 경우 403 오류가 반환됩니다. 루트로 텍스트 편집기에서 /etc/nginx/sites-available/mattermost 파일을 열고 프록시에서 설정되는 호스트 헤더가 동적인지 확인하세요.
location ~ /api/v[0-9]+/(users/)?websocket$ {
proxy_pass http://backend;
(...)
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
그런 다음 config.json 에서 AllowCorsFrom 설정을 클라이언트가 사용하는 도메인과 일치하도록 설정하세요. 클라이언트가 보낼 수있는 호스트 이름의 변형을 추가해야 할 수도 있습니다. 문제를 진단하는 데 NGINX 로그가 도움이 될 것입니다.
"EnableUserAccessTokens": false,
"AllowCorsFrom": "domain.com domain.com:443 im.domain.com",
"SessionLengthWebInDays": 30,
웹소켓 오류에 대한 기타 문제 해결 팁은 여기에서 확인하세요 .
Mattermost Docker 설치를 사용한 NGINX 프록시를 어떻게 설정하나요?
Mattermost 네트워크의 이름을 찾고 NGINX 프록시에 연결합니다.
docker network ls
# "mymattermost_default"와 같은 Mattermost 네트워크의 이름을 찾습니다.
docker network connect mymattermost_default nginx-proxy
Mattermost Docker 컨테이너를 다시 시작합니다.
docker-compose stop app
docker-compose start app
Tip
NGINX 프록시가 들어오는 요청을 허용하기 때문에 ‘web’ 컨테이너를 실행할 필요가 없습니다.
docker-compose.yml파일을 업데이트하여VIRTUAL_HOST와expose지시문을 추가하세요.
environment:
# db 자격 증명 및 데이터베이스 이름과 동일하게 설정
- MM_USERNAME=mmuser
- MM_PASSWORD=mmuser-password
- MM_DBNAME=mattermost
- VIRTUAL_HOST=mymattermost.tld
expose:
- "80"
- "443"
Azure에서 Gitlab CE와 Mattermost를 함께 설치할 때 NGINX가 실패하는 이유는 무엇인가요?
Mattermost의 응용 프로그램 항목의 콜백 URL을 업데이트해야 할 수 있습니다.
관리자로서 GitLab 인스턴스에 로그인합니다.
Admin > Applications 으로 이동합니다.
GitLab-Mattermost에서 편집 을 선택합니다.
새 도메인/URL로 콜백 URL을 업데이트합니다.
변경사항을 저장합니다.
/etc/gitlab/gitlab.rb구성 파일에서 GitLab 및 Mattermost의 외부 URL을 업데이트합니다.
Certbot가 http-01 도전에 실패하는 이유는 무엇인가요?
yourdomain.com에 대한 인증서를 요청 중
다음 도전 수행 중:
yourdomain.com에 대한 http-01 도전
확인을 기다리는 중...
도메인 yourdomain.com에 대한 도전 실패
yourdomain.com에 대한 http-01 도전
도전 정리 중
일부 도전에 실패했습니다.
위의 오류가 표시된다면 대개 Certbot이 포트 80에 액세스할 수 없었기 때문입니다. 이는 방화벽 또는 다른 DNS 구성으로 인할 수 있습니다. A/AAAA 레코드가이 서버를 가리키도록하고 NGINX 구성 내의 server_name 이 리디렉션되지 않았는지 확인하십시오.
Note
Cloudflare을 사용하는 경우 force traffic to https 를 해제해야 합니다.
Certbot 속도 제한
만약 독립적으로 certbot을 실행 중이라면 다음과 같은 오류가 표시됩니다:
example.com에 대한 Let's Encrypt SSL/TLS 인증서를 발급할 수 없습니다.
example.com에 대해 Let's Encrypt 속도 제한 중 하나가 초과되었습니다.
자세한 내용은 관련 지식 베이스 문서를 참조하십시오.
세부 정보
https://acme-v02.api.letsencrypt.org/acme/new-order에서 유효하지 않은 응답입니다.
세부 정보:
유형: urn:ietf:params:acme:error:rateLimited
상태: 429
자세한 내용: 새 주문 생성 오류 :: 최근에 실패한 인증이 너무 많습니다: https://letsencrypt.org/docs/rate-limits/
만약 Mattermost 내에서 Let’s Encrypt를 실행 중이라면 다음과 같은 오류가 표시됩니다:
{"level":"error","ts":1609092001.752515,"caller":"http/server.go:3088","msg":"http: TLS handshake error from ip:port: 429 urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/","source":"httpserver"}
이는 인증서를 생성하려는 시도가 너무 많았음을 의미합니다. 자세한 내용은 여기 에서 찾을 수 있습니다.
