OpenVPN नियंत्रण पॅकेटचा मागोवा: TLS आधी tls-auth

tls-auth अयशस्वीता सहसा हँडशेक समस्या म्हणून नोंदवली जाते, पण ती कधीच तशी नव्हती। कोणत्याही TLS प्रक्रियेपूर्वी नियंत्रण पॅकेटवर HMAC तपासले जाते, म्हणून न जुळणारी किल्ली किंवा दिशा अशी अयशस्वीता निर्माण करते जी प्रमाणपत्राच्या समस्येसारखी दिसते आणि दोन स्तर आधी ठरवली जाते। लिफाफ्याकडे स्वतंत्र वस्तू म्हणून पाहिल्यास निदान लहान होते: क्षेत्रे वाचा, तपासणी लवकर चालते याची खात्री करा आणि नंतर दोन्ही टोकांनी मान्य करावयाच्या तीन गोष्टींची तुलना करा।

लिफाफा ज्या क्रमाने बांधला जातो त्या क्रमाने वाचा

नियंत्रण पॅकेटमध्ये सत्र ओळखकर्ता, ऐच्छिक tls-auth HMAC, पुनरावृत्ती व पोच माहिती आणि विश्वासार्ह संदेश ओळखकर्ता असतो, आणि त्यानंतर संदेश प्रकाराचा पेलोड येतो। संदेश हँडशेक संदेश असेल तर पेलोड TLS सिफरटेक्स्ट असतो। संबंध एवढाच: TLS सामग्री लिफाफा आधीच संरक्षित करत असलेल्या संदेशाच्या आतून प्रवास करते। पहा OpenVPN नेटवर्क प्रोटोकॉल संदर्भ जो नियंत्रण वाहिनीची क्षेत्रे त्याच क्रमाने सूचीबद्ध करतो।

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

हा गट संकल्पनात्मक ठेवा। हे बाइट-क्रम आकृती नाही, आणि टॅग मोजण्यासाठी पुरेसे नाही, कारण HMAC मध्ये जाणारी क्षेत्रे अंमलबजावणी, आवृत्ती आणि मोडवर अवलंबून असतात।

तपासणी हँडशेकपूर्वी चालते हे दाखवा

सामायिक किल्ली असलेला प्राप्तकर्ता HMAC तपासू शकतो आणि बनावट पॅकेट लगेच टाकून देऊ शकतो, हँडशेक स्थिती राखून ठेवल्याशिवाय किंवा सार्वजनिक किल्लीचे काम न करता। संरक्षण सुरुवातीच्या हँडशेक पॅकेटनाही व्यापते, आणि म्हणूनच चुकीची किल्ली उशिरा येणारी प्रमाणीकरण त्रुटी म्हणून नाही तर अयशस्वी जोडणी म्हणून दिसते।

डीमनची शब्दाडंबरता वाढवा आणि tun उपकरणाऐवजी नियंत्रण वाहिनी पहा:

openvpn --config /etc/openvpn/server.conf --verb 6

तुम्ही शोधत असलेली गोष्ट म्हणजे पॅकेट पातळीवर नोंदवली जाणारी नियंत्रण-वाहिनी HMAC पडताळणी अयशस्वीता, कोणत्याही TLS इशाऱ्यापूर्वी। लॉगमध्ये TLS इशारा म्हणजे लिफाफा स्वीकारला गेला आणि अयशस्वीता आत सरकली, ही वेगळ्या उपायाची वेगळी चौकशी आहे।

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

दोन्ही टोकांवर किल्ली, दिशा आणि digest जुळवा

तीन मूल्ये जुळली पाहिजेत आणि त्यांपैकी फक्त एक फाइल आहे। स्थिर किल्लीची सामग्री दोन्ही टोकांवर समान असली पाहिजे, दिशा विरुद्ध असली पाहिजे, आणि HMAC साठी वापरला जाणारा digest जुळला पाहिजे। किल्ली सामग्रीला हात लावण्यापूर्वी संरचना तपासा, कारण एक उलटी दिशा खराब फाइलपेक्षा जास्त अयशस्वीता स्पष्ट करते:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

सामायिक गुप्तता संपादकाऐवजी साधनाने तयार करा आणि परवानग्या कडक ठेवा:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

tls-auth ची tls-crypt शी गल्लत करू नका। दोन्ही नियंत्रण वाहिनीचे संरक्षण करतात, पण tls-crypt ती एन्क्रिप्टही करते आणि निरीक्षकांपासून हँडशेक लपवते, आणि दिशा विभागणीची जागा स्वतःच्या किल्ली हाताळणीने घेते। एक वापरणारे प्रोफाइल दुसऱ्यासाठी संरचित केलेल्या सोबत्याशी काम करणार नाही, आणि कोणतेही digest ट्यूनिंग ती तफावत भरत नाही।

टॅग फक्त खऱ्या स्वरूपातून पुन्हा तयार करा

बाइट-अचूक पुनरुत्पादन हे VPN चालवण्यापेक्षा वेगळे काम आहे, आणि ते फक्त खऱ्या इनपुटसह चालते: पॅकेट बनवणारी अंमलबजावणी व आवृत्ती, निवडलेला digest, दिशा, आणि सत्र ओळखकर्ता व पोच अरेसह प्रत्यक्ष बाइट। क्षेत्र सूचीचे पाठ्य स्वरूप ते बाइट नाहीत।

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

हा सराव उत्पादन प्रोफाइलपासून दूर ठेवा। टॅग पुन्हा तयार करण्यात तैनातीने संरक्षण सक्षम करावे का हे सांगणारे काहीही नाही।

संरक्षण न काढता विसंगती मागे घ्या

मोहात पडून केला जाणारा प्रयोग म्हणजे tls-auth काढून टाकणे, जोडणी यशस्वी होताना पाहणे आणि किल्ली चुकीची होती असा निष्कर्ष काढणे। त्या उत्तरामुळे संरक्षण जाते आणि तीनपैकी कोणते मूल्य जुळले नाही हे काहीच शिकवत नाही। त्याऐवजी सर्व्हरकडून मंजूर जुळणारी संरचना घ्या आणि तिच्याशी तुलना करा।

बदल उलटता येईल अशा पद्धतीने तयार करा। पूर्वीची सर्व्हर संरचना आणि किल्ली फाइल ठेवा, दुरुस्त केलेली जोडी लागू करा, क्लायंट हँडशेक पूर्ण करतो याची खात्री करा, आणि त्यानंतरच बॅकअप काढा। बदलानंतर क्लायंट अयशस्वी झाले तर खंड काळात तिसरा प्रकार रचण्याऐवजी पूर्वीच्या फाइल्स पुनर्संचयित करा। पुनर्संचयन ही एकच आदेश असावी जी तुम्हाला सुरुवातीपूर्वीच माहीत असेल।

शेवटी, उत्तीर्ण तपासणीचा अर्थ लक्षात ठेवा। ती सिद्ध करते की सोबत्याकडे सामायिक किल्ली आहे, त्याचे प्रमाणपत्र किंवा खाते अधिकृत आहे हे नाही, आणि ती वाटाघाटी झालेल्या डेटा-वाहिनी सिफरबद्दल काहीही सांगत नाही. अधिकृती आणि डेटा संरक्षण नंतर प्रस्थापित होते, म्हणून स्वच्छ लिफाफा तपासणी ही सुरुवातीचा बिंदू आहे, निकाल नाही।