फॉरवर्ड केलेला VPN पोर्ट: अभ्यागत आणि पुरवठादार काय पाहू शकतात

पोर्ट फॉरवर्ड केल्याने अनोळखी लोकांना पुरवठादाराच्या सार्वजनिक पत्त्यामार्फत सेवेपर्यंत पोहोचण्याचा मार्ग मिळतो. हा एकच बदल उघडपणा आणि ओळखण्यायोग्यतेवर एकाच वेळी परिणाम करतो, आणि दोन्हीपैकी कोणीही सेवा चालवणाऱ्याचे नाव प्रकाशित करत नाही. दोन्ही वेगळे ठेवल्यास 'फॉरवर्डिंग' अॅनोनिमिटी मानणे आणि ते ओळख मानणे या विरुद्ध चुका टळतात. तीन प्रश्न त्यांना स्पष्टपणे वेगळे करतात, आणि उत्तरे वेगवेगळ्या पुराव्यांतून येतात.

तीन वस्तू, तीन वेगळे प्रश्न

सार्वजनिक पत्ता त्याच्या मागे उत्तर देणाऱ्या अॅप्लिकेशनपासून वेगळा ठेवा, आणि दोन्हीही हे काम चालवणाऱ्या व्यक्ती किंवा संस्थेपासून वेगळे ठेवा. प्रत्येकाचे स्वतःचे प्रेक्षक आणि स्वतःचे पुरावे आहेत. हे मिसळल्यास व्यवस्थित वाटणारे आणि चुकीचे निष्कर्ष मिळतात.

त्या क्रमाने त्यांचा विचार करा. पहिला पोहोचक्षमतेचा प्रश्न आहे, दुसरा अॅप्लिकेशनच्या ओळखीचा प्रश्न आहे, आणि तिसरा श्रेयनिर्देशाचा प्रश्न आहे ज्यावर पहिले दोन केवळ अंशतः प्रकाश टाकतात. पोर्ट फॉरवर्डिंग खाजगी आहे का असे कोणी विचारले तर, त्या तीनपैकी कोणता अर्थ आहे हे विचारा. उत्तरे खरोखर वेगळी असतात, आणि धोरण पृष्ठ सहसा त्यातील एकाचीच चर्चा करते.

अभ्यागत एंडपॉइंट्समध्ये काय जोडू शकतो

अभ्यागत एंडपॉइंटशी जोडतो आणि अॅप्लिकेशन कायदेशीरपणे जे सादर करते ते पाहतो: 'होस्टनेम', प्रमाणपत्राचे नाव, लॉगिन पृष्ठ, प्रकाशित सामग्री. हे तपशील सेवेचा नेहमीचा प्रवेश पत्ता बोगद्यामागे लपलेला असतानाही सेवेची ओळख करून देतात. एकाच नावाची साइट सादर करणारे दोन एंडपॉइंट निरीक्षकांना ते जोडण्याचा आधार देतात. या वर्तनात कोणतीही गळती नाही, कारण अॅप्लिकेशन दिसण्यासाठीच बनवले आहे.

दोन एंडपॉइंट्समध्ये प्रमाणपत्रे, रीडायरेक्ट आणि पृष्ठ सामग्री जुळणे हे ते एकाच सेवेचे आहेत याचा मजबूत संकेत आहे. दुसरा कोणताही नोंद दोन्हींना जोडेपर्यंत ते सेवेबद्दलचे विधान राहते, माणसाबद्दल नाही.

IETF च्या गोपनीयता मार्गदर्शक तत्त्वे कायमस्वरूपी ओळखकर्ते कालांतराने परस्परसंवाद सहसंबंधित करणे कसे शक्य करतात हे वर्णन करतात. सहसंबंध म्हणजे श्रेयनिर्देश नाही, कारण एक सेवा अनेक लोक चालवू शकतात आणि पत्ता असंबंधित ग्राहकांमध्ये बदलू शकतो. हाच फरक सहसंबंधाच्या निष्कर्षाला आरोपात बदलण्यापासून रोखतो.

फॉरवर्डिंग पुरवठादाराला काय माहीत असावे

येणारे कनेक्शन पोहोचवण्यासाठी पुरवठादाराच्या प्रणालीने सार्वजनिक प्रवेश बिंदू आणि अंतर्गत गंतव्यस्थान यांच्यातील सक्रिय संबंध ठेवावा लागतो. ही कार्यात्मक वस्तुस्थिती अभ्यागत जे पाहतो त्यापेक्षा वेगळी आहे, आणि पुरवठादार जे ठेवण्याचे ठरवतो त्यापेक्षाही वेगळी आहे. धोरण पृष्ठ वाचताना दोन्ही प्रश्न वेगळे ठेवा, कारण एक अपरिहार्य आहे आणि दुसरा निर्णय. ब्राउझिंग इतिहास ठेवला जात नाही असे विधान मॅपिंग इतिहासाबद्दल काहीही सांगत नाही.

