गेटवेमा 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 मार्गबाहिरको स्रोतले सुन्ने प्रयोग गर्नै नसक्ने पुष्टि गरेर टुङ्ग्याउनुहोस्। सफल रिजोल्युसनले फर्काएको ठेगानालाई अधिकार दिँदैन, त्यसैले यी दुई प्रश्न अलग राख्नुहोस्।

सम्बन्धित लेखहरू