मास्करेड वा नीति-आधारित राउटिङ: VPN गेटवेमार्फत LAN ट्राफिक

पूरै LAN लाई VPN टनेलको पछाडि राख्नु सजिलो भाग हो; दुर्गम पक्षले ती क्लाइन्टहरूलाई कसरी देख्छ भन्ने निर्णय गर्नु सजिलो छैन। मास्करेडले प्रत्येक LAN स्रोतलाई गेटवेको टनेल ठेगानामा पुनःलेखन गर्छ, त्यसैले दुर्गम पक्षले एक पियरलाई जवाफ दिन्छ। नीति-आधारित राउटिङले मूल ठेगानाहरू कायम राख्छ र दुर्गम पक्षले तिनीहरूमा कसरी पुग्ने जान्नुपर्ने माग गर्छ। दुवैमध्ये कुनै पनि पूर्वनिर्धारित होइन; छनोट दुर्गम पक्ष कसको हो र प्रति-उपकरण पहिचान महत्त्वपूर्ण छ कि छैन भन्नेमा निर्भर गर्दछ।

दुई डिजाइनले फरक कुराहरूको वाचा गर्छन्

मास्करेडले LAN लाई एउटै देखिने होस्टमा घटाउँछ: गेटवे। दुर्गम सञ्जालले त्यही एउटा ठेगानालाई जवाफ दिन्छ, र गेटवेले जवाफहरूलाई प्रवाह सुरु गर्ने क्लाइन्टतर्फ फर्काएर अनुवाद गर्छ। दुर्गम पक्षमा तपाईंका निजी प्रिफिक्सहरूका लागि कुनै मार्ग आवश्यक पर्दैन, त्यसैले यो डिजाइन तिनीहरूलाई बोक्न अस्वीकार गर्ने प्रदायकसँग पनि टिक्छ। गेटवे हरेक जडानको स्रोत पनि बन्छ, त्यसैले दुर्गम पक्षले दुई क्लाइन्ट छुट्याउन सक्दैन।

नीति-आधारित राउटिङले प्रत्येक क्लाइन्टको ठेगाना अक्षुण्ण राख्छ। दुर्गम सञ्जालले वास्तविक स्रोत देख्छ र त्यसलाई लग गर्न, प्रति-होस्ट नियम लागू गर्न वा जवाफ सिधै त्यो ठेगानामा पठाउन सक्छ। यही दृश्यता पूरै कुरा हो, र यससँग एउटा दायित्व आउँछ: दुर्गम पक्षसँग LAN प्रिफिक्सका लागि टनेलबाट फर्किने मार्ग हुनुपर्छ। नियम सक्रिय गर्नुअघि त्यो मार्ग योजना गर्नुहोस्, किनभने टनेल जसरी पनि उठ्नेछ र केवल जवाफहरू मात्र कमी हुनेछन्।

असफलताका तरिकाहरू वाचाहरूजत्तिकै फरक छन्। अनुपस्थित मास्करेड नियमले निजी स्रोतसहित बाहिर जाने र कहिल्यै नफर्किने प्याकेटहरू उत्पादन गर्छ। अनुपस्थित फिर्ती मार्गले नीति-आधारित राउटिङमा त्यही लक्षण दिन्छ, तर सुधार गेटवेमा होइन, दुर्गम राउटरमा हुन्छ।

मास्करेड: दुर्गम पक्षमा एक पियर

मास्करेड मार्गको एउटा क्रम छ जुन महत्त्वपूर्ण छ। कुनै पनि NAT नियमले काम गर्नुअघि फर्वार्डिङ सक्रिय हुनुपर्छ, फिल्टर तालिकाले दुवै दिशामा गुज्रन अनुमति दिनुपर्छ, र त्यसपछि मात्र टनेल इन्टरफेसमा अनुवाद लागू हुन्छ।

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

क्लाइन्टहरूलाई अझै गेटवेसम्म मार्ग चाहिन्छ। कि त गेटवे तिनीहरूको पूर्वनिर्धारित राउटर हो, वा तिनीहरूले दुर्गम प्रिफिक्सका लागि विशेष मार्ग बोक्छन्; यदि अलग राउटर पूर्वनिर्धारित रह्यो भने, त्यो राउटरलाई टनेलका गन्तव्यहरूका लागि स्थिर मार्ग चाहिन्छ, नत्र गेटवेले देख्नुअघि प्याकेट गलत हपमा जान्छ।

DNS एउटा अलग निर्णय हो। दुर्गम पक्षको रिजोल्भरले आफ्नो जवाफ क्लाइन्टसम्म फर्किन सक्छ भने मात्र जवाफ दिन्छ। मास्करेडमा प्रश्न गेटवेबाट आएको जस्तो देखिन्छ, त्यसैले रिजोल्भरको फिर्ती मार्ग पहिले नै पूरा छ; नीति-आधारित राउटिङमा रिजोल्भरलाई अन्य कुनै पनि दुर्गम सेवाजस्तै त्यही फिर्ती मार्ग चाहिन्छ।

