VPN मात्र भएको iptables होस्ट: tun यन्त्रको नाम दिनुहोस्, tun+ होइन

tun+ मेसिनको हरेक सुरुङसँग मेल खान्छ। एउटा यन्त्र नाम निश्चित गर्नुहोस्, endpoint अपवाद पहिले राख्नुहोस् र नीति परीक्षण गर्दा पुनःस्थापनाको बाटो राख्नुहोस्।

-o tun+ लेख्नु ठ्याक्कै निर्देशन जस्तो लाग्छ र वास्तवमा यो कर्नेलसँग भएको हरेक सुरुङसँग मेल खाने वाइल्डकार्ड हो। दोस्रो VPN क्लाइन्ट, कन्टेनर ब्रिज वा क्र्यास भएको सत्रले छाडेको इन्टरफेस सबैले यसलाई पूरा गर्छन्, र त्यसपछि होस्टले नीतिले रोक्न खोजेको ट्राफिकलाई अनुमति दिन्छ। तलको प्रक्रियाले एउटा यन्त्र नाम निश्चित गर्छ, सुरुङ साँच्चै बन्न सक्ने गरी अपवादहरू मिलाउँछ र नियमहरू नराम्रोसँग परे फर्कने बाटो छाड्छ। हरेक चरण अलगै फिर्ता लिन सकिने गरी छोटो छ।

चरण 1: अहिले भएका नियमहरू लेख्नुहोस्

पूर्वनिर्धारित नीति बदल्नुअघि हालको अवस्था सुरक्षित गर्नुहोस्, ताकि रोलब्याक सम्झना नभई आदेश बनोस्। iptables-save > /root/iptables.pre हरेक तालिका तपाईंले पुनःस्थापना गर्न सक्ने फाइलमा लेख्छ, र तपाईंले सेट गर्न लागेको नीतिले त्यसलाई बोक्ने जडान काट्दा खुला root सत्र भएको दोस्रो टर्मिनल अतिशयोक्ति होइन। यदि तपाईं टाढाबाट काम गर्दै हुनुहुन्छ भने flush पनि आपत्कालीन स्विचको रूपमा तालिका बनाउनुहोस्।

त्यसपछि इन्टरफेसहरू सूचीबद्ध गर्नुहोस्, किनकि तपाईंले मानेको नाम त्यो नाम हो जो पढ्नुपर्थ्यो: ip -br link अहिले के छ देखाउँछ, र सुरुङ माथि नआएसम्म देखिँदैन। पढ्दै जाँदा यन्त्रका नामहरू लेख्दै जानुहोस्।

चरण 2: सुरुङलाई आफ्नै नाम दिनुहोस्

OpenVPN क्लाइन्ट कन्फिगरेसनमा dev tun_work स्वीकार्छ, र त्यसपछि Linux tun0 बाँड्नुको सट्टा ठ्याक्कै त्यही नामको इन्टरफेस बनाउँछ। अरू कसैले त्यसमा दाबी नगरेसम्म पुनःजडानहरूमा नाम स्थिर रहन्छ, र यन्त्रको नाम लिने नियमलाई अर्थपूर्ण बनाउने यही हो।

जहाँ नाम नियन्त्रण गर्न सकिँदैन, त्यहाँ सुरुङको ठेगाना वा प्याकेट चिन्हसँग मिलाउनुहोस्। दुवै काम गर्छन्, दुवै पढ्न गाह्रो छ, र सुरुङ पुनःक्रमाङ्कन हुँदा दुवै अझ शान्त रूपमा असफल हुन्छन्। जसरी भए पनि एउटै कुरासँग मिलाउनुहोस् र कुन भन्ने स्पष्ट पार्नुहोस्।

चरण 3: endpoint अपवाद पहिले राखेर नीति लेख्नुहोस्

VPN मात्र भएको होस्ट भनेको छोटो अपवाद सूचीसहितको पूर्वनिर्धारित-अस्वीकृति होस्ट हो, र सबैभन्दा महत्त्वपूर्ण अपवाद त्यो हो जसले सुरुङलाई अस्तित्वमा रहन दिन्छ। सुरुङ-यन्त्र नियमभन्दा पहिले endpoint नियम राखेर यही क्रममा बनाउनुहोस्, ताकि ह्यान्डसेकलाई जाने ठाउँ होस्:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

