SSL का उपयोग करने वाली साइट के लिए एक रिवर्स प्रॉक्सी के रूप में Nginx

परिचय

Apgin को अपाचे के रूप में nginx को कॉन्फ़िगर कैसे करें और इसकी आवश्यकता क्यों है, इसे बार-बार लिखा जाता है, जिसमें Habré भी शामिल है। मेरा मामला क्लासिक से थोड़ा अलग है। यह सब हमेशा की तरह शुरू हुआ, अपाचे पर एक परियोजना, आगंतुकों की संख्या में वृद्धि और इससे संबंधित, अपर्याप्त सर्वर संसाधन। लेकिन ग्राहकों के साथ संचार की सुरक्षा के लिए परियोजना ने एसएसएल का उपयोग किया। मुझे क्या सामना करना पड़ा और मैंने कट के तहत बताई गई समस्याओं को कैसे हल किया।

समस्याओं

चूंकि क्लाइंट अनुरोधों का प्रत्यक्ष स्वागत nginx को दिया गया था, तो SSL के साथ काम करना होगा। अपाचे, जो अब लटका हुआ है लेकिन लूपबैक 127.0.0.1:8080 है, को SSL समर्थन की आवश्यकता नहीं है। पहली समस्या यह थी कि प्रमाणपत्र थावे से था, और उन्हें एक मध्यवर्ती प्रमाणपत्र के उपयोग की आवश्यकता थी। इस तरह के प्रमाणपत्रों के साथ काम करने के लिए नग्नेक्स के पास एक विशेष निर्देश नहीं है। अपाचे विन्यास में, यह इस तरह था:

<VirtualHost 1.2.3.4:443> ... SSLEngine on SSLCertificateFile /usr/local/ssl/www.blabla.ru/public.crt SSLCertificateKeyFile /usr/local/ssl/www.blabla.ru/private.key SSLCACertificateFile /usr/local/ssl/www.blabla.ru/intermediate.crt ... </VirtualHost> 

SSLCACertificateFile के साथ nginx में क्या करें? यह पता चला कि आपको अपनी सामग्री को एक (सार्वजनिक प्रमाणपत्र, उसके बाद एक मध्यवर्ती) में रखकर दो फाइलों को "मर्ज" करने की आवश्यकता है:

 cd /usr/local/ssl/www.blabla.ru cp public.crt public_concat.crt cat intermediate.crt >> public_concat.crt 

यह बात है, अब nginx में हम सिर्फ लिखते हैं:

  server { listen 1.2.3.4:443; server_name www.blabla.ru; ssl on; ssl_certificate /usr/local/ssl/www.blabla.ru/public_concat.crt; ssl_certificate_key /usr/local/ssl/www.blabla.ru/private.key; ... } 

असुरक्षित साइट से सुरक्षित पर पुनर्निर्देशित करने से सेटिंग में कोई कठिनाई नहीं हुई:

  server { listen 1.2.3.4:80; server_name www.blabla.ru blabla.ru; # rewrite ^(.*) https://www.blabla.ru$1 permanent; return 301 https://www.blabla.ru$request_uri; } 

अजाक्स के साथ कठिनाइयाँ शुरू हुईं। सर्वर के लिए एसिंक्रोनस अनुरोध http: // उपसर्ग के साथ किए गए थे, जिसके कारण 301 अनुप्रेषित था जो कि अजाक्स के लिए हानिकारक था। विशेष रूप से पर्यावरण चर को स्थानांतरित करने की आवश्यकता थी, विशेष रूप से, प्रोटोकॉल नाम, नगीनक्स से अपाचे तक, यह इस तरह से किया गया था:
नगीनक्स में:

  server { ... location / { ... proxy_set_header X-Forwarded-Proto $scheme; ... } ... } 

वर्चुअल होस्ट की परिभाषा में अपाचे में सबसे महत्वपूर्ण बात यह है:

 <VirtualHost 127.0.0.1:8080> ServerName www.blabla.ru ... SetEnvIf X-Forwarded-Proto https HTTPS=on ... </VirtualHost> 

अब सभी ajax अनुरोधों के अनुसार https: // पर जाएं। इस ट्रिक के लिए, अपाचे setenvif_module मॉड्यूल को इनस्टॉल और कॉन्फिगर किया जाना चाहिए:

 LoadModule setenvif_module libexec/apache22/mod_setenvif.so 

यह भी ध्यान में रखने योग्य है कि कुछ अनुप्रयोग स्वयं पर्यावरण चर का उपयोग करके अपना मार्ग निर्धारित कर सकते हैं। उदाहरण के लिए, phpMyAdmin, इसलिए संसाधन के डेवलपर्स द्वारा इसकी आवश्यकता होती है, अगर इसमें कॉन्फ़िगरेशन में निर्दिष्ट पूर्ण पथ नहीं है, तो यह इसे पोर्ट के साथ स्वयं बना देगा। तो मुझे कुछ ऐसा मिला:

 https://www.blabla.ru:80/myadmin 

यहाँ बात है: 80 सब कुछ खराब कर दिया, phpMyAdmin एक डांट के साथ नहीं खुला था कि एसएसएल सुरक्षा त्रुटि थी। इसे ठीक किया गया था, जैसा कि ऊपर बताया गया है, सीधे phpMyAdmin config में पथ का संकेत देकर:

 $cfg['PmaAbsoluteUri'] = 'https://www.blabla.ru/myadmin'; 

मौजूदा लॉगिंग योजना को बचाने के लिए अपाचे में आगंतुकों के वास्तविक आईपी पते को स्थानांतरित करने के बारे में मत भूलना। यह बार-बार चित्रित किया जाता है, अपाचे rpaf_module मॉड्यूल की ओर खुदाई करता है।

पुनश्च: सब कुछ FreeBSD 8.2, Apache 2.2.22_5, nginx-1.0.14.1 के तहत किया गया था। मैंने कॉन्फ़िगर के पूर्ण पाठ को अपलोड नहीं किया ताकि नोट को न बढ़ाया जाए। उसी कारण से, मैंने वास्तविक आईपी क्लाइंट और rpaf_module मॉड्यूल के हस्तांतरण पर ध्यान केंद्रित किया। यदि आवश्यक हो - बाहर रखना।