गेटवेवर OpenVPN DNS: dnsmasq आणि फायरवॉलची व्याप्ती

टनेलच्या पत्त्यावर dnsmasq चालवा, फक्त क्लायंट पूलमधून DNS ला परवानगी द्या, रिझॉल्व्हर पुश करा आणि नंतर थेट क्वेरी तसेच अॅपचा स्वतःचा शोध तपासा।

टनेलवरील क्लायंट गेटवेपर्यंत पोहोचतात आणि गेटवे अंतर्गत रिझॉल्व्हरपर्यंत पोहोचतो, म्हणून DNS ने काम करायला हवे। पण ते काम करत नाही, कारण ही दोन वेगळी परवानगी आहेत आणि काम करणारी DNS सेवा ही तिसरी गोष्ट आहे। ऐकणारा अशा पत्त्यावर असला पाहिजे जिथपर्यंत क्लायंट पोहोचतात, फायरवॉलने त्या पत्त्यावरील क्वेरीला परवानगी दिली पाहिजे आणि क्लायंटला तो वापरण्यास सांगितले पाहिजे। टनेल दोन्ही दिशांनी उघडल्यास पहिल्या दोन गोष्टी अपघाताने सुटतात आणि तिसरी अपूर्ण राहते।

ऐकणारा दोन दिशा असलेली स्थानिक सेवा आहे

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

क्लायंटने कळवलेला टाइमआउट आणि गेटवेवर दिसणारा टाइमआउट एकच बिघाड नाही।

टनेलचा पत्ता बांधा, प्रत्येक पत्ता नाही

या कामासाठीच्या समर्पित dnsmasq प्रतिला स्पष्ट ऐकण्याचा पत्ता, सुरुवातीनंतर टनेल दिसणे सहन करणारी बांधणी पद्धत आणि एक स्पष्ट अपस्ट्रीम लागतो। ही मी वापरतो ती सर्वात लहान आवृत्ती आहे:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic वैयक्तिक पत्ते बांधते आणि tun0 नंतर दिसल्यास सांभाळते, जे VPN सेवा पुन्हा सुरू होणाऱ्या होस्टवर महत्त्वाचे आहे। loopback ची यादी केल्यास सार्वजनिक ऐकणारा न जोडता स्थानिक साधने चालू राहतात। no-resolv डेमनला होस्टच्या रिझॉल्व्हर संरचनेतून अपस्ट्रीम वारसाहक्काने घेण्यापासून थांबवते आणि no-hosts या प्रतीला गेटवेची hosts फाइल प्रकाशित करण्यापासून प्रतिबंधित करते। या पर्यायांपैकी कोणताही कोणालाही सेवेची क्वेरी करण्याची परवानगी देत नाही।

दुसरा डेमन सुरू करण्यापूर्वी पोर्ट 53 वर आधीपासून असलेला ऐकणारा आहे का ते तपासा आणि चुकीच्या डिरेक्टरीतल्या भटकत्या फाइलऐवजी वितरणाच्या संरचना-मालकाचा वापर करा।

DNS इनपुटला परवानगी द्या, टनेल ट्रान्झिटला नाही

हे काम करणारे फायरवॉल नियम स्थानिक-इनपुट नियम आहेत, टनेल इंटरफेस, क्लायंट पूल, गेटवे पत्ता आणि पोर्ट 53 पर्यंत मर्यादित। प्रत्येक प्रोटोकॉलसाठी एक, दोन नियम पुरतात:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP सोबत TCP वरही चालतो, म्हणून फक्त UDP चा नियम मोठ्या उत्तरांना अधूनमधून वाटणाऱ्या पद्धतीने अपयशी होऊ देतो। हे ufw route परवानग्या नाहीत आणि त्यांनी tun0 वर व्यापक परवानगी बनू नये। क्रम सामग्रीइतकाच महत्त्वाचा आहे: tun0 वरून सर्व इनपुट टाकून देणारा आधीचा नियम तरीही जिंकतो आणि अंतिम ड्रॉपखाली परवानगी जोडल्याने काहीही तयार होत नाही।