नीति-आधारित राउटिङ: स्रोत राख्नुहोस्, फिर्ती मार्ग थप्नुहोस्

नीति-आधारित राउटिङ तालिका र त्यसलाई छान्ने नियमबाट सुरु हुन्छ। LAN इन्टरफेसबाट आउने ट्राफिक समर्पित तालिकामा पठाइन्छ, र त्यो तालिकाले टनेलबाट पूर्वनिर्धारित मार्ग बोक्छ। मुख्य तालिका अस्पर्शित रहन्छ, त्यसैले गेटवेले आफैं सिर्जना गरेको ट्राफिक अर्को बाटो लिन सक्छ।

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

त्यसपछि दुर्गम पक्षले LAN प्रिफिक्सलाई टनेलबाट फर्काएर राउट गर्नुपर्छ। त्यो यो गेटवेमा होइन, दुर्गम राउटरमा गरिने कन्फिगरेसन हो। गेटवेले मुख्य तालिकाले अपेक्षा गर्नेभन्दा फरक इन्टरफेसमा आउने जवाफहरू पनि स्वीकार्नुपर्छ; कडा मोडले ती प्याकेटहरू छोड्दा ढिलो उल्टो-मार्ग फिल्टरिङ (rp_filter 2 मा सेट) सामान्य समायोजन हो।

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

स्वामित्व र दुर्गम पक्षले के लग गर्छ भन्नेका आधारमा निर्णय गर्नुहोस्

यदि टनेल प्रदायकमा अन्त्य हुन्छ भने, मास्करेड प्रयोग गर्नुहोस्। त्यो अपरेटरले तपाईंका निजी LAN दायराहरू राउट गर्दैन, र तपाईंको गेटवेको पछाडिका व्यक्तिगत क्लाइन्टहरू छुट्याउने कारण उसँग छैन। एउटा देखिने पियर नै उसको नीतिले समर्थन गर्ने एकमात्र मोडेल हो, त्यसैले त्यही दिनुहोस् र अनुवाद तपाईंको किनारामा राख्नुहोस्। प्रदायकले एक पियर देख्छ, जुन उसको नीतिले ठ्याक्कै अपेक्षा गर्ने कुरा हो, र तपाईंका क्लाइन्टहरूले त्यही एक पहिचान उत्तराधिकारमा पाउँछन्।

यदि दुवै छेउ तपाईंका हुन् र दुर्गम सेवाहरू स्रोत ठेगानामा कार्य गर्छन् भने, नीति-आधारित राउटिङ आफ्नो थप मार्गको योग्य छ। त्यसपछि फायरवाल नियम, प्रति-प्रयोगकर्ता पहुँच र अडिट लगहरूले क्लाइन्टहरू छुट्याउन सक्छन्। यदि दुर्गम पक्षलाई केवल पहुँच चाहिन्छ भने, मास्करेड सरल छ र फिर्ती-मार्गका त्रुटिहरूको एक वर्ग हटाउँछ।

हाइब्रिड डिजाइनहरू सामान्य छन्: तपाईंको आफ्नै सञ्जालमा नीति-आधारित राउटिङ, प्रदायकको किनारामा मास्करेड। महत्त्वपूर्ण कुरा कुन हपले अनुवाद गर्छ र कुन हपले राउट गर्छ भनी लेख्नु हो, किनभने एक क्लाइन्टका लागि दुर्घटनावश थपिएको NAT नियमले त्यही श्रृंखलाका हरेक क्लाइंटको स्रोत लुकाउँछ।

एक क्लाइन्टबाट जाँच्नुहोस्, त्यसपछि दोस्रो क्लाइन्टबाट

परीक्षण ट्राफिक सुरु हुने ठाउँमा चलाउनुहोस्। होस्टले प्रयोग गर्ने मार्ग जाँच्नुहोस्, टनेल इन्टरफेसमा प्याकेट देखा पर्ने नियाल्नुहोस्, र अनुवादका लागि conntrack जाँच्नुहोस्। त्यो क्रमले प्याकेटले इच्छित बाटो लियो भनी प्रमाणित गर्छ, केवल कतै पुग्यो भनेर होइन।

पुनःजडानपछि परीक्षण दोहोर्याउनुहोस्। इन्टरफेसको नाम लिने मास्करेड नियम नयाँ टनेल ठेगानामा टिक्छ; पुरानो ठेगानाको नाम लिने नियम टिक्दैन। त्यसपछि दोस्रो LAN होस्ट परीक्षण गर्नुहोस्, किनभने एक मेसिनमा चल्ने डिजाइन प्रायः त्यही मेसिनको आफ्नै मार्गमा निर्भर हुन्छ, गेटवेको नीतिमा होइन।

छानिएको मोडेल, अनुवादित वा सुरक्षित स्रोत र फिर्ती मार्गको मालिक गेटवेका टिप्पणीहरूमा लेख्नुहोस्। नत्र क्लाइंट वा टनेल थप्ने अर्को व्यक्तिले अनुमान गर्नेछ, र अनुमान नै चलिरहेको LAN-देखि-VPN सेटअप आधा-अधुरो बनाउने तरिका हो।