एका क्लाउड सेवेसाठी नेटिव्ह TLS, SSH फॉरवर्ड किंवा VPN

प्रश्न क्वचितच असा असतो की दोन क्लाउड मशीनमध्ये काहीतरी एन्क्रिप्ट करावे का; प्रश्न असा असतो की तुम्ही कोणता इंटरफेस एन्क्रिप्ट करत आहात आणि कोण कुणाची ओळख तपासतो। मी हे संवाद नेटवर्क आकृतीऐवजी सेवेपासून सुरू करतो, कारण सेवेला आधीच माहीत आहे की तिला काय हवे आहे। तीन सीमा बहुतेक प्रकरणे झाकतात: ॲपचे स्वतःचे TLS, SSH द्वारे फॉरवर्ड केलेला एक TCP पोर्ट, आणि प्रत्येक सहभागीला पत्ता देणारे राउटेड ओव्हरले। त्या ताकदीने क्रमवारीत नाहीत, तर समस्येचा किती भाग झाकतात यावर क्रमवारीत आहेत।

नेटवर्कऐवजी सेवेपासून सुरुवात करा

प्रक्रियेतून बाहेर जा। ती कोणत्या प्रोटोकॉलवर बोलते, क्लायंट कोणते नाव सत्यापित करेल आणि कोणाला अजिबात कनेक्शन उघडण्याची परवानगी आहे? ही तीन उत्तरे कोणत्याही तुलना तक्त्यापेक्षा वेगाने पर्याय काढून टाकतात, आणि सेवेचे स्वतःचे कॉन्फिगरेशन सामान्यतः काही मिनिटांत त्यांना उत्तर देते।

8443 पोर्टवर आधीच HTTPS देणारे छोटे अंतर्गत API घ्या, api.internal.example साठी प्रमाणपत्रासह। होस्टवर ss -ltnp ते कशाला बांधले आहे ते दाखवते, आणि openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example प्रमाणपत्र क्लायंट प्रत्यक्षात वापरणार असलेल्या नावासाठी वैध आहे का ते दाखवते। दोन्ही निरोगी असल्यास, सेवा स्वतःचा प्रवाह संरक्षित करू शकते आणि फक्त पोहोच शिल्लक राहते। हे नेटवर्क बांधण्यापेक्षा खूपच लहान समस्या आहे।

पायरी 1: सेवा स्वतःचे संरक्षण करते का?

हे जुळल्यास घ्यायचा पर्याय आहे, आणि संघ गृहीत धरतात त्यापेक्षा जास्त वेळा जुळतो। सेवेचे एन्क्रिप्शन क्लायंट आणि सर्व्हरमधील संपूर्ण मार्ग झाकते, मधल्या प्रत्येक हॉपसह, जे मध्यभागी असलेल्या कोणत्याही बोगद्याने सुधारत नाही। क्लायंटच्या डीफॉल्ट स्टोअरमध्ये योगायोगाने असलेल्या गोष्टींवर अवलंबून राहण्याऐवजी अपेक्षित नाव आणि विश्वास स्पष्टपणे सेट करा।

एन्क्रिप्शन आणि पोहोच वेगळी नियंत्रणे राहतात, आणि ती एकत्र करणे हेच हा पर्याय चुकतो ते ठिकाण। अमर्यादित सार्वजनिक श्रोत्यावरील TLS सेवा अजूनही कोणाकडूनही कनेक्शनचे प्रयत्न स्वीकारते, म्हणून पेलोड संरक्षित असण्याच्या वस्तुस्थितीपासून स्वतंत्रपणे श्रोता आणि नेटवर्क नियम निश्चित केले पाहिजेत। नंतर अवलंबित्वे तपासा, कारण TLS वरचे API शोध एंडपॉइंट, अॅडमिन पोर्ट किंवा शेजारच्या बल्क ट्रान्सफर चॅनेलबद्दल काहीही सांगत नाही। त्यातील प्रत्येकाला स्वतःचे उत्तर हवे, आणि एक असुरक्षित भाऊ संपूर्ण सीमा कल्पित करण्यासाठी पुरतो।

पायरी 2: एक TCP पोर्ट हीच संपूर्ण गरज आहे का?

जेव्हा गरज खरोखर एक TCP पोर्ट असते, तेव्हा फॉरवर्ड ही काम करणारी सर्वात लहान गोष्ट असते। SSH स्थानिक फॉरवर्ड तो पोर्ट आधीच अस्तित्वात असलेल्या प्रमाणित कनेक्शनमधून नेतो।