गेटवेचा DNS आता रचनेचा भाग असल्यास ती आधीची धोरणे जाणीवपूर्वक तपासा आणि का ते नोंदवा।

अपस्ट्रीम अर्धा भाग वेगळा मार्ग आहे

क्वेऱ्या गेटवेमधून त्याच्या स्वतःच्या पत्त्यावरून अपस्ट्रीम रिझॉल्व्हरकडे निघतात, म्हणून गेटवेचा रूट आणि त्या रिझॉल्व्हरकडील आउटपुट धोरणाने ही देवाणघेवाण परवानगी दिली पाहिजे। हा क्लायंटना ऐकणाऱ्यापर्यंत पोहोचू देणाऱ्या नियमापेक्षा वेगळा नियम आहे आणि तो वेगळ्या लक्षणाने अपयशी होतो।

उत्तरे काम करण्यासाठी अमर्यादित टनेल आउटपुट जोडू नका; मागोवा घेतलेल्या उत्तरांना त्याची गरज नाही।

पर्याय पुश करा, नंतर हस्तांतरण तपासा

सर्व्हर पुश केलेल्या पर्यायाने क्लायंटना रिझॉल्व्हरची घोषणा करू शकतो। हा पर्याय आहे, ऑपरेटिंग सिस्टमने पाळावाच असा आदेश नाही:

push "dhcp-option DNS 10.90.0.1"

कमांड-लाइन Linux क्लायंटला त्याच्या कनेक्शन मॅनेजरचे रिझॉल्व्हर एकत्रीकरण लागू शकते आणि व्यवस्थापित उपकरणाला अद्ययावत व्यवस्थापन प्रोफाइल लागू शकते। कनेक्ट केल्यानंतर क्लायंटवरील सक्रिय रिझॉल्व्हरची पुष्टी करा, पुश लागू झाला असे गृहीत धरण्याऐवजी। दोन यंत्रणा एकाच वेळी DNS सेट करण्याचा प्रयत्न करतात तेव्हा लुकलुकणारे रिझोल्यूशन असे दिसणारी शर्यत उद्भवते।

लक्ष्य क्लायंटच्या रिझॉल्व्हर संरचनेचा एकच मालक असणे आहे आणि पुश सहसा तो मालक तेव्हाच असतो जेव्हा क्लायंट प्लॅटफॉर्म सहमत असतो।

तुम्ही प्रत्यक्षात काय बांधले ते तपासा

एक खाजगी पूर्ण पात्र नाव आणि एक परवानगी असलेले बाह्य नाव थेट टनेल पत्त्याविरुद्ध, UDP आणि TCP दोन्हीवर क्वेरी करा। नंतर अॅपच्या नेहमीच्या शोधमार्गाने पुनरावृत्ती करा।

थेट क्वेऱ्या चालत असतील आणि अॅप अजूनही अपयशी होत असेल, तर बिघाड सर्व्हरवर नाही, हस्तांतरणात आहे:

  • क्लायंटने पुश केलेला पर्याय कधीच लागू केला नाही।
  • नंतर दुसरा रिझॉल्व्हर सेट झाला आणि शर्यत जिंकली।
  • अॅप त्याची स्वतःची रिझॉल्व्हर लायब्ररी किंवा कॅशे केलेले उत्तर वापरते।

मंजूर VPN मार्गाबाहेरील स्रोत ऐकणाऱ्याचा वापर अजिबात करू शकत नाही याची पुष्टी करून समारोप करा। यशस्वी रिझोल्यूशनने परत दिलेल्या पत्त्याला अधिकृतता देत नाही, म्हणून हे दोन प्रश्न वेगळे ठेवा।

संबंधित लेख