टनेल उठ्ने बित्तिकै UFW ले VPN को DNS सर्भर छोडिदिन्छ
UFW को पूर्वनिर्धारित अस्वीकार नीतिले टनेलको इन्टरफेस पनि ढाक्छ। ट्राफिक दिशाअनुसार मिलाउनुहोस्, tun0 मा धकेलिएको resolver लाई अनुमति दिनुहोस्, त्यसपछि बाहिरी मार्ग खोल्नुहोस्।
VPN जोडिने बित्तिकै नामहरू समाधान हुन छोड्छन्, जबकि सार्वजनिक ठेगानामा ping अझै जवाफ दिन्छ र फायरवाल स्थितिमा गलत देखिने केही देखिँदैन। नीतिमा केही बदलिएको छैन; बदलिएको कुरा नयाँ इन्टरफेस आएको हो, र पूर्वनिर्धारित अस्वीकारले पहिलो प्याकेटदेखि नै त्यसलाई ढाक्छ। UFW दिशा र इन्टरफेसका आधारमा निर्णय गर्छ, त्यसैले वायरलेस लिंकका लागि लेखिएको नियम टनेलबाट बाहिर जाने ट्राफिकबारे केही भन्दैन। समाधान भनेको निश्चित क्रममा लगाइने केही साँघुरा नियमहरू हुन्।
लक्षण टनेल उठेपछि मात्र देखिन्छ
पूर्वनिर्धारित अस्वीकार नीतिले भनिएको कुरा ठ्याक्कै गर्छ: मिल्ने नियम नभएको सबै कुरा, अस्तित्वमा रहेका हरेक इन्टरफेसमा अस्वीकार गरिन्छ। नियम लेख्दा टनेल अस्तित्वमा थिएन, त्यसैले तीमध्ये कुनैले पनि यसलाई समात्न सक्दैन, र सधैं रहेको अस्वीकार अब नाम समाधानमा लागू हुन्छ। शाब्दिक ठेगानामा सीधा ट्राफिक, फराकिलो अनुमतिले ढाकेको खण्डमा अझै काम गर्न सक्छ, र त्यसैले सार्वजनिक resolver मा ping सफल हुन्छ जबकि नाम खोज्ने असफल हुन्छ। खाडल भनेको नीतिले कहिल्यै नदेखेको इन्टरफेसका लागि नियम हो।
यसले किन असफलता सफा रूपमा उल्टिन्छ पनि व्याख्या गर्छ: टनेल तल झार्नुहोस्, नामहरू फेरि समाधान हुन्छन्, किनभने प्रश्न नियम भएको इन्टरफेसमा फर्किन्छ। टनेल उठेको बेला मात्र असफल हुने नीति DNS समस्या होइन, र resolver आफैं ट्युन गर्नु यहाँ सबैभन्दा धेरै समय बर्बाद गर्छ। resolver कन्फिगरेसन पढ्नुअघि इन्टरफेस सूची पढ्नुहोस्।
तीन दिशा, तीन फरक नियम-समूह
एक सत्रले एकभन्दा बढी दिशामा नियमहरूलाई छुन्छ, र टनेलले तीमध्ये लगभग सबैमा दोस्रो इन्टरफेस थप्छ। ट्राफिकलाई पहिले दिशा र इन्टरफेसअनुसार मिलाउँदा बाँकी यान्त्रिक हुन्छ, किनभने तलको हरेक पंक्तिलाई आफ्नै ठाउँमा आफ्नै नियम चाहिन्छ। उदाहरणहरूले tun0 र 10.8.0.0/24 को पोखरी प्रयोग गर्छन्, त्यसैले क्लाइन्टको आफ्नै आउटपुटबाट नाम र दायरा राख्नुहोस्।
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
दुई पंक्ति प्रायः गल्ती गरिन्छ किनभने दुवैले टनेलको उल्लेख गर्छन्। resolver को नियमले क्लाइन्टले टनेलमा पठाउने ट्राफिकलाई अनुमति दिन्छ, जबकि SSH को नियमले सर्भरले त्यहाँबाट पाउने ट्राफिकलाई अनुमति दिन्छ; ती फरक मेसिनमा बस्छन् र स्वतन्त्र रूपमा असफल हुन्छन्। सबैभन्दा धेरै बिर्सिने पंक्ति दोस्रो हो, किनभने सर्भरको सार्वजनिक ठेगानामा क्लाइन्टको ट्राफिकलाई अनुमति नदिएसम्म क्लाइन्टले टनेल नै बनाउन सक्दैन। माथिबाट तल काम गर्नुहोस् र हरेक असफलताको एउटा सम्भावित कारण हुन्छ।
धकेलिएको resolver लाई आफ्नै नियम चाहिन्छ
टनेलले DNS बोक्छ कि बोक्दैन भन्ने सर्भरले के पठाउँछ भन्नेमा निर्भर हुन्छ। resolver विकल्प धकेल्ने सर्भरले क्लाइन्टको कन्फिगरेसनमा निजी ठेगाना राख्छ, र त्यो ठेगाना टनेलबाट मात्र मार्गनिर्देशित हुन सक्छ। सर्भरले केही धकेल्दैन भने, क्लाइन्टले पहिलेको resolver राख्छ र तलका नियमहरूसँग अनुमति दिने केही हुँदैन। केही लेख्नुअघि धकेलिएको स्थिति र हालको प्रश्न परिणाम जाँच्नुहोस्:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedस्थिति आउटपुटले प्रयोगमा रहेको resolver र त्यो जोडिएको लिंकको नाम बताउँछ, र त्यसपछिको मार्ग खोजले कुन इन्टरफेसले त्यो ठेगानामा प्रश्न बोक्ने देखाउँछ। resolver अर्को लिंकमा बसेको छ भने, समस्या फायरवालभन्दा अघिको हो र कुनै नियमले सहयोग गर्दैन। दुवै टनेलमा सहमत भए भने दुई नियम चाहिन्छ, किनभने अधिकांश प्रश्न UDP ले बोक्छ र जवाफ काटिएपछि TCP ले लिन्छ। दुवै मान लेख्नुहोस्, किनभने नियमहरूले नाम लिने तिनै हुन्:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'भित्री मार्गभन्दा पहिले बाहिरी मार्ग खोल्नुहोस्
टनेल अस्तित्वमा आउनुअघि क्लाइन्टले सर्भरको सार्वजनिक ठेगानामा पुग्नुपर्छ, त्यसैले त्यसको नियम भौतिक लिंकमा बस्छ र पहिले ठाउँमा हुनुपर्छ। resolver लाई अनुमति दिएर सर्भर बिर्सने नीतिले क्लाइन्टलाई टनेल नै बनाउन नसक्ने अवस्थामा छोड्छ, र यो लक्षण सामान्यतया kill switch मा थोपारिन्छ। त्यसपछि तपाईंले साँच्चै टनेलबाट चाहेका सेवाहरूलाई अनुमति दिनुहोस्, एक पटकमा एउटा साँघुरो नियम, इन्टरफेस पूरै खोल्नुको सट्टा। साँघुरा नियमहरू नै अस्वीकार ठाउँमा रहन सक्ने कारण हुन्।
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'परीक्षण गर्दा क्रम महत्त्वपूर्ण हुन्छ, किनभने टनेल उठ्न दिने पहिलो नियम नै हो। त्यसलाई थप्नुहोस्, जोड्नुहोस्, र सेवा-नियम थप्नुअघि टनेल उठेको पुष्टि गर्नुहोस्, किनभने दुवै एकैचोटि गर्दा असफलताले कुन आधा गलत छ भन्ने केही बताउँदैन। माथिको कागजात ठेगानाको सट्टा क्लाइन्टलाई प्रयोग गर्न कन्फिगर गरिएको अन्त्य बिन्दु राख्नुहोस्।
जानाजानी जडान काटेर क्लाइन्ट पक्ष सक्नुहोस्। अस्वीकारले जानाजानी बाहिर राखिएको ट्राफिकलाई अझै अस्वीकार गर्नुपर्छ, किनभने टनेल उठेको बेला जवाफ दिने resolver ले शंका हुँदा अस्वीकार गर्ने नीतिको आधा मात्र ढाक्छ।
जोडिने क्लाइन्ट अझै स्वीकारिएको छैन
सर्भरलाई पनि आफ्नै दिशा विचार गर्नुपर्छ, र हात मिलाउने प्रक्रिया पूरा गर्ने क्लाइन्ट सर्भरले स्वीकार नगरेसम्म सर्भरमा चल्ने कुनै कुरामा पुग्न सक्दैन। सार्वजनिक सुन्ने नियमले टनेल अस्तित्वमा रहन मात्र अनुमति दिन्छ; यसले टनेलको ट्राफिक भित्र पस्न दिँदैन। सर्भरमा यो दुई नियम र सेवा साँच्चै सुनिरहेको छ भन्ने एउटा जाँच हो:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'नियमको पोखरी सर्भरले बाँड्ने दायरासँग बराबर हुनुपर्छ, र टनेल नम्बर सर्भरले बनाएकोसँग मिल्नुपर्छ, किनभने अर्को इन्टरफेसका लागि नियम नियम नभएजस्तै हुन्छ। limit प्रशासनिक पोर्टका लागि जानाजानी हो, किनभने यसले दोहोरिने जडानलाई असीमित स्वीकार गर्नुको सट्टा सीमित गर्छ। सुन्ने जाँचले बन्द पोर्ट र फालिएको प्याकेट छुट्याउँछ, जो क्लाइन्टबाट एउटै देखिन्छन्। क्रमांकित नियमहरू पनि पूरा चित्र होइनन्: UFW का before नियम र हातले लेखिएको कुनै पनि nftables लाइन पहिले मिल्छ र सूचीले अनुमति दिएको जस्तो देखिने प्याकेटलाई पनि अझै अस्वीकार गर्न सक्छ।