endpoint को शब्दशः ठेगाना र पोर्ट तपाईंको प्रदायकको हो, यो पृष्ठको होइन। endpoint होस्टनाम भए एकचोटि समाधान गरेर नतिजा निश्चित गर्नुहोस्, किनकि नियमले नाम खोज्न सक्दैन र घुम्ने उत्तरले अर्को DNS परिवर्तनपछि नीति चुपचाप तोड्छ। पोर्ट पनि जाँच्नुहोस्, किनकि तपाईंलाई TCP 443 मा सार्ने प्रदायकहरूलाई अन्यथा कसैले नलेखेको नियम चाहिन्छ। एउटै प्रोटोकलमा मात्र चल्ने सुरुङ सामान्यतया यही छुट हो, फायरवालको खराबी होइन।

राउटरमा त्यही आकार त्यसको पछाडिका क्लाइन्टका लागि FORWARD शृंखलामा जान्छ, र राउटरको आफ्नै ट्राफिकलाई आफ्नै नियम चाहिन्छ। केवल अगाडि पठाइएका प्याकेट ढाक्ने नियमसमूहले SSH र DNS लाई पुरानै बाटोमा छाड्छ, र सुरुङ माथि आउने क्षणमै राउटर अगम्य हुनु यही कारणले हो।

चरण 4: उपस्थिति मात्र होइन, क्रम जाँच्नुहोस्

नियमहरू क्रममा मूल्याङ्कन हुन्छन्, त्यसैले पहिले आउने ACCEPT ले पछि थपिएको REJECT लाई मात्र लुकाउँछ। established र related मिलानले नै सामान्य आगमन बाटो नखोली तपाईंका आफ्नै निर्गम अनुरोधका उत्तरहरू फर्कन दिन्छ, र यसलाई सुरुङ स्वीकृतिपछि राख्दा खसेको सुरुङले पनि आफ्नै इन्टरफेसमा फिर्ती ट्राफिक पार गर्छ।

नियमको संख्या एउटै स्क्रिनमा पढ्न सकिने गरी सानो राख्नुहोस्। जुन नियमसमूहको अडिट तपाईं गर्न सक्नुहुन्न, त्यही नै तपाईं माथि अपवाद थपेर टाल्नुहुनेछ, र पूर्वनिर्धारित-अस्वीकृति नीतिहरूले बिस्तारै पूर्वनिर्धारित-अनुमतिको किनारा पाउने तरिका यही हो। परिवर्तनअघि र पछि ACCEPT गन्नुहोस्।

चरण 5: बुट र ठेगाना परिवार दुवै टिक्ने बनाउनुहोस्

हातले हालेका नियम रिबुटमा हराउँछन्, त्यसैले तिनलाई वितरणको फायरवाल सेवा वा सुरुङ इन्टरफेस बनेपछि चल्ने unit बाट लोड गर्नुहोस्। OpenVPN सुरु हुनुअघि चल्ने स्क्रिप्टमा tun_work उल्लेख गर्नु खसेको ट्राफिकको बुट लूप बनाउने सामान्य तरिका हो।

त्यसपछि IPv6 छुट्टै जाँच्नुहोस्, किनकि IPv4 का लागि राम्रो पूर्वनिर्धारित-अस्वीकृति नीतिले अर्को परिवारबारे केही भन्दैन। ip -6 route ले होस्टसँग केवल IPv4 सम्हाल्ने सुरुङ वरिपरि ट्राफिक बोक्न सक्ने मार्ग छ कि छैन भन्ने बताउँछ, र ip6tables वा nftables लाई आफ्नै समान नियम चाहिन्छ। नियमसमूहको सममितिमा भरोसा गर्नुको सट्टा IPv6-only गन्तव्यसँग परीक्षण गर्नुहोस्।

चरण 6: प्रमाणित गर्नुहोस् र पुनःस्थापना गर्न तयार रहनुहोस्

सुरुङ माथि ल्याउनुहोस्, तपाईंको इच्छित सेवा चल्छ भनी पुष्टि गर्नुहोस्, त्यसपछि नीतिले अस्वीकार गर्नुपर्ने कुरा प्रयास गर्नुहोस्। उत्तरले तपाईंलाई अचम्मित पार्यो भने iptables-restore < /root/iptables.pre ले पुनःस्थापना गर्नुहोस्, र त्यसपछि मात्र नियम सम्पादन गर्न सुरु गर्नुहोस्। दिगोपन र परीक्षण गरिएको पुनःस्थापना मार्गले नै यसलाई दुईचोटि गर्न सकिने परिवर्तन बनाउँछ।

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