राउटेड VPN कॅप्चर शाखेचा VLAN टॅग कधीच का दाखवत नाही

बोगदा इंटरफेसवर घेतलेले कॅप्चर शाखेचा VLAN ID कधीच दाखवणार नाहीत, आणि हे साधनाची कमतरता नसून रचनेचे वैशिष्ट्य आहे। राउटेड TUN बोगदा IP पॅकेट वाहून नेतो, त्यामुळे शाखा लिंकवर त्यांना वाहून नेणारे टॅग केलेले Ethernet फ्रेम त्यांना राउट केलेल्या राउटरवरच संपते। तुमच्या धोरणाचा प्रश्न विभागांबद्दल असल्यास, कॅप्चर सुरू होण्यापूर्वी त्या प्रश्नासाठी सेन्सरची स्थिती निवडली पाहिजे। तुम्ही अपेक्षित असलेल्या VLAN फील्डला तुम्ही समर्थन देऊ शकता अशा संदर्भाने बदलले पाहिजे।

बोगदा इंटरफेस प्रत्यक्षात काय वाहून नेतो ते पाहा

TUN होस्टला IP पॅकेट पोहोचवतो; TAP Ethernet फ्रेम पोहोचवतो। राउटेड रचना पहिले वापरते, याचा अर्थ डिक्रिप्शननंतर येणाऱ्या पॅकेटमध्ये लिंक-स्तर हेडर अजिबात नसतो, आणि त्यामुळे वाचण्यासाठी 802.1Q टॅगही नसतो। मार्गात काहीही काढले गेले नाही, कारण टॅग कधीच बोगद्यात शिरला नाही। आतील पॅकेट त्याच्या IP हेडरपासून सुरू होते, त्यामुळे VLAN-जागरूक नियमाला अपेक्षित असलेले प्रत्येक फील्ड फक्त अनुपस्थित आहे।

कॅप्चरबद्दल वाद घालण्यापूर्वी इंटरफेसचा प्रकार निश्चित करा, कारण त्याच तैनातीतील TAP उपकरण वेगळे वागेल आणि चुकीच्या निष्कर्षाकडे नेईल।

ip -d link show tun0
tcpdump -i tun0 -nn -e -c 20

पहिला आदेश उपकरणाचा प्रकार आणि त्याचे फ्लॅग छापतो। दुसरा पहिल्या वीस पॅकेट्सचे लिंक-स्तर हेडर छापतो, आणि TUN उपकरणावर आउटपुट Ethernet ब्लॉकशिवाय IP पासून सुरू होते, जे एका स्क्रीनवरील संपूर्ण स्पष्टीकरण आहे।

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

तीनपैकी एका ठिकाणी उभे राहा आणि ते काय पाहू शकते ते स्वीकारा

शाखेच्या Ethernet विभागात टॅग असतो, पण सेन्सर त्या विभागातील स्थानिक रहदारीच पाहतो। बाह्य VPN नेटवर्कवर रहदारी संरक्षित असते, त्यामुळे निरीक्षक फक्त टोके आणि प्रमाण शिकतो आणि आतील पॅकेटबद्दल काहीही नाही। डिक्रिप्शननंतर TUN मार्गावर आतील IP पॅकेट त्याच्या पत्ते आणि पोर्टसह उपलब्ध असते, आणि शाखेच्या फ्रेमशिवाय। त्यामुळे एकाच प्रवाहाचे ट्रंकवरील कॅप्चर आणि राउटेड कॅप्चर दोन वेगळ्या संभाषणांसारखे दिसतात।

ती तीन स्थाने तीन वेगळ्या प्रश्नांची उत्तरे देतात, आणि एक कॅप्चर एकाच वेळी तीनही असू शकत नाही।

tcpdump -i eth0 -nn -e 'vlan' -c 10
tcpdump -i tun0 -nn -c 10

जोडी चालवा आणि तुलना करा। पहिले शाखा लिंक होस्टकडे ट्रंक असलेल्या ठिकाणी टॅग केलेली फ्रेम आणि त्यांचे VLAN ID दाखवते; दुसरे राउटिंगनंतर तेच संभाषण साधे IP म्हणून दाखवते। पहिले काहीही परत देत नसेल, तर होस्ट पोर्ट प्रवेश पोर्ट आहे का ते तपासा, कारण तेव्हा स्विचने टॅग आधीच काढलेला असतो आणि होस्टवरील कोणतेही कॅप्चर तो कधीच दाखवणार नाही।

गहाळ टॅग तुम्ही समर्थन देऊ शकता अशा मॅपिंगने बदला

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

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

ip route get 10.20.30.40
ip -br addr show

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

निकालावर विश्वास ठेवण्यापूर्वी परतीचा मार्ग आणि पेलोड तपासा

फक्त एक दिशा पाहणारा तपासणी बिंदू अर्धे संभाषण चुकवेल, आणि VPN सहभागी झाल्यावर असममित राउटिंग सामान्य आहे। एकतर्फी कॅप्चर पूर्ण मानण्यापूर्वी उत्तरे त्याच सेन्सरमधून जातात याची खात्री करा।

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

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