उत्तर न मिळणारा बहिर्गामी ESP म्हणजे VPN मृत आहे असे नाही
ESP प्रत्येक असोसिएशनसाठी एकच दिशा संरक्षित करते आणि काहीही मान्य करत नाही. सर्व्हरला प्रतिसाद देत नाही असे म्हणण्यापूर्वी आंतरिक संभाषण आणि इनबाउंड SA जुळवून पहा.
तुम्ही IPsec होस्टवर ट्रॅफिक कॅप्चर केले, ESP पॅकेट बाहेर जाताना पाहिले, परत काहीही आले नाही असे पाहिले आणि दूरची बाजू खराब आहे असा निष्कर्ष काढला. कॅप्चर त्या निष्कर्षाला पुष्टी देत नाही. ESP संभाषणाची एक दिशा संरक्षित करते आणि IP स्तरावर काहीही मान्य करत नाही, त्यामुळे परत येणारा ESP नसणे म्हणजे अॅपकडे सांगण्यासारखे काही नव्हते इतकेच सहज असू शकते, जितके ते टनेल मृत असल्याचे असू शकते. कोणत्याही बाजूला दोष देण्यापूर्वी आंतरिक देवघेव आणि प्राप्तीच्या बाजूची स्थिती वाचा.
गैरसमज: प्रत्येक संरक्षित पॅकेटला उत्तर मिळते
ESP हा विनंती-प्रतिसाद प्रोटोकॉल नाही. धोरण जे निवडते ते तो एन्क्रिप्ट आणि प्रमाणित करतो, आणि प्राप्तकर्ता ते आंतरिक पॅकेट स्वतःचे पॅकेट निर्माण न करता पडताळून, उलगडून आणि पोहोचवतो. गंतव्य ज्याकडे दुर्लक्ष करते अशी UDP चौकशी, किंवा इनबाउंड धोरण जे टाकून देते असे ICMP प्रतिध्वनी, दोन्ही दिशांना शांतता हाच योग्य परिणाम म्हणून निर्माण करतात. त्या शांततेला वाहतूक बिघाड मानणे तुम्हाला कधीच नव्हता असा नेटवर्क दोष शोधायला पाठवते.
एकदिशीय कॅप्चर प्रत्यक्षात हेच सिद्ध करते की त्या निरीक्षण बिंदूवर प्रेषकाच्या स्टॅकने काहीतरी एन्क्रिप्ट केले. आले का याबद्दल काहीही नाही आणि उत्तर देण्याच्या हेतूबद्दलही काहीही नाही. उपयुक्त प्रश्न „उत्तर का नाही“ हा नसून „आंतरिक संभाषणाने काय निर्माण केले पाहिजे होते“ हा आहे.
दोन SA, दोन SPI, एक संभाषण
IPsec सुरक्षा असोसिएशन एकदिशीय असतात, त्यामुळे सामान्य संरक्षित देवघेव स्वतंत्र ओळखण्या आणि स्वतंत्र स्थितीसह एक इनबाउंड असोसिएशन आणि एक आउटबाउंड असोसिएशन चालवते. बाहेर जाणाऱ्या पॅकेटच्या SPI साठी परतीचा रहदारी शोधणे म्हणजे वर्गवारीची चूक आहे, कारण कोणतेही उत्तर समोरच्या बाजूच्या स्वतःच्या आउटबाउंड SA अंतर्गत स्वतःच्या SPI सह प्रवास करते. त्याऐवजी रहदारी निवडक आणि समोरच्या बाजूच्या पत्त्यांनी जोडी जुळवा.
की पुनर्निर्मिती काही क्षणांसाठी चित्र गुंतागुंतीचे करते, कारण जुनी आणि बदली स्थिती एकमेकांवर येऊ शकते. लक्षण की बदलाच्या सुमारास सुरू झाले असेल, तर फक्त कनेक्शनचे नाव नाही तर असोसिएशन ओळखण्या आणि वेळमुद्रा एकत्र गोळा करा.
काहीही उत्तर देण्यापूर्वी प्राप्तकर्त्याने काय करावे
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
प्रत्येक ओळ स्वतंत्रपणे अपयशी होते आणि प्रत्येक बिघाडाला वेगळा मालक असतो, म्हणून एक कॅप्चर त्यांना वेगळे करू शकत नाही. इनबाउंड काउंटर हाच आलेपणाचा एकमेव थेट पुरावा आहे, कारण प्रमाणीकरण किंवा पुनरावृत्ती तपासणीत नापास होणारे पॅकेट कोणत्याही प्रतिसादाशिवाय टाकून दिले जाते. त्यामुळे ज्याचा इनबाउंड काउंटर हलला नाही तो समोरचा भाग आपल्या धोरणाबद्दल तुम्हाला काहीच माहिती देत नाही.
पोहोचवणे हे उलगडण्यापासून वेगळे पाऊल आहे. स्थिती वैध असू शकते आणि तरीही पॅकेट नंतर इनबाउंड धोरणाने किंवा आंतरिक गंतव्य समाविष्ट नसलेल्या मार्गाने टाकून दिले जाऊ शकते, त्यामुळे स्वच्छ काउंटर म्हणजे पॅकेट तुम्हाला हव्या तिथे गेले असे गृहीत धरण्याऐवजी लक्ष्य होस्टने स्पष्ट मजकूर पाहिला का ते तपासा.
मूळ ESP हा UDP नाही
मूळ ESP हा IP प्रोटोकॉल 50 आहे, जो TCP किंवा UDP नाही आणि त्याला पोर्टच नाहीत. त्यामुळे UDP 500 वर IKE परवानगी देणारा फायरवॉल नियम डेटा मार्गाबद्दल काहीच सांगत नाही, आणि पोर्टभोवती लिहिलेला फिल्टर टनेलला वाटाघाटी करू देऊन नंतर आत नेलेले सर्व टाकून देऊ शकतो. डेटा मार्ग तुम्ही प्रत्यक्षात पाहिलेल्या मोडमध्ये स्वतंत्रपणे तपासा.
NAT मागे चित्र बदलते: संरक्षित पेलोड UDP च्या आत प्रवास करते, सामान्यतः पोर्ट 4500 वर, जसे RFC 3948 परिभाषित करते. कोणताही नियम लिहिण्यापूर्वी सक्रिय मोड नोंदवा, कारण मार्गावरील उपकरण मूळ ESP आणि UDP-मध्ये गुंडाळलेल्या ESP ला पूर्णपणे वेगळ्या पद्धतीने वागवू शकते, आणि काही मधले उपकरण एकाला परवानगी देऊन दुसरे टाकून देतात.
या घटनेशी संबंधित काउंटर वाचा
strongSwan होस्टवर swanctl --list-sas दोन्ही दिशांना प्रत्येक असोसिएशनचे पॅकेट आणि बाइट काउंटर नोंदवते, जे „कधीच आले नाही“ आणि „आले पण उत्तर दिले नाही“ वेगळे करण्यास पुरेसे आहे. Linux वर /proc/net/xfrm_stat गहाळ स्थिती, गहाळ धोरण आणि प्रोटोकॉल त्रुटींसारखे एकत्रित अपयश मोजते. ती एकूण आकडेवारी बूटपासून जमा होते आणि एका नेटवर्क नावक्षेत्राशी संबंधित असते, त्यामुळे मोठा आकडा म्हणजे आरोप नाही.
योग्य नावक्षेत्रात घटनेच्या कालावधीभोवती दोन वाचन घ्या आणि फरक तुलना करा, अन्यथा गेल्या आठवड्यातील त्रुटी आज दुपारच्या तिकिटावर लावाल. नावक्षेत्र आणि दोन्ही वेळमुद्रा तिकिटात नोंदवा, जेणेकरून पुढील वाचक एकूण आकड्यावर विश्वास ठेवण्याऐवजी तुलना पुन्हा करू शकेल.
टप्प्याला नाव द्या, संशयिताला नाही
उपयुक्त निष्कर्ष सांगतो की पॅकेट कुठे थांबले: कधीच मिळाले नाही, मिळाले आणि टाकून दिले गेले, पोहोचवले पण उत्तर नाही, किंवा उत्तर दिले आणि परतीच्या वाटेवर हरवले. यापैकी प्रत्येक वेगळ्या मालकाकडे आणि वेगळ्या पुढील आदेशाकडे निर्देश करतो. „VPN सर्व्हरकडून प्रतिसाद नाही“ हे चार वेगळ्या बिघाडांना कॅप्चरने कधीच न्याय्य न ठरवलेल्या एका वाक्यात आणते.
कॅप्चर अरुंद ठेवा आणि कर्नेलची कच्ची स्थिती तिकिटांमध्ये ठेवू नका, कारण त्यात होस्ट सोडू नये अशी की सामग्री असू शकते. काउंटरमधील फरक आणि वेळमुद्रा हे पुढील व्यक्तीला देण्यासारखे भाग आहेत.