एउटा LAN सबनेट OpenVPN बाट रुट गर्नु र पूर्वनिर्धारित राख्नु
एउटा सबनेट सुरुङबाट जाँदा LAN पूर्वनिर्धारित राख्नु। नीति तालिकालाई मुख्य तालिकाका सम्पादनसँग तुलना गर्नु, त्यसपछि NAT वा सर्भर-साइड रुट छान्नु।
जुन बाकसहरू LAN का लागि रुट गर्छन् र एकैसाथ VPN डायल गर्छन्, तिनीहरू आफैसँग उही बहसमा फस्छन्: सुरुङले पूर्वनिर्धारित रुटको मालिक बन्न चाहन्छ, र LAN लाई त्यो फिर्ता चाहिन्छ। OpenVPN जोडिँदा यसले सुरुङबाट एउटा पूर्वनिर्धारित वा दुई आधा-पूर्वनिर्धारित रुट राख्न सक्छ, जुन ल्यापटपका लागि ठीक र जसका छिमेकीहरू उसको LAN ठेगानाबाट जवाफ अपेक्षा गर्छन् त्यस्तो गेटवेका लागि गलत हो। जवाफ VPN छोड्नु होइन। जवाफ दुवै निर्णयलाई फरक तालिका दिनु हो।
एउटा पूर्वनिर्धारित रुट, दुई मालिक
फर्वार्ड गरिएको ट्राफिक र स्थानीय रूपमा उत्पन्न ट्राफिकले एउटै बाटो लिनुपर्दैन। LAN क्लाइन्टहरूलाई सुरुङ तपाईंले छान्नुभएका गन्तव्यहरूका लागि मात्र चाहिन्छ, जबकि होस्टका आफ्नै व्यवस्थापन सत्रहरू र ती क्लाइन्टहरूलाई दिइने जवाफहरूलाई LAN पूर्वनिर्धारित चाहिन्छ। दुवैलाई मुख्य तालिकामा मिसाउँदा दुई फरक प्रश्नमा एउटै जवाफ थोपरिन्छ।
OpenVPN मा ठ्याक्कै यसैका लागि एउटा स्विच छ। route-noexec क्लाइन्टलाई मुख्य तालिका छुनैबाट रोक्छ, र यसले प्रयोग गर्ने मानहरू route-up स्क्रिप्टमा route_vpn_gateway, dev र इन्टरफेसका ठेगानाका रूपमा निर्यात गरिन्छ। त्यसपछि कुन तालिकाले कुन रुट पाउने भन्ने तपाईंले निर्णय गर्नुहुन्छ, पछि पढ्न सकिने कोडमा।
नीति तालिका विरुद्ध मुख्य तालिका पुनर्लेखन
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
अलग तालिका एउटा सबनेटभन्दा माथि स्केल हुने एक मात्र विकल्प हो। यसलाई एक पटक नाम दिनु, त्यसपछि नामले नै सन्दर्भ गर्नु ताकि कसैले पनि संख्या सम्झनु नपरोस्:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnयहाँका ठेगानाहरू प्लेसहोल्डर हुन्। केही चलाउनु अघि आफ्नै परिनियोजनबाट LAN प्रिफिक्स, सुरुङ गेटवे र यन्त्रको नाम बदल्नु।
नियम होस्टसँग पनि मिल्नुपर्छ
LAN प्रिफिक्ससँग मात्र मिल्ने नियमले फर्वार्ड गरिएका प्याकेट समेट्छ। यसले गेटवे आफैले उत्पन्न गर्ने ट्राफिक समेट्दैन, र LAN क्लाइन्टहरूलाई फर्काइने जवाफहरू पनि समेट्दैन, जुनले स्रोतका रूपमा गेटवेको LAN ठेगाना बोक्छन्। ती खोजहरू main मा पर्छन् र अझै सुरुङबाट बाहिर जान सक्छन्।
गेटवेको आफ्नै LAN ठेगानाका लागि दोस्रो नियम थप्नु, वा पहिलो नियमलाई दुवै समेट्ने समूहसम्म फराकिलो बनाउनु। क्रम महत्त्वपूर्ण छ: बढी विशिष्ट नियम पहिले राख्नु, र स्रोत स्पष्ट रूपमा उल्लेख गर्ने खोजबाट नतिजा जाँच्नु।
ip route get 203.0.113.9 from 192.168.50.1यदि यसले स्थानीय रहनुपर्ने गन्तव्यका लागि सुरुङ यन्त्र देखाउँछ भने, तालिकामा जे भए पनि नियमहरूको समूह गलत हो।
NAT वा पारिपट्टिको रुट
VPN सर्भरले सुरुङ सबनेट मात्र जान्दछ, अरू केही होइन। LAN स्रोत ठेगानासँग आउने प्याकेटहरूको फर्किने बाटो हुँदैन जबसम्म कसैले त्यो उपलब्ध गराउँदैन, र त्यो उपलब्ध गराउने ठ्याक्कै दुई तरिका छन्। सर्भरमा LAN प्रिफिक्सका लागि रुट थप्दा मूल स्रोत एक छेउदेखि अर्को छेउसम्म देखिने रहन्छ, जुन लेखापरीक्षित डिजाइनले सामान्यतया चाहन्छ। गेटवेमा मास्करेड गर्दा स्रोत सुरुङ ठेगानामा पुनर्लेखन हुन्छ र सर्भरको कुनै सहयोग चाहिँदैन।
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEजब तपाईं सर्भर नियन्त्रण गर्नुहुन्न र त्यहाँ रुट थप्न सक्नुहुन्न, NAT छान्नु। लग, पहुँच नियन्त्रण वा फर्किने बाटोको सममिति महत्त्वपूर्ण हुँदा सर्भर-साइड रुट छान्नु, किनकि मास्करेडले मूल ठेगाना पारिपट्टिले अभिलेख गर्ने सबैबाट मेटाउँछ।
दुवै अवस्थामा फर्वार्डिङ सक्षम हुनुपर्छ, र कडा रिभर्स-पाथ फिल्टरिङले जवाफ खसाल्न सक्छ जब main ले त्यो स्रोतका लागि सुरुङ छानेको हुँदैन। सुरुङलाई दोष दिनु अघि प्रभावकारी मान जाँच्नु।
पुनः जडानपछि पनि विभाजन टिकिरहोस्
हातले थपिएका नियम र रुटहरू इन्टरफेस फेरि बनाइँदा हराउँछन्, र पुरानो तालिका प्रविष्टि यसलाई न्याय दिने सत्रभन्दा लामो रहन सक्छ। तालिकाको नियम, सुरुङको रुट र मास्करेड प्रविष्टि क्लाइन्टको route-up स्क्रिप्टभित्र राख्नु, र स्क्रिप्टको सुरुमा तालिका खाली गर्नु ताकि पुरानो गेटवे नयाँ सत्रमा टिक्न नसकोस्।
दुवै छेउबाट जाँच्नु: गेटवेमा LAN स्रोतसहित खोज, र LAN क्लाइन्टबाट सुरुङबाट जानुपर्ने गन्तव्यमा वास्तविक अनुरोध। अस्तित्वमा भए पनि कहिल्यै नछानिने रुट, काउन्टर नपढेसम्म रुट नै नभएजस्तै व्यवहार गर्छ।