अपने प्रॉक्सी IP के लिए सर्वर तैयार करने का व्यावहारिक क्रम: पहले SSH एक्सेस जांचें, फिर पोर्ट बदलकर key authentication अपनाएँ, बुनियादी सुरक्षा सख्ती करें, proxy service इंस्टॉल करके पोर्ट खोलें, और अंत में client से कनेक्ट करके सत्यापन करें।
क्लाउड सर्वर खरीदकर उसे proxy के रूप में इस्तेमाल करते समय समस्या अक्सर मूल connectivity में नहीं होती। ज़्यादातर परेशानी server-side तैयारी के क्रम से आती है। क्रम सही हो तो client आम तौर पर पहली कोशिश में कनेक्ट हो जाता है; क्रम गड़बड़ हो तो बार-बार terminal पर लौटकर configuration बदलनी पड़ती है।
यहाँ केवल server side की बात है: पहली login से लेकर access को सख्त करने, proxy service चलाने, port खोलने, client को जोड़ने और कनेक्शन न बनने पर layer-by-layer कारण खोजने तक।
पहली login पर सबसे पहले access की पुष्टि करें
Instance बन जाने के बाद पहले provider console में उपलब्ध web terminal से login करें और शुरुआत से ही local tool पर निर्भर न रहें। इस चरण का उद्देश्य सिर्फ यह देखना है कि मशीन चल रही है और network reachable है।
अंदर आने के बाद sudo -i चलाकर Enter दबाएँ और root पर जाएँ। Prompt जब $ से # हो जाए, तो privilege escalation सफल है। आगे के काम इसी identity से करें।
साथ ही चार चीज़ें नोट कर लें: public IP, login username (Linux में default root), password और SSH port (default 22)। Client कनेक्शन के लिए यही चार values चाहिए; इनमें से एक भी missing हो तो connection नहीं बनेगा।
Default port बदलें, फिर key-based login पर जाएँ
Port 22 हर दिन अनगिनत बार scan होता है और automated credential attempts सामान्य हैं। Port बदलना server को अपने-आप अधिक मजबूत नहीं बनाता, लेकिन ज़्यादातर automated noise को फ़िल्टर कर देता है।
बदलाव /etc/ssh/sshd_config में किया जाता है। इसे vi से खोलें, edit mode में जाने के लिए i दबाएँ, PermitRootLogin और PasswordAuthentication वाली lines को yes करें, फिर Esc दबाकर :wq लिखें ताकि save करके बाहर निकलें। अगर provider key-based login support करता है, तो बेहतर तरीका है कि local public key को server के authorized_keys में जोड़ें और फिर PasswordAuthentication को no कर दें, ताकि केवल key authentication रहे।
Configuration बदलने के तुरंत बाद मौजूदा session बंद न करें। पहले दूसरी terminal window खोलें, नए port और नए method से एक बार login करें, access की पुष्टि करें और उसके बाद ही पुरानी window बंद करें। वरना configuration में गलती होने पर आप खुद को बाहर lock कर सकते हैं और recovery के लिए provider console पर लौटना पड़ेगा।
SSH port, Port वाली line में सेट होता है। बदलाव के बाद configuration लागू करने के लिए SSH service restart करें। Debian और Ubuntu systems पर /etc/init.d/ssh restart चलाया जा सकता है।
पहले दिन ही बुनियादी सुरक्षा सख्ती पूरी करें
Port बदलने और keys इस्तेमाल करने के अलावा दो छोटे काम पहले दिन ही कर लेना अच्छा है। पहला, passwd root से root के लिए पर्याप्त लंबा random password सेट करें और आसानी से अनुमान लगने वाला combination न रखें। दूसरा, जिन services और ports की ज़रूरत नहीं है उन्हें बंद करें। मशीन पर जितनी कम चीज़ें चलेंगी, attack surface उतना छोटा होगा; system firewall में केवल सचमुच ज़रूरी ports ही allow करें।
अगर यह server लंबे समय तक केवल कुछ निश्चित source locations से इस्तेमाल होगा, तो security group में source addresses उन्हीं तक सीमित करें। यह पूरे Internet के लिए access खोलने से कहीं सुरक्षित है।
Proxy service इंस्टॉल करें और authentication सेट करें
Server-side initialization पूरी हो जाने के बाद proxy पर आएँ।
एक विकल्प सीधे SSH tunnel का उपयोग करना है। Server पर अतिरिक्त कुछ install करने की ज़रूरत नहीं; client forwarding के लिए system की built-in SSH service और वही server credentials इस्तेमाल करता है। यह आसान है, लेकिन performance औसत रहती है और बहुत अधिक concurrent connections पर दबाव बढ़ता है, इसलिए temporary use या कम accounts के लिए ठीक है।
दूसरा विकल्प server पर dedicated proxy service install करना है। आम तौर पर एक installation command पर्याप्त होती है, फिर authentication method और listening port आप खुद configure करते हैं। इसे boot पर auto-start करने के लिए सेट करें; वरना server restart होते ही proxy भी बंद हो जाएगा।
Authentication को बढ़ती सुरक्षा के तीन स्तरों में समझा जा सकता है: username और password सबसे आसान हैं, लेकिन leak होने पर proxy लगभग हाथ से निकल जाता है; password के साथ source IP allowlist रोज़मर्रा के उपयोग के लिए अक्सर पर्याप्त है; key या certificate authentication सबसे मजबूत है, हालाँकि configuration थोड़ी जटिल है और long-term accounts के लिए यह मेहनत उचित है।
Port को दो अलग जगहों पर खोलें
यही वह जगह है जहाँ सबसे अधिक रुकावट आती है। Proxy service का listening port system firewall और provider के security group, दोनों में अलग-अलग allow करना पड़ता है। दोनों controls स्वतंत्र हैं; केवल एक जगह port खोलने से connection नहीं बनेगा।
एक और आसानी से छूटने वाली setting service का listening address है। कुछ services default रूप से केवल 127.0.0.1 पर bind होती हैं। अगर server पर local test चलता है लेकिन बाहर से connection नहीं बनता, तो अक्सर यही कारण होता है। Listening address को server के private address या 0.0.0.0 पर बदलें।
Local client से कनेक्ट करें
Environment management tool में नया environment बनाएँ और वास्तविक proxy type चुनें। अगर SSH tunnel इस्तेमाल कर रहे हैं, तो address में server का public IP, port में SSH port, और username/password में server credentials भरें। फिर connection test चलाएँ।
Test pass होना केवल यह बताता है कि network path काम कर रहा है। Environment खोलकर तीन बातें और जांचें: exit IP server का public IP है या नहीं; DNS भी proxy से जा रहा है या नहीं, क्योंकि local DNS resolution ऐसी region information दिखा सकता है जो exit IP से मेल नहीं खाती; और time zone तथा language exit region के अनुरूप हैं या नहीं। तीनों checks पास होने के बाद ही environment को ready मानें।
Accounts बढ़ने पर environment और exit का mapping स्थिर रखें, ताकि कई accounts एक ही environment साझा न करें। PurpleMark जैसे tools हर account को अलग exit से bind कर सकते हैं, जो manual mapping table संभालने से अधिक विश्वसनीय है।
कनेक्शन न बने तो बाहर से अंदर की ओर जांचें
सबसे बाहरी layer से शुरू करें: क्या security group में अनुमति है? क्या system firewall में अनुमति है? दोनों की पुष्टि करने के बाद ही आगे जाएँ।
फिर service खुद देखें: process अभी चल रहा है या नहीं, खासकर server restart होने के बाद? Listening address केवल local interface पर bind तो नहीं है?
उसके बाद authentication layer जांचें: username या password गलत तो नहीं? Key file की permissions ज़रूरत से ज़्यादा खुली तो नहीं? Permissions गलत होने पर SSHD सीधे key reject कर देता है। सबसे अंत में client side देखें: public IP भरा है या गलती से private IP? यह गलती बहुत आम है।
इस क्रम से चलने पर आम तौर पर दो या तीन rounds में पता चल जाता है कि समस्या किस layer में है, बजाय service को बार-बार reinstall करने के।
समापन
Server side की तैयारी में आधे घंटे से भी कम समय लगता है, लेकिन यही तय करती है कि अगले कई महीनों तक मशीन कितनी आसानी से चलेगी। Access सख्त रखें, ports सही तरह से खोलें और authentication साफ़ तरीके से configure करें; उसके बाद केवल routine maintenance रह जाता है।
