AWS Client VPN एंडपॉइंट DNS: सोडवलेला IP पिन करणे का अयशस्वी होते
AWS Client VPN एंडपॉइंटचे नाव तुम्ही सोडवलेल्या पत्त्याने बदला आणि टनेल नंतर काम करणे थांबवेल. निर्यात केलेले नाव आणि त्याचा यादृच्छिक उपसर्ग ठेवा.
गेल्या आठवड्यात dig +short ने तुमच्या AWS Client VPN प्रोफाइलमधील एंडपॉइंट नावासाठी एक पत्ता दिला, आणि टनेल जोडले गेले. या आठवड्यात तोच प्रोफाइल तुमच्या लॅपटॉपवर 'Connecting' वर थांबले आहे, तर सहकाऱ्याची अस्पर्शित प्रत अजूनही काम करते. काहीही ब्लॉक झाले नाही आणि प्रमाणपत्र कालबाह्य झाले नाही. कोणीतरी एंडपॉइंट होस्टनाव त्या सोडवलेल्या पत्त्याने बदलले, आणि सेवा आता तिथे प्रतिसाद देत नाही. निर्यात केलेले नाव हा त्या बदलाला तग धरण्यासाठी बनवलेला भाग आहे.
तुमच्या प्रोफाइलमधील नाव हे विचारले जाणारे नाव नसू शकते
Client VPN मधून निर्यात केलेल्या प्रोफाइलमध्ये सहसा remote-random-hostname असते. तो पर्याय सुरू असताना क्लायंट एक वापर-एकदा लेबल तयार करतो, बिंदूने ते एंडपॉइंट नावाशी जोडतो आणि एकत्रित नाव सोडवतो. एंडपॉइंटच्या झोनमधील वाइल्डकार्ड रेकॉर्ड कोणत्याही लेबलला उत्तर देतो, म्हणूनच बनावट उपसर्गही सोडवला जातो आणि म्हणूनच क्वेरी हाताने पुन्हा तयार करण्याचा प्रयत्न केल्यास ही युक्ती अदृश्य राहते.
म्हणून जेव्हा तुम्ही एंडपॉइंट नाव टर्मिनलमध्ये पेस्ट करून उत्तर मिळवता, तेव्हा क्लायंट जोडणीच्या वेळी वापरतो त्यापेक्षा वेगळे नाव तुम्ही सोडवले आहे. हा फरक प्रोफाइलमध्ये दुरुस्त करायचा दोष नाही. लेबल जाणूनबुजून पुन्हा तयार होते: पर्याय कॅशेला जुने उत्तर ठेवू देत नाही, आणि तो कधीही तुमचे मशीन किंवा सत्र ओळखत नाही.
क्लायंट पर्याय पूर्णपणे दुर्लक्षित करतो अशी सुसंगतता-स्थिती मला आली आहे. AWS उपाय नोंदवतो: खरे एंडपॉइंट नाव ठेवा आणि पुढे यादृच्छिक स्ट्रिंग व बिंदू जोडा, त्याला पेस्ट करायचे मूल्य नाही तर नामकरण नमुना माना. जुन्या क्लायंटवर ते लागू करणे योग्य आहे; उपसर्ग असलेली स्ट्रिंग एंडपॉइंट म्हणून हार्डकोड करणे नाही.
साठवलेले उत्तर बरोबर का राहू शकत नाही
Client VPN एंडपॉइंट पत्ते AWS व्यवस्थापित करते आणि ते काळानुसार बदलतात, असे सर्वोत्तम पद्धतींचे दस्तऐवज स्पष्ट सांगते. पकडलेले उत्तर हे एका सोडवणुकीचे स्नॅपशॉट आहे. ते हार्डकोड करणारे प्रोफाइल सेवा हलताच सेवानिवृत्त होस्टकडे लक्ष्य ठेवणारे प्रोफाइल बनते, आणि अयशस्वीता क्वचितच DNS सारखी दिसते: तुम्हाला कनेक्शन टाइमआउट किंवा थांबलेला हँडशेक मिळतो, म्हणून लोक राउटिंग आणि प्रमाणपत्रांच्या मागे धावतात.
/etc/hosts मधील तेच उत्तर तीच मुदत अतिरिक्त समस्येसह वारसा म्हणून घेते. hosts नोंद रीबूट, पुनर्निर्यात आणि 'क्लायंट पुन्हा इन्स्टॉल करा' दुरुस्त्या टिकून राहते, म्हणून पत्ता हलताच अयशस्वीता परत येते. एक नोंद आठवड्यांपर्यंत निरुपद्रवी पडलेली आणि नंतर ती वाहणारे प्रत्येक मशीन बंद पाडलेले, तर नवीन इन्स्टॉल सामान्यपणे जोडले जात होते, असे मी पाहिले आहे. त्याच खात्यात एक गट अयशस्वी आणि दुसरा ठीक असणारे हे विभाजन हा तुम्हाला मिळणारा सर्वात स्वस्त सुगावा आहे.
यादृच्छिकतेची व्याप्ती योग्यरित्या ठरवा. ती प्रत्येक कनेक्शन प्रयत्नाला होते. प्रस्थापित टनेल त्याचे एंडपॉइंट पुन्हा सोडवत नाही, सत्राच्या मध्ये सर्व्हर बदलत नाही, आणि वैयक्तिक अनुप्रयोग विनंत्या प्रत्येकी नवीन VPN होस्ट निवडत नाहीत. फक्त पुढील प्रयत्न पुन्हा सोडवतो, म्हणून दुपारभर चालणारे सत्र उद्याच्या सकाळबद्दल काहीही सांगत नाही.
टनेल उभे राहिल्यावर सेवा काय तपासते
Client VPN ची मागणी आहे की तुम्ही जोडलेले आहात तो पत्ता एंडपॉइंटच्या DNS नावासाठी सोडवलेल्या पत्त्याशी जुळावा. ही एकच अट असंबद्ध वाटणाऱ्या अनेक अयशस्वीता स्पष्ट करते: दुसरीकडे निर्देश करणारा सानुकूल DNS रेकॉर्ड, खऱ्या एंडपॉइंट पत्त्याकडे पाठवणारा सानुकूल फ्रंटएंड, आणि कच्च्या पत्त्यावर पुन्हा लिहिलेले प्रोफाइल. AWS सानुकूल-रेकॉर्ड-अधिक-फॉरवर्डिंग रचना अलीकडील AWS क्लायंटसह अयशस्वीता म्हणून नोंदवते. तपासणी अरुंद आहे; प्रत्येक उपनाव बंदी आहे असा निर्णय नाही.
हे VPN प्रोटोकॉलबद्दलचे सामान्य नियमही नाही. संख्यात्मक remote सामान्य OpenVPN उपयोजनात पूर्णपणे वैध आहे, आणि अनेक तसे चालतात. मर्यादा व्यवस्थापित रचनेतून येते, तिच्याखालील प्रोटोकॉलमधून नाही.
यामुळे प्रमाणपत्र पडताळणी सैल करणे ही चुकीची प्रतिक्रिया ठरते. पत्ता बदलल्यानंतर प्रोफाइल अयशस्वी झाल्यास सर्व्हर पडताळणी बंद करणे सोडवणूक किंवा पत्ता-जुळणीची अट दुरुस्त करण्याऐवजी त्रुटी हलवते, आणि कशावरही विश्वास ठेवणारा क्लायंट सोडते. निर्यात केलेला CA, सर्व्हर पडताळणी आणि परस्पर प्रमाणीकरण सेटिंग्ज आल्या तशाच ठेवा.
अनुमती सूची, इग्रेस आणि खाजगी DNS या तीन वेगळ्या समस्या आहेत
लॅपटॉप जोडण्यापूर्वी गंतव्यस्थानाला परवानगी देणारा फायरवॉल नियम बाह्य श्रोत्याशी संबंधित आहे. नेटवर्क मालकाला एंडपॉइंट नाव, ट्रान्सपोर्ट आणि कॉन्फिगर केलेला पोर्ट द्या, नंतर त्यांचे नियंत्रण सेवेच्या DNS वर्तनाचे अनुसरण करू शकते का विचारा. एक पकडलेला पत्ता धरून ठेवणारा नियम हा न लिहिलेल्या मुदतीचा स्नॅपशॉट आहे. नियंत्रण फक्त अपरिवर्तनीय गंतव्यस्थाने स्वीकारत असेल, तर गुपचूप उत्तर हार्डकोड करण्याऐवजी रोलआउटपूर्वी ती तफावत सोडवा.
टनेल उभ्यानंतरच्या विनंत्या करण्यासाठी स्थिर स्रोत पत्ता हवा असलेल्या भागीदाराची वेगळी आवश्यकता असते: इग्रेस. वेबसाइट काय पाहते हे अनुप्रयोग मार्ग आणि स्प्लिट-टनेल धोरणावर अवलंबून असते, क्लायंट ज्या पत्त्यावर जोडला त्यावर नाही. स्प्लिट-टनेल रहदारी AWS ला अजिबात स्पर्श न करू शकते.
टनेलमधील खाजगी DNS हा तिसरा स्तर आहे. क्लायंटना दिलेला रिझोल्व्हर जोडणीनंतर अंतर्गत नावांना उत्तर देतो; टनेल अस्तित्वात येण्यापूर्वी तो सार्वजनिक एंडपॉइंट सोडवू शकत नाही. एंडपॉइंट सोडवण्याची अयशस्वीता आणि अंतर्गत अनुप्रयोग सोडवण्याची अयशस्वीता वेगवेगळ्या टप्प्यांत होतात, आणि त्या मिसळल्यास तुम्ही चुकीच्या लॉगवर जाता.
पत्ता कुटुंब त्याच यादीत येते. IPv4 उत्तर IPv6 किंवा दुहेरी-स्टॅक एंडपॉइंटच्या परवानगी असलेल्या मार्गाबद्दल काहीही सांगत नाही, म्हणून एका कुटुंबात घेतलेला स्नॅपशॉट दुसऱ्यासाठी पुरावा नाही.
काहीही पिन न करता कनेक्शन तपासा
निर्यात झालेल्या तशाच प्रोफाइलपासून सुरुवात करा आणि ते प्रत्यक्षात काय मागते ते वाचा:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'नंतर तीन गोष्टींची तुलना करा: प्रोफाइलमधील एंडपॉइंट नाव, नवीन प्रयत्नासाठी क्लायंट जो पत्ता कळवतो, आणि नाव आता कशात सोडवले जाते. सोडवले जाणारे नाव फक्त रेकॉर्ड उत्तर देते हे सिद्ध करते; ट्रान्सपोर्ट आणि प्रमाणीकरण वेगळे आहेत, आणि एंडपॉइंटला ping ला उत्तर देण्याची गरज नाही. मधल्या बाबीसाठी क्लायंटचा स्वतःचा लॉग हाच एकमेव स्रोत आहे, म्हणून तो प्रयत्नाच्या वेळी पकडा, नंतर नाही.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
आज उत्तर देणारा पत्ता आजबद्दलचा पुरावा आहे; नाव हीच सेवा वैध ठेवते ती गोष्ट. निरीक्षण नोंदवा, एंडपॉइंटच्या मालकाला पाठवा, आणि प्रोफाइल नावाकडे निर्देश करत ठेवा.
सोडायच्या दोन सवयी: थांबलेल्या हँडशेकमधून जाण्यासाठी प्रमाणपत्र तपासण्या बंद करणे, आणि एक तरी टिकेल या आशेने एंडपॉइंट नावासमोर लेबलांची रास करणे. लेबल वाइल्डकार्ड रेकॉर्डमधून सोडवले जाते किंवा समस्या दुसरीकडे आहे. योग्यरित्या कॉन्फिगर केलेले प्रोफाइल तरीही अयशस्वी झाल्यास, लांब होस्टनाव नाही, तर अचूक क्वेरी आणि कनेक्शन घटना पाठवा.
बंद करण्यापूर्वी: प्रोफाइलमध्ये अजूनही निर्यात केलेले एंडपॉइंट नाव आहे, कोणतीही hosts फाइल पत्ता पिन करत नाही, क्लायंट लॉगमधील remote सध्याच्या सोडवणुकीशी जुळतो, आणि फायरवॉल नियम पत्त्याऐवजी एंडपॉइंटचे नाव सांगतो. पुढील व्यक्तीला सोपवायची स्थितीही हीच आहे.