LAN सर्व्हरवरील VPN क्लायंट: उत्तरे चुकीच्या मार्गाने का जातात

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

उत्तर हा नवीन पॅकेट आहे, मार्गाची उलटी चाल नाही

विनंती ज्या मार्गाने गेली त्याच मार्गाने उत्तर परत येते ही कल्पना सोडणे उपयुक्त आहे। राउटिंग प्रत्येक पॅकेटसाठी, प्रत्येक दिशेसाठी, पाठवणाऱ्या होस्टवर ठरवले जाते। बोगद्यातून 10.64.0.23 वरून आलेल्या विनंतीमुळे परतीचा मार्ग तयार होत नाही; होस्टने उत्तर दिल्यावर ते उत्तर नवीन पॅकेट म्हणून तक्त्याशी जुळवले जाते आणि जो मार्ग जिंकतो त्यातून बाहेर पडते।

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

बाकी वाचताना दोन उपजाळे लक्षात ठेवा। एक म्हणजे दूरचे क्लायंट ज्या VPN पत्ता पूलमधून येतात, या उदाहरणात 10.64.0.0/24। दुसरे म्हणजे काम सुरू ठेवायचे LAN, 172.16.24.0/24, त्याचा राउटर 172.16.24.1 वर। दोष असा की त्यांच्यातील रहदारी डीफॉल्ट रूट ठरवतो।

कॅप्चर आणि लुकअपने ते सिद्ध करा

काहीही बदलण्यापूर्वी उत्तर कोणते उपकरण वापरेल ते निश्चित करा। लुकअप कॅप्चरपेक्षा वेगवान आहे आणि पॅकेट तयार होताना कर्नल ज्या प्रश्नाचे उत्तर देईल त्याच प्रश्नाचे उत्तर देते।

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

उत्तर दोन भागांत वाचा। जर ते dev tun0 सांगते, तर होस्ट उत्तराचे एन्कॅप्स्युलेशन करून ते प्रदात्याकडे देईल, आणि LAN क्लायंटला ते कधीच दिसणार नाही। जर ते dev eth0 सांगते पण क्लायंटला तरीही वेळ संपते, तर मार्ग आधीच बरोबर आहे आणि पॅकेट नंतर टाकून दिले जाते, ही दुसरी समस्या आणि दुसरा उपाय आहे।

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

बोगद्याला मागे टाकणारा सर्वात अरुंद मार्ग बसवा

प्रीफिक्सची लांबी ठरवते, मेट्रिक नाही, म्हणून LAN राउटरमार्फत क्लायंट पूलचा मार्ग VPN क्लायंट बसवतो त्या कोणत्याही डीफॉल्टवर जिंकतो। मेट्रिकच्या शस्त्रक्रियेची गरज नाही, आणि डीफॉल्ट क्लायंटने ठेवलेल्या जागीच राहू शकतो।

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

दुसऱ्या add ऐवजी replace वापरा, कारण पुन्हा जोडणारा क्लायंट आधीच स्वतःची नोंद बसवलेला असेल आणि दुसरे add परवानगीची समस्या वाटणाऱ्या आधीच अस्तित्वात असलेल्या मार्गाच्या त्रुटीने अयशस्वी होते। Windows होस्टवर समतुल्य route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p आहे, जिथे -p रीबूटमध्येही नोंद ठेवते, कारण बोगदा पुन्हा वर आल्यावर क्लायंट तक्ता पुन्हा बनवू शकतो। आधुनिक Windows होस्टवर समर्थित समतुल्य New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore आहे, आणि जुना route आदेश लीगसी स्वरूपात ठेवला आहे।

एक तपशील ठरवतो की हे बरोबर आहे की फक्त विश्वासार्ह: पुढील हॉप हा तोच राउटर असला पाहिजे जो क्लायंटकडे परत जाणाऱ्या मार्गाचा खरा मालक आहे। ज्या पत्त्यावर स्वतः बोगद्यातून पोहोचता अशा पत्त्याकडे मार्ग वळवल्यास स्वच्छ बिघाडाऐवजी अधूनमधून होणारी हानी म्हणून दिसणारा लूप तयार होतो। ओळ निश्चित करण्यापूर्वी पुढील हॉप LAN उपजाळ्यावर आहे याची खात्री करा।

पुन्हा जोडल्यानंतरही उत्तर टिकवा

हाताने जोडलेला मार्ग जास्तीत जास्त पुढील पुनर्जोडणीपर्यंत टिकतो। क्लायंट पूल गतिशील असल्यास तो सर्व्हर कॉन्फिगरेशनमध्ये पिन करा, जेणेकरून तुम्ही राउट केलेला प्रीफिक्स क्लायंटना मिळणाराच प्रीफिक्स राहील; अन्यथा नोंद रिकाम्या श्रेणीकडे निर्देश करते आणि लक्षणे आठवड्यांनंतर स्पष्ट कारणाशिवाय परत येतात। मार्ग क्लायंटच्याच up-स्क्रिप्टमध्ये लिहिणे हा दुसरा विश्वासार्ह पर्याय आहे, कारण क्लायंटने तक्ता पुन्हा लिहिल्यानंतर ती चालते।

स्थितीपूर्ण फायरवॉल बरोबर मार्गालाही पराभूत करू शकतो। कॅप्चर आता दाखवत असेल की उत्तर eth0 मधून बाहेर पडते आणि क्लायंटला तरीही वेळ संपत असेल, तर होस्ट पाठवण्यापूर्वी पॅकेट टाकून देतो का ते तपासा। कडक रिव्हर्स-पाथ फिल्टरिंग आणि net.ipv4.conf.all.rp_filter 1 वर ठेवल्यास, ज्या इंटरफेसवरून आले त्याच इंटरफेसवरून परत राउट होणार नाही अशा स्रोताची पॅकेट्स टाकून दिली जातात, आणि हीच ती असममित स्थिती आहे जी तुम्ही आत्ताच तयार केली आणि नंतर दुरुस्त केली, आणि conntrack स्थिती फॉरवर्ड केलेल्या पोर्टसाठी तीच गोष्ट सांगते।

शेवटची तपासणी लोक वगळतात ती ही: बोगदा खाली जाऊन पुन्हा वर आल्यानंतर लुकअपची पुनरावृत्ती करा। चार मूल्ये तुम्ही लिहून ठेवलेल्याशी जुळली पाहिजेत: गंतव्य, पुढील हॉप, उपकरण आणि निवडलेला स्रोत। त्यांपैकी काही सरकले असेल, तर क्लायंटने तक्ता पुन्हा लिहिला आहे आणि उपाय त्याच्या हुक्समध्ये आहे, shell इतिहासात नाही।