टनल उभी राहिल्यावर 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 ओळ आधी जुळते आणि यादी परवानगी देत असल्यासारखा दिसणारा पॅकेटही अजूनही नाकारू शकते.