UDP VPN पोर्ट स्कॅनवर शांत? असे का होते
WireGuard आणि कठोर OpenVPN प्रमाणीकरणात अयशस्वी डेटाग्राम उत्तर न देता टाकून देतात। स्कॅनरकडून मिळणारे शांतपण हे अपेक्षित वर्तन आहे, बंद पोर्ट नाही।
तुम्ही VPN पोर्ट स्कॅन करता, उत्तर मिळत नाही आणि सेवा बंद आहे किंवा फायरवॉल बंद आहे असा निष्कर्ष काढता। WireGuard मध्ये आणि स्वतःचे प्रमाणीकरण घेऊन जाणाऱ्या OpenVPN नियंत्रण चॅनेलमध्ये तो निष्कर्ष लागू होत नाही। वैध प्रमाणीकरण सामग्रीशिवाय डेटाग्राम उत्तराशिवाय टाकून दिला जातो, म्हणून बाहेरून निरोगी सेवा अशीच शांत दिसते। बोगदा चुकण्यापूर्वीच तपासणी चुकीची आहे।
शांतपण हाच प्रोटोकॉल आहे, दोष नाही
UDP मध्ये कनेक्शन स्थापना नसते, म्हणून स्कॅनरला उघडा पोर्ट आणि फिल्टर केलेला पोर्ट वेगळा करता यावा म्हणून SYN नाही आणि कोणतीही पोच नाही। तपासणी एक स्वतंत्र डेटाग्राम म्हणून येते आणि सेवा ती अपेक्षित प्रोटोकॉलशी जुळते का ते तपासते। जुळत नसेल तर पॅकेट टाकून दिले जाते, आणि टाकून देणे हे दस्तऐवजी वर्तन आहे, बिघाड नाही।
WireGuard आपल्या हँडशेक संदेशांची क्रिप्टोग्राफिक पद्धतीने पडताळणी करतो आणि अयशस्वी होणारे सर्व दुर्लक्षित करतो। OpenVPN tls-auth किंवा tls-crypt सह आपल्या नियंत्रण चॅनेलसाठी तेच करतो। दोन्ही प्रकरणांत कोणताही अनियंत्रित पेलोड वापरकर्त्याकडे जाणाऱ्या टप्प्यापर्यंत कधीही पोहोचत नाही, म्हणून उत्तर देण्यासाठी काहीही नाही आणि परत करण्यासाठी त्रुटीही नाही।
TCP असते तर बंद पोर्टवरून तुम्हाला रीसेट मिळाला असता। UDP तुम्हाला अस्पष्टतेत ठेवते, जी स्कॅनर अंदाज लावण्याऐवजी उघडा किंवा फिल्टर केलेला असे छापून सोडवतात।
स्कॅनर काय निष्कर्ष काढू शकतो आणि काय नाही
स्कॅनचा निकाल तो जेवढा पेलोड पाठवतो तेवढाच माहितीपूर्ण असतो। संभाव्य निरीक्षणे प्रत्येकजण प्रत्यक्षात कशाला आधार देतो यानुसार लावा:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
यादीतील एकमेव सकारात्मक चाचणी म्हणून तिसरी ओळ वाचा। त्यासाठी खरे प्रोफाइल, खरी की आणि योग्य एंडपॉइंट आवश्यक आहे, आणि सामान्य स्कॅनरकडे तेच नसते।
मार्गाच्या दोन्ही टोकांकडे पहा
तुम्ही व्यवस्थापित करता त्या सर्व्हरसाठी, कोणताही निष्कर्ष काढण्यापूर्वी इंटरफेसवर कॅप्चर करा, नंतर सेवेला तिने काय पाहिले ते विचारा। दोन्ही आदेशांना गेटवेवर root आवश्यक आहे:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showइंटरफेसवर कोणतेही पॅकेट दिसत नसेल, तर सेवेने काहीही पाहण्यापूर्वीच मार्गाने ते टाकून दिले आहे, आणि पुढील थांबा राउटिंग आणि फिल्टरिंग आहे। पॅकेट येतात पण कोणताही हँडशेक पूर्ण होत नसेल, तर सेवा पोहोचण्यायोग्य आहे आणि फरक की, एंडपॉइंट कॉन्फिगरेशन किंवा प्रोटोकॉल आवृत्तीत आहे। तीच तुलना स्कॅनरला देता आली नाही त्या प्रश्नाचे उत्तर देते। खरा क्लायंट जोडण्याचा प्रयत्न करत असताना ती चालवा, स्कॅनर स्वतःची पुनरावृत्ती करत असताना नाही।
चाचणी बदला, संरक्षण नाही
मोहक छोटा मार्ग म्हणजे निदानाला उत्तर मिळावे म्हणून नियंत्रण चॅनेलचे संरक्षण बंद करणे। ते खऱ्या सुरक्षा गुणधर्माची देवाणघेवाण अधिक सुंदर स्कॅन निकालासाठी करते, आणि ती चुकीची दिशा आहे। त्याऐवजी मंजूर नेटवर्कमधून वैध प्रोफाइल वापरा आणि तुलना पुन्हा करता यावी म्हणून एंडपॉइंट व वेळ नोंदवा।
सर्वात उपयुक्त चाचणी विभेदक आहे: तेच प्रोफाइल काम करणाऱ्या मार्गावर आणि जो मार्ग काम करत नाही त्यावर। जर काम करणारा मार्ग हँडशेक निर्माण करतो आणि अयशस्वी मार्ग इंटरफेसवर काहीही निर्माण करत नाही, तर तुम्ही काहीही कमकुवत न करता तुटीचे स्थान शोधले आहे।
म्हणून उत्तर न मिळालेला UDP पॅकेट सर्व्हर ऑफलाइन असल्याचेही सिद्ध करत नाही आणि तो सुरक्षित असल्याचेही नाही। ते फक्त हे सिद्ध करते की ही तपासणी, या मार्गावर, या क्षणी, स्वीकारली गेली नाही।