आकार ssh -N -L 8443:127.0.0.1:8443 [email protected] आहे, आणि महत्त्वाचा तपशील लक्ष्य पत्ता आहे: 127.0.0.1 दूरच्या बाजूला सोडवला जातो, म्हणून सेवेचे कनेक्शन तुमच्या लॅपटॉपऐवजी बास्टियनमधून उघडते। स्थानिक श्रोत्याला -L 127.0.0.1:8443:... असे अरुंद बांधा जेणेकरून तुम्ही अपघाताने सेवा तुमच्या स्वतःच्या स्थानिक नेटवर्कवर प्रकाशित करू नये। सर्व्हरच्या बाजूला, क्लायंटच्या चांगल्या वर्तनावर विश्वास ठेवण्याऐवजी खाते काय फॉरवर्ड करू शकते ते मर्यादित करा। PermitOpen, AllowTcpForwarding local आणि GatewayPorts no डीफॉल्ट ही तीन सेटिंग्ज आहेत जी सामान्य रिलेला विशिष्ट चॅनेलमध्ये बदलतात।

करार दोन्ही दिशांनी अरुंद आहे। SSH स्वतःच्या चॅनेलचे संरक्षण करते, आणि बास्टियनपासून दुसऱ्या ॲपपर्यंतच्या पुढील हॉपला स्वतःचे संरक्षण हवे। फक्त बास्टियनच्या loopback वर ऐकणाऱ्या सेवेचे प्रदर्शन दुसऱ्या नेटवर्कमधून पोहोचणाऱ्या सेवेपेक्षा पूर्णपणे वेगळे आहे, आणि फॉरवर्ड ते बदलत नाही। बोगद्याला त्यांचा पर्याय मानण्याऐवजी ॲपचे प्रमाणीकरण आणि TLS तपासण्या ठेवा।

एका मालकाच्या एका कनेक्शनसाठी हे चांगले काम करते। मोठ्या प्रमाणात हे एक प्रणाली बनते: स्थानिक पोर्ट संघर्ष, देखरेख, की रोटेशन आणि रीबूटनंतर फॉरवर्ड कोण पुन्हा सुरू करतो हा प्रश्न।

पायरी 3: राउटिंग हीच खरी गरज आहे का?

ती यादी सर्वात लहान पर्यायाची प्रामाणिक किंमत आहे, आणि म्हणूनच संघ शेवटी विसरलेल्या काही बॅकग्राउंड कमांड्सना व्यवस्थापित गोष्टीने बदलतात। बदल आपोआप VPN नाही। जर गरज अजूनही एक TCP पोर्ट असेल, तर दस्तऐवजीकृत मालकासह देखरेखीखालील फॉरवर्ड ओव्हरलेपेक्षा स्वस्त चालतो आणि तुम्ही पाहू शकता अशा पद्धतीने अयशस्वी होतो। लालित्य मोजण्यापूर्वी कार्यात्मक मालकी मोजा।

राउटिंग हीच गरज असते तेव्हा राउटिंग योग्य उत्तर बनते। सामान्य IP कनेक्टिव्हिटी हवी असलेली अनेक ॲप्स, TCP फॉरवर्ड नेऊ शकत नाहीत असे प्रोटोकॉल, किंवा होस्टमध्ये फिरणाऱ्या सेवा — सर्व एकाच दिशेने दाखवतात।

ओव्हरले सहभागींना पत्ता आणि मार्ग देते, आणि मग खरे काम सुरू होते: न-ओव्हरलॅपिंग श्रेणी, मार्ग मालकी, DNS, नोंदणी, रद्द करणे आणि साथीदार गायब झाल्यावर काय होते। यातील काहीही पत्त्यासोबत येत नाही। ओव्हरलेमध्ये स्वीकारलेला साथीदारही गंतव्यस्थानावरील प्रत्येक क्रियेसाठी स्वयंचलितपणे अधिकृत नसतो, म्हणून सेवा-स्तरीय प्रमाणीकरण राहते।

नंतर तुमच्याकडे काय आहे

तुम्ही सोडलेल्या नोंदीत दोन गोष्टी येतात। पहिली म्हणजे क्लायंटने सत्यापित करायची ओळख, कारण काहीतरी काम करण्यासाठी नाव-तपासणी सैल होताच या प्रत्येक सीमा शांतपणे बिघडतात। दुसरी म्हणजे काढण्याची पायरी: प्रवेश संपल्यावर कोणती की, कोणता नियम किंवा कोणता मार्ग गायब होतो, आणि ते कोण करते।

हा प्रवास जिथे सुरू झाला तिथेच, सेवेजवळ संपतो। प्रत्यक्ष रहदारी झाकणारी आणि तुम्ही सत्यापित करू इच्छित असलेल्या साथीदारांना सत्यापित करणारी सीमा निवडा, नंतर प्रवेश कसा अद्ययावत, देखरेख आणि काढला जातो ते लिहा। OpenSSH संदर्भ अरुंद कराराचे वचन देण्यापूर्वी फॉरवर्डिंग पर्यायांची पुष्टी करण्याचे ठिकाण आहे। जर तुम्ही काढण्याची पायरी एका वाक्यात वर्णन करू शकत नाही, तर सीमा समस्येपेक्षा मोठी आहे।