MULTI: ग्राहकबाट खराब स्रोत ठेगाना: यो कसको ठेगाना थियो?
भित्री स्रोतले त्यसलाई पठाउने ग्राहकसँग मेल खाँदैन। यसलाई टनेल बाँडफाँट, ग्राहकको पछाडिको LAN, वा दोहोरो पहिचानसँग मिलाउनुहोस्।
सर्भर लगले MULTI: bad source address from client छाप्छ, प्याकेट फ्याँक्छ, र सत्र जोडिएको रहन्छ। यो संयोजनले सन्देशलाई प्रमाणीकरण असफलता भनेर पढ्नेहरूलाई अलमल्याउँछ। त्यस्तो होइन: ग्राहक प्रमाणीकरण भइसकेको छ, र आएको प्याकेटले भित्री स्रोत ठेगाना बोकेको थियो जसलाई सर्भरले त्यो ग्राहकको प्रतिसँग जोड्न सकेन। जाँच डेलिभरी अघि हुन्छ, त्यसैले टनेल स्वस्थ देखिन्छ तर त्यसबाट केही उपयोगी जाँदैन।
डेलिभरी अघि सर्भरले के तुलना गर्छ
ग्राहकबाट आउने प्रत्येक प्याकेटका लागि, प्रयोगकर्ता स्पेसमा रहेको सर्भरले टनेलभित्रको स्रोत ठेगाना हेर्छ र आफ्नो आन्तरिक रुटिङ अवस्थालाई त्यो ठेगाना कुन ग्राहकको हो भनी सोध्छ। मालिक अर्को प्रति हो वा मालिक नै छैन भने प्याकेट हटाइन्छ र चेतावनी जारी हुन्छ।
टनेल इन्टरफेसबाट सामान्य डेलिभरी कहिल्यै हुँदैन।
यो क्रमले मानिसहरूलाई अलमल्याउने एक विवरण व्याख्या गर्छ: होस्ट फायरवालका काउन्टर सर्दैनन्, किनकि प्याकेट कहिल्यै फायरवालसम्म पुगेन। होस्टमा रिभर्स-पाथ फिल्टरिङ मिलाउँदा यहाँ केही फरक पर्दैन, किनकि अस्वीकृति डेमनको आफ्नै एसोसिएसन जाँचमा भएको थियो। सन्देशलाई स्वामित्वको बारेमा एक भनाइका रूपमा पढ्नुहोस्, त्यसपछि तीनमध्ये कुन अवस्थाले यो बनायो पत्ता लगाउनुहोस्।
नमिल्ने भित्री ठेगानाका तीन स्रोत
ग्राहकले आफूलाई नतोकिएको ठेगानाबाट, कसैले आफ्नो भनेर घोषणा नगरेको सञ्जालबाट, वा पहिले नै मालिक भएको पहिचानको प्रतिबाट पठाइरहेको हुन सक्छ। तीनैले एउटै लग लाइन बनाउँछन्। ती के बदल्नु पर्ने भन्नेमा फरक छन्। ठेगाना र हालको बाँडफाँट सूचीबाट सुरु गर्नुहोस्, र यी दुई तथ्यलाई केस छान्न दिनुहोस्।
ती फरक पार्न दुई तथ्य चाहिन्छ: लगमा अस्वीकृत ठेगाना, र सर्भरले हालको मान्ने बाँडफाँट। दोस्रो चलिरहेको प्रतिको स्थिति वा व्यवस्थापन दृश्यबाट उपलब्ध हुन्छ, र सल्लाह लिन योग्य एकमात्र अधिकार त्यही हो, किनकि कन्फिगरेसन फाइलले हालको अवस्था होइन, मनसाय अभिलेख गर्छ।
केही बदल्नु अघि दुवै अभिलेख गर्नुहोस्, त्यसपछि वर्गीकरण गर्नुहोस्। पछि खिचिएको स्क्रिनसट चेतावनी बनाउने अवस्थाको अभिलेख होइन। बाँडफाँट सत्रहरूबीच सर्ने हुनाले समय छाप पनि राख्नुहोस्।
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
ग्राहकको पछाडिको LAN र iroute
जब साइट ग्राहकले आफ्नै निजी सञ्जाल रुट गर्छ, त्यो सञ्जाल ग्राहकको हो भनेर घोषणा गर्नुपर्छ। iroute प्रविष्टि भएको ग्राहक-विशेष फाइलले त्यो गर्छ, र प्रविष्टिले ग्राहकले बोक्न पाउने प्रिफिक्सको नाम दिन्छ।
त्यही प्रिफिक्सलाई टनेलतिर देखाउने कर्नेल रुट छुट्टै आवश्यकता हो, र त्यो थप्दा डेमनको आन्तरिक स्वामित्वमा केही फरक पर्दैन।
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0प्रभावकारी पहिचान फाइल नामसँग मिल्छ भनी पुष्टि गर्नुहोस्, किनकि नमिल्दा फाइल कहिल्यै लोड हुँदैन र लक्षण हराएको प्रविष्टिसँग उस्तै हुन्छ। चेतावनी शान्त गर्न फराकिलो iroute नथप्नुहोस्, किनकि त्यसले अप्रत्याशित स्रोतलाई अधिकृत बनाउँछ र ग्राहकले किन पठायो भन्ने जवाफ दिँदैन। iroute, duplicate-cn र पहिचान म्यापिङलाई छुट्टाछुट्टै नियन्त्रणका रूपमा OpenVPN 2.6 पुस्तिकाले अभिलेख गर्छ।
दुई मेसिनमा एउटै पहिचान
दोस्रो ल्यापटपमा प्रतिलिपि गरिएको प्रोफाइलले एउटै प्रमाणपत्र र एउटै सामान्य नाम बोकेको हुन्छ। सर्भरको सेटिङअनुसार नयाँ जडानले पुरानोलाई प्रतिस्थापन गर्न सक्छ, र स्वामित्व राख्ने प्रतिले एसोसिएसन जाँच जित्छ।
यसले खराबीलाई रोकिएर देखाउँछ र दुवै उपकरण जागा भएको बेला मात्र देखा पर्छ।
दोहोरो सामान्य नामलाई अनुमति दिँदा दुवै जोडिन सक्छन्, तर तिनलाई स्वतन्त्र स्थिर ठेगाना वा स्वतन्त्र स्वामित्व दिँदैन। दुई उपकरण सँगै रहनुपर्ने भए, प्रत्येकको आफ्नै पहिचान र आफ्नै बाँडफाँट होस् भनेर तिनलाई छुट्टाछुट्टै दर्ता गर्नुहोस्। दोहोरो सेटिङलाई यो चेतावनीको उपचार मान्दा रहस्य यथावत् रहन्छ र अर्को थपिन्छ।
एसोसिएसन बदलिएको प्रमाणित गर्नुहोस्
सुधार कन्फिगरेसनको मालिकमार्फत लागू गर्नुहोस्, त्यसपछि नयाँ नीति लोड होस् भनेर प्रभावित ग्राहक पुनः जोड्नुहोस्।
त्यही प्रक्रिया फेरि गर्नुहोस् र तीन कुरा पुष्टि गर्नुहोस्: प्याकेटको भित्री स्रोत, सर्भरले जोड्ने ग्राहक प्रति, र त्यसपछिको गन्तव्यको व्यवहार।
चेतावनी रोकिए पनि अनुप्रयोग अझै असफल भइरहेको छ भने समस्या हराएको होइन, सरेको हो। फर्वार्डिङ, फायरवाल नियम र फर्कने मार्ग छुट्टाछुट्टै चरण हुन्, र एसोसिएसन जाँच पार गर्नु भनेको प्याकेटलाई टनेल छोड्न अनुमति दिइयो भन्ने मात्र हो।