ऐतिहासिक मॅपिंग, खाते जोडण्या किंवा कनेक्शन नोंदी टिकतात का हा पुरवठादाराच्या प्रत्यक्ष धोरणाचा आणि अंमलबजावणीचा प्रश्न आहे. फॉरवर्डिंग प्रत्येक श्रेणी नोंदवली जाते हे सिद्ध करत नाही. मॅपिंग मागे घेतल्यानंतर कोणती क्षेत्रे टिकतात आणि किती काळ, हे विशेष विचारा.

येणारी पोहोचक्षमता क्लायंटच्या जाणाऱ्या राउटिंगपासून, DNS पासून आणि अपयशाच्या वर्तनापासूनही वेगळी आहे. मॅपिंग जोडल्याने क्लायंटचा उर्वरित रहदारी कसा बाहेर पडतो हे वर्णन होत नाही.

मॅपिंग किती काळ टिकते यामुळे उघडपणा बदलतो

मॅपिंग एका सत्रासाठी, आरक्षणासाठी, किंवा ते बदलणाऱ्या पुरवठादाराच्या धोरणानुसार टिकू शकते. कायमचे वाटप किंवा सतत फिरणे यापैकी काहीही गृहीत धरू नये; उत्पादनाचे दस्तऐवजीकृत वर्तन वाचा आणि तुम्ही निरीक्षण करता ते नोंदवा. आठवड्याच्या अंतराने केलेली दोन निरीक्षणे उत्पादन पृष्ठावरील कोणत्याही विपणन वाक्यापेक्षा 'फिरण्याबद्दल' अधिक सांगतात. निरीक्षण केलेला मध्यांतर तुमच्या टिपांमध्ये एंडपॉइंटच्या शेजारी लिहा, कारण मध्यांतर उघडपणाचा भाग आहे.

आयुष्य बदलते की कोणता सहसंबंध शक्य आहे. स्थिर एंडपॉइंट एका सेवेच्या दीर्घकालीन मागोव्याला आमंत्रण देतो, तर फिरणारा प्रत्येक निरीक्षण मागील निरीक्षणाशी जोडणे कठीण करतो. दोन्हीपैकी कोणताही गुणधर्म पुरवठादाराच्या नोंदींबद्दल हमी नाही, आणि कोणताही सेवा स्वतः काय प्रकाशित करते हे ठरवण्याचा पर्याय नाही.

हेतुपूर्वक प्रकाशित करा, मग दोन्ही दरवाजे बंद करा

पुरवठादार तुम्हाला आवश्यक प्रोटोकॉलला परवानगी देतो, लक्ष्य श्रोता तुमच्या मनातील आहे, आणि होस्ट व अॅप्लिकेशन नियंत्रणे अजूनही प्रवेश मर्यादित करतात याची खात्री करा. प्रकाशित करण्यापूर्वी सेवा अनोळखी व्यक्तीला काय सादर करेल ते पहा. हे दोन आदेश अभ्यागताला मिळणारे प्रमाणपत्र आणि शीर्षलेख दाखवतात.

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

काहीतरी प्रकाशित करणे म्हणजे त्याची प्रशासन पृष्ठे उघड करणे किंवा अॅप्लिकेशनचे लॉगिन सोडणे याला न्याय देते असे नाही, आणि भाषांतर अशा सेवेला TLS देत नाही ज्याला ते कधीच नव्हते. रहदारी कशीही आली तरी कूटबद्ध प्रोटोकॉल आणि त्याच्या सर्व्हर-ओळख तपासण्या जागेवर ठेवा. नंतर प्रतिसाद शीर्षलेख तपासा, कारण 'बॅनर' किंवा दोषमार्जन पृष्ठ अनोळखी व्यक्तीला सेवेच्या हेतूपेक्षा अधिक सांगू शकते. दोन आदेश जे परत देतात ते निरीक्षकाला मिळणारे तेच दृश्य आहे.

सेवा बंद करणे म्हणजे दोन बंदी, एक नाही: मालकामार्फत मॅपिंग मागे घ्या, नंतर श्रोता आणि अधिकार स्वतंत्र बाबी म्हणून हाताळा. बुकमार्क केलेला एंडपॉइंट उत्तर देणे थांबवतो तेव्हा तो कोणतेही क्रेडेन्शियल रद्द करत नाही, आणि आधीच पोहोचवलेली माहिती परत आणत नाही.