डोमेन, HTTPS और रिवर्स प्रॉक्सी
Caddy प्रोफ़ाइल या अपने रिवर्स प्रॉक्सी का उपयोग करके Antimatter को HTTPS के साथ एक डोमेन नाम पर रखें, और साइट URL और क्लाइंट एड्रेस सही करें।
साइट URL
साइट URL (ServiceSettings.SiteURL) वह पता है जिसके माध्यम से लोग Antimatter तक पहुँचते हैं, जैसे https://chat.example.com। सर्वर इसका उपयोग ईमेल और सूचनओं में लिंक, साइन-इन रीडायरेक्ट (OAuth, OpenID Connect, SAML), मोबाइल और डेस्कटॉप ऐप्स, और अनुरोधों के स्रोत की जाँच के लिए करता है। इसे ब्राउज़र के एड्रेस बार में दिए गए पते के बिल्कुल समान सेट करें: स्कीम, डोमेन और डिफ़ॉल्ट न होने पर पोर्ट, बिना अंत में स्लैश के।
- साइट के compose फ़ाइल के साथ:
.envमेंSITE_URL। - कहीं और:
AM_SERVICESETTINGS_SITEURL, या सिस्टम कंसोल › पर्यार्वण › वेब सरवर › साइट URL.
यदि साइट URL गलत है, तो पहचान प्रदाता (identity provider) के साथ साइन-इन विफल हो जाता है, ईमेल में लिंक गलत जगह पर इशारा करते हैं, और ऐप्स कनेक्ट नहीं कर पाते हैं। डोमेन बदलने के बाद, इसे यहाँ और हर पहचान प्रदाता के रीडायरेक्ट URL में अपडेट करें।
बंडल्ड Caddy प्रोफ़ाइल के साथ HTTPS
साइट की compose.yaml में https प्रोफ़ाइल में Caddy सर्विस शामिल है। यह Let's Encrypt से प्रमाणपत्र प्राप्त करता है, इसे स्वतः नवीनीकृत करता है, HTTP को HTTPS में रीडायरेक्ट करता है, और सब कुछ, वेबसॉकेट समेत, Antimatter को फॉरवर्ड करता है।
- अपने डोमेन का DNS रिकॉर्ड (A, और IPv6 के लिए AAAA) सर्वर की ओर इशारा करें।
- फ़ायरवॉल में पोर्ट 80/tcp, 443/tcp और 443/udp (HTTP/3) खोलें। Let's Encrypt को इंटरनेट से पोर्ट 80 या 443 तक पहुँचना चाहिए।
- डोमेन को
.envमें जोड़ें और साइट URL सेट करें:echo "DOMAIN=chat.example.com" >> .env sed -i 's|^SITE_URL=.*|SITE_URL=https://chat.example.com|' .env - प्रोफ़ाइल के साथ शुरू करें:
docker compose --profile https up -d
बाद के हर docker compose up में --profile https जोड़ें, या .env में COMPOSE_PROFILES=https रखें ताकि साधारण docker compose up -d इसे शामिल करे। Caddy अपने प्रमाणपत्र https वॉल्यूम में रखता है।
Antimatter का अपना पोर्ट होस्ट पर प्रकाशित रहता है (HTTP_PORT, डिफ़ॉल्ट रूप से 8065)। Caddy के आगे होने पर, इसे केवल सर्वर के लिए ही रखें:
echo "HTTP_PORT=127.0.0.1:8065" >> .env
docker compose --profile https up -d
Caddy Antimatter तक आंतरिक edge नेटवर्क के माध्यम से पहुँचता है, उस पोर्ट के माध्यम से नहीं, इसलिए यह आपके उपयोगकर्ताओं के लिए कुछ भी नहीं बदलता।
अपने रिवर्स प्रॉक्सी (nginx) के साथ
यदि सर्वर पर पहले से ही nginx या कोई अन्य प्रॉक्सी चल रहा है, तो https प्रोफ़ाइल बंद रखें और प्रॉक्सी को Antimatter के पोर्ट 8065 पर निर्देशित करें। प्रॉक्सी को निम्नलिखित कार्य करने होंगे:
- वेबसॉकेट अपग्रेड पास करना (वेब ऐप और मोबाइल ऐप्स
/api/v4/websocketपर एक वेबसॉकेट खुला रखते हैं, और कुछ ऐप्स अपने स्वयं के वेबसॉकेट खोलते हैं); - अधिकातम फ़ाईल आकार (100 MB, डिफ़ॉल्ट रूप से) के बराबर या उससे बड़े रिकवेस्ट बॉडी स्वीकार करें (अधिकातम फ़ाईल आकार);
- लंबे समय तक चलने वाले कनेक्शन खुले रखना (वेबसॉकेट, बड़े अपलोड और डाउनलोड);
Hostहेडर और क्लाइंट का पता पास करना।
antimatter-docker में प्रोडक्शन टेम्पलेट से अनुकूलित एक पूर्ण सर्वर ब्लॉक। डोमेन और सर्टिफिकेट पथों को बदलें:
upstream antimatter {
server 127.0.0.1:8065;
keepalive 64;
}
map $http_upgrade $connection_upgrade {
default upgrade;
'' '';
}
proxy_cache_path /var/cache/nginx/antimatter levels=1:2 keys_zone=antimatter_cache:10m
max_size=3g inactive=120m use_temp_path=off;
server {
listen 80;
listen [::]:80;
server_name chat.example.com;
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name chat.example.com;
ssl_certificate /etc/ssl/chat.example.com/fullchain.pem;
ssl_certificate_key /etc/ssl/chat.example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_timeout 1d;
ssl_session_cache shared:AntimatterSSL:10m;
ssl_session_tickets off;
add_header Strict-Transport-Security "max-age=31536000" always;
# At least FileSettings.MaxFileSize (100 MB by default).
client_max_body_size 100M;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_buffers 256 16k;
proxy_buffer_size 16k;
location ~ ^/api/v[0-9]+/(users/)?websocket$ {
client_body_timeout 60s;
send_timeout 300s;
lingering_timeout 5s;
proxy_connect_timeout 90s;
proxy_send_timeout 300s;
proxy_read_timeout 90s;
proxy_pass http://antimatter;
}
location / {
proxy_read_timeout 600s;
proxy_cache antimatter_cache;
proxy_cache_revalidate on;
proxy_cache_min_uses 2;
proxy_cache_use_stale timeout;
proxy_cache_lock on;
proxy_pass http://antimatter;
}
}
फ़ाइल की जाँच nginx -t से करें और इसे लागू करने के लिए systemctl reload nginx चलाएँ। सर्वर स्वयं X-Content-Type-Options, Referrer-Policy, Permissions-Policy और X-Frame-Options भेजता है; केवल HSTS प्रॉक्सी पर निर्भर करता है। एक बार जब HTTPS काम करे, तो इसकी max-age बढ़ाएँ, और includeSubDomains केवल तभी जोड़ें यदि सभी सबडोमेन HTTPS का उपयोग कर रहे हैं।
Docker Compose और होस्ट पर nginx के साथ, ऊपर दिया गया upstream प्रकाशित पोर्ट 8065 पर निर्देशित करता है। इसे केवल 127.0.0.1 पर प्रकाशित करें (HTTP_PORT=127.0.0.1:8065), ताकि कोई भी प्रॉक्सी को बायपास न कर सके।
antimatter-docker रिपॉज़िटरी में nginx के साथ एक पूर्ण सेटअप है, जो एक कंटेनर में है और certbot के माध्यम से Let's Encrypt का उपयोग करता है, deploy/compose में।
अन्य प्रॉक्सी
यदि कोई भी प्रॉक्सी ऊपर दिए गए चार बिंदुओं को पूरा करता है, तो वह काम करेगा। ऑडियो और वीडियो कॉल कभी प्रॉक्सी से नहीं गुजरते: वे अपने स्वयं के पोर्ट का उपयोग करते हैं, देखें Calls and voice।
प्रॉक्सी के पीछे क्लाइंट पते
प्रॉक्सी के पीछे, हर अनुरोध प्रॉक्सी से आता प्रतीत होता है। वास्तविक क्लाइंट पते को लॉग करने, क्लाइंट के अनुसार रेट लिमिट लागू करने और IP फ़िल्टरिंग का उपयोग करने के लिए, सर्वर को बताएं कि कौन सा हेडर पते को ले जाता है, और किन प्रॉक्सी पर विश्वास किया जा सकता है। इनमें से किसी सेटिंग के लिए System Console में कोई फ़ील्ड नहीं है: इन्हें config.json में या वेरिएबल्स के साथ सेट करें।
| की और वेरिएबल | डिफ़ॉल्ट | यह क्या करता है |
|---|---|---|
ServiceSettings.TrustedProxyIPHeader, AM_SERVICESETTINGS_TRUSTEDPROXYIPHEADER | खाली: सर्वर कनेक्शन के पते का उपयोग करता है | हेडर जो क्लाइंट का पता ले जाते हैं, उदाहरण के लिए X-Forwarded-For। अनुरोध में मौजूद पहला हेडर उपयोग किया जाता है। |
ServiceSettings.TrustedProxyIPs, AM_SERVICESETTINGS_TRUSTEDPROXYIPS | खाली | आपके प्रॉक्सी के पते या CIDR रेंज, उदाहरण के लिए 172.29.71.0/28। हेडर केवल उन अनुरोधों के लिए मान्य हैं जो इनमें से किसी एक से आते हैं। |
एक वेरिएबल में, कई मानों को स्पेस से अलग करें: AM_SERVICESETTINGS_TRUSTEDPROXYIPHEADER="X-Forwarded-For X-Real-IP"। सर्वर एक कॉन्फ़िगरेशन को अस्वीकार कर देता है जिसमें TrustedProxyIPs में कोई एंट्री हो जो न तो IP एड्रेस हो और न CIDR रेंज।
सर्वर क्लाइंट का एड्रेस कैसे खोजता है
हर प्रॉक्सी X-Forwarded-For के दाईं ओर उस एड्रेस को जोड़ता है जिससे उसे रिक्वेस्ट मिला। क्लाइंट ने हेडर में जो भेजा था, वह बाईं ओर रह जाता है। इसलिए सर्वर हेडर को दाईं ओर से पढ़ता है, अपने विश्वसनीय प्रॉक्सी के एड्रेस छोड़ देता है, और पहला अन्य एड्रेस क्लाइंट का मानता है। क्लाइंट अपने हेडर भेजकर अपना एड्रेस चुन नहीं सकता।
- एक प्रॉक्सी के पीछे,
TrustedProxyIPHeaderअकेला सही एड्रेस देता है: सर्वर हेडर के सबसे दाईं ओर के एड्रेस को लेता है। जब तक आपTrustedProxyIPsभी सेट नहीं करते, स्टार्टअप पर यह एक वार्निंग लॉग करता है। इसके बिना, जो भी सीधे पोर्ट 8065 तक पहुँचता है, वह हेडर सेट कर सकता है, इसलिए उस पोर्ट को केवल127.0.0.1या एक निजी नेटवर्क पर पब्लिश करें। - कई प्रॉक्सी के पीछे, उदाहरण के लिए आपके अपने प्रॉक्सी के सामने एक CDN या लोड बैलेंसर, सभी को
TrustedProxyIPsमें सूचीबद्ध करें। अन्यथा सर्वर बाहरी प्रॉक्सी का एड्रेस क्लाइंट का मान लेगा। - प्रॉक्सी हेडर को उस एड्रेस से बदल सकता है जो वह देखता है, जैसा कि ऊपर दिए गए nginx उदाहरण में किया गया है (
X-Forwarded-For $remote_addr), या उसे जोड़ सकता है (nginx का$proxy_add_x_forwarded_for)। दोनों काम करते हैं।
कौन से एड्रेस सूचीबद्ध करें
उस एड्रेस को सूचीबद्ध करें जिससे प्रॉक्सी के रिक्वेस्ट आते हैं, जैसा कि Antimatter उसे देखता है।
- साइट के compose फ़ाइल और Caddy के साथ, यह पहले से हो चुका है: Caddy
edgeनेटवर्क के माध्यम से Antimatter तक पहुँचता है, और compose फ़ाइलTrustedProxyIPHeaderकोX-Forwarded-ForऔरTrustedProxyIPsको उस नेटवर्क की रेंज,EDGE_SUBNET(172.29.71.0/28, यदि आपने.envमें इसे नहीं बदला है) सेट करती है। यदिEDGE_SUBNETआपके किसी नेटवर्क से ओवरलैप करता है, तो उसे बदलें। - antimatter-docker में प्रोडक्शन सेटअप अपने nginx कंटेनर के लिए
FRONTEND_SUBNETके साथ वही करता है। - यदि होस्ट पर nginx है और Antimatter Docker में है, तो रिक्वेस्ट Antimatter तक पब्लिश किए गए पोर्ट के माध्यम से पहुँचते हैं, आमतौर पर compose प्रोजेक्ट के नेटवर्क के गेटवे एड्रेस से (
docker network inspectइसे दिखाता है)।compose.override.yamlमेंAM_SERVICESETTINGS_TRUSTEDPROXYIPSको उस एड्रेस सेट करें। - Docker के बिना, यदि nginx उसी होस्ट पर है, तो यह
127.0.0.1होता है (और यदि nginx IPv6 के माध्यम से कनेक्ट करता है, तो::1।)
प्रॉक्सी के बिना TLS
सरवर स्वयं HTTPS भी सर्व कर सकता है, सिस्टम कंसोल › पर्यार्वण › वेब सरवर में: कनेक्शन सुरक्षा को TLS (ServiceSettings.ConnectionSecurity) पर सेट करें, साथ में TLS प्रमाणपत्र फ़ाईल और TLS कुंजी फ़ाईल (ServiceSettings.TLSCertFile, ServiceSettings.TLSKeyFile), या Let's Encrypt का उपयोग करें (ServiceSettings.UseLetsEncrypt)। तब सरवर को पोर्ट 443 पर लिसन करना होगा (लिसन एड्रेस, ServiceSettings.ListenAddress, डिफ़ॉल्ट रूप से :8065), और ServiceSettings.Forward80To443 पोर्ट 80 को रीडायरेक्ट करता है। रिवर्स प्रॉक्सी चलाना और रिन्यू करना आसान है, और यह गाइड इसी की मान लेती है।
सर्वर टाइमआउट और रिक्वेस्ट साइज़
सरवर के अपने वेब सरवर की सेटिंग्स, सिस्टम कंसोल › पर्यार्वण › वेब सरवर में:
| सेटिंग | कुंजी | डिफ़ॉल्ट |
|---|---|---|
| लिसन एड्रेस | ServiceSettings.ListenAddress | :8065 |
| रीड टाइमआउट | ServiceSettings.ReadTimeout | 300 सेकंड |
| लिखने का टाइमआउट | ServiceSettings.WriteTimeout | 300 सेकंड |
| आइडल टाइमआउट (System Console में कोई फील्ड नहीं) | ServiceSettings.IdleTimeout | 60 सेकंड |
| अधिकातम पेयलॉड आकार (बाइट) | ServiceSettings.MaximumPayloadSizeBytes | सुरक्षा देखें |
सामान्य रिकवेस्ट के लिए प्रॉक्सी के अपने टाइमआउट को इनसे कम न रखें, और उसके बॉडी आकार को कम से कम अधिकातम फ़ाईल आकार रखें।