टनल उठते ही UFW VPN के DNS सर्वर को छोड़ देता है
UFW की डिफ़ॉल्ट इनकार नीति टनल के इंटरफ़ेस को भी ढकती है। ट्रैफ़िक को दिशा से क्रमबद्ध करें, tun0 पर पुश किए गए रिज़ॉल्वर की अनुमति दें, फिर बाहरी रास्ता खोलें।
VPN कनेक्ट होते ही नाम हल होना बंद हो जाते हैं, जबकि किसी सार्वजनिक पते पर ping अब भी जवाब देता है और फ़ायरवॉल स्थिति में कुछ भी गलत नहीं दिखता। नीति में कुछ नहीं बदला; बदला यह है कि एक नया इंटरफ़ेस आया, और डिफ़ॉल्ट इनकार पहले पैकेट से ही उसे ढक लेता है। UFW दिशा और इंटरफ़ेस के आधार पर फ़ैसला करता है, इसलिए वायरलेस लिंक के लिए लिखा नियम टनल से निकलने वाले ट्रैफ़िक के बारे में कुछ नहीं कहता। मरम्मत कुछ संकरे नियमों की है जो एक ख़ास क्रम में लगाए जाते हैं।
लक्षण सिर्फ़ टनल उठने के बाद दिखता है
डिफ़ॉल्ट इनकार नीति ठीक वही करती है जो उसे कहा गया: मेल खाता नियम न होने पर हर चीज़ अस्वीकार होती है, मौजूद हर इंटरफ़ेस पर। नियम लिखे जाने के समय टनल मौजूद नहीं थी, इसलिए उनमें से कोई उसे पकड़ नहीं सकता, और जो इनकार हमेशा से था वह अब नाम हल करने पर लागू होता है। किसी शाब्दिक पते पर सीधा ट्रैफ़िक तब भी काम कर सकता है जब कोई व्यापक अनुमति उसे ढक ले, और इसीलिए सार्वजनिक रिज़ॉल्वर पर ping सफल होता है जबकि नाम खोजना विफल हो जाता है। कमी उस इंटरफ़ेस के लिए नियम की है जिसे नीति ने कभी नहीं देखा।
यह भी बताता है कि विफलता साफ़ तौर पर क्यों पलट जाती है: टनल नीचे उतारो और नाम फिर हल होने लगते हैं, क्योंकि क्वेरी ऐसे इंटरफ़ेस पर लौट जाती है जिसके पास नियम हैं। जो नीति सिर्फ़ टनल चालू रहने पर विफल होती है वह DNS समस्या नहीं है, और रिज़ॉल्वर को ही ट्यून करना यहाँ सबसे ज़्यादा समय बर्बाद करता है। रिज़ॉल्वर कॉन्फ़िग पढ़ने से पहले इंटरफ़ेस सूची पढ़ें।
तीन दिशाएँ, तीन अलग नियम-समूह
एक सत्र एक से ज़्यादा दिशाओं में नियमों को छूता है, और टनल लगभग हर एक में दूसरा इंटरफ़ेस जोड़ देती है। ट्रैफ़िक को पहले दिशा और इंटरफ़ेस से क्रमबद्ध करना बाकी काम को यांत्रिक बना देता है, क्योंकि नीचे की हर पंक्ति को अपनी जगह पर अपना नियम चाहिए। उदाहरण 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 |
दो पंक्तियाँ अक्सर उलझ जाती हैं क्योंकि दोनों टनल का ज़िक्र करती हैं। रिज़ॉल्वर का नियम उस ट्रैफ़िक की अनुमति देता है जो क्लाइंट टनल में भेजता है, जबकि SSH का नियम उस ट्रैफ़िक की अनुमति देता है जो सर्वर वहाँ से पाता है; वे अलग मशीनों पर रहते हैं और स्वतंत्र रूप से विफल होते हैं। सबसे अधिक भूली जाने वाली पंक्ति दूसरी है, क्योंकि क्लाइंट टनल तब तक बना ही नहीं सकता जब तक सर्वर के सार्वजनिक पते पर उसका ट्रैफ़िक अनुमत न हो। ऊपर से नीचे काम करें और हर विफलता का एक संभावित कारण होता है।
पुश किए गए रिज़ॉल्वर को अपना नियम चाहिए
टनल DNS ले जाती है या नहीं, यह इस पर निर्भर है कि सर्वर क्या भेजता है। जो सर्वर रिज़ॉल्वर विकल्प पुश करता है वह क्लाइंट के कॉन्फ़िग में एक निजी पता डालता है, और वह पता सिर्फ़ टनल से ही रूट हो सकता है। अगर सर्वर कुछ पुश नहीं करता, तो क्लाइंट अपने पहले वाले रिज़ॉल्वर को रखता है और नीचे के नियमों के पास अनुमति देने को कुछ नहीं होता। कुछ भी लिखने से पहले पुश की गई स्थिति और मौजूदा क्वेरी परिणाम जाँचें:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedस्थिति आउटपुट इस्तेमाल हो रहे रिज़ॉल्वर और उस लिंक का नाम बताता है जिससे वह बंधा है, और उसके पीछे की रूट खोज बताती है कि कौन-सा इंटरफ़ेस उस पते तक क्वेरी ले जाएगा। जब रिज़ॉल्वर किसी दूसरे लिंक पर बैठा हो, समस्या फ़ायरवॉल से पहले की है और कोई नियम मदद नहीं करेगा। जब दोनों टनल पर सहमत हों, दो नियम चाहिए, क्योंकि ज़्यादातर क्वेरी 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'अंदर के रास्ते से पहले बाहर का रास्ता खोलें
टनल बनने से पहले क्लाइंट को सर्वर के सार्वजनिक पते तक पहुँचना होता है, इसलिए उसका नियम भौतिक लिंक पर बैठता है और पहले जगह पर होना चाहिए। जो नीति रिज़ॉल्वर की अनुमति देती है पर सर्वर भूल जाती है, वह क्लाइंट को टनल बनाने में बिल्कुल अक्षम छोड़ देती है, और यह लक्षण आमतौर पर 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'परीक्षण के दौरान क्रम मायने रखता है, क्योंकि पहला नियम ही टनल को उठने देता है। उसे जोड़ें, कनेक्ट करें, और सेवा-नियम जोड़ने से पहले पुष्टि करें कि टनल ऊपर है, क्योंकि दोनों एक साथ करने का मतलब है कि विफलता यह नहीं बताती कि कौन-सा आधा ग़लत है। ऊपर के दस्तावेज़ी पते की जगह वह एंडपॉइंट रखें जिसके लिए क्लाइंट कॉन्फ़िगर है।
जान-बूझकर डिस्कनेक्ट करके क्लाइंट पक्ष पूरा करें। इनकार को अब भी उस ट्रैफ़िक को अस्वीकार करना चाहिए जिसे आपने जान-बूझकर बाहर रखा, क्योंकि टनल चालू रहने पर जवाब देने वाला रिज़ॉल्वर संदेह होने पर इनकार करने वाली नीति का सिर्फ़ आधा हिस्सा ढकता है।
कनेक्ट होने वाला क्लाइंट अभी स्वीकृत नहीं है
सर्वर को अपनी दिशा सोचनी होती है, और हैंडशेक पूरा करने वाला क्लाइंट तब तक सर्वर पर चल रही किसी चीज़ तक नहीं पहुँच सकता जब तक सर्वर उसे स्वीकार न करे। सार्वजनिक लिसनर का नियम सिर्फ़ टनल के अस्तित्व की अनुमति देता है; वह टनल के ट्रैफ़िक को अंदर नहीं आने देता। सर्वर पर ये दो नियम और एक जाँच है कि सेवा वास्तव में सुन रही है:
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 पंक्ति पहले मेल खाती है और सूची जिस पैकेट की अनुमति देती दिखती है उसे भी अब भी अस्वीकार कर सकती है।