L2TP/IPsec एका नेटवर्कवर जोडतो आणि दुसऱ्यावर वेळ संपतो

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

नेटवर्कची तुलना करण्यापूर्वी क्लायंट निश्चित करा

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

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

चार टप्पे, चार वेगळे त्रुटी संदेश

L2TP/IPsec कनेक्शन चार टप्प्यांतून जाते, आणि RFC 3193 ती व्यवस्था वर्णन करते जी पहिल्या दोनांना जोडते. IKE चर्चा ही अशी जागा आहे जिथे फिल्टर केलेला मार्ग शांत कालबाह्यता निर्माण करतो. IPsec प्रमाणीकरण ही अशी जागा आहे जिथे प्रमाणपत्र किंवा आधीच सामायिक केलेल्या कीमधील फरक त्याऐवजी स्पष्ट नकार निर्माण करतो. L2TP बोगद्याची स्थापना ही अशी जागा आहे जिथे आधीच स्थापित सुरक्षा संघटना तरीही कुठेही नेऊ शकत नाही, आणि PPP लॉगिन ही अशी जागा आहे जिथे चुकीचे क्रेडेन्शियल शेवटी दिसणारी अयशस्वीता निर्माण करते. ज्या टप्प्यावर थांबले त्याचा लॉग वाचा, शेवटच्या छापलेल्या ओळीचा नाही.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

strongSwan चा लॉग दाखवतो की IKE देवाणघेवाण एखाद्या प्रस्तावापर्यंत पोहोचली का आणि समकक्षाने अजिबात उत्तर दिले का, जे प्रवेशयोग्यता धोरणापासून वेगळे करते. xl2tpd चा लॉग जिथे IPsec संपतो तिथून पुढे चालतो, म्हणून त्या लॉगमध्ये काहीही नसलेली स्थापित सुरक्षा संघटना L2TP टप्प्याकडे निर्देश करते. मार्ग प्रश्न पुष्टी करतो की क्लायंट आपण विचारात घेतलेल्या सर्व्हर पत्त्याकडे पाठवत आहे, आणि हे मागील नेटवर्कवरून वारसाहक्काने मिळालेले जुने DNS उत्तर पकडते. एकत्रितपणे, तीन निर्गम लक्षणाऐवजी टप्प्याचे नाव सांगतात.

NAT ची खोली आणि सहाय्यकाचे वर्तन यांची तुलना करा

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

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

बाहेर जाणारा क्लायंट, आत येणारा सर्व्हर: दोन वेगळ्या समस्या

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

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