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

दुई आकार, एउटा भेटघाट स्थल

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

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

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

दुवै आकारमध्ये कुनै पनि रचनागत रूपमा बढी सुरक्षित छैन। दुवैले एउटा सेवा पोर्टलाई सर्भरको सार्वजनिक ठेगानासम्म पुग्न सक्ने सबैका लागि खोल्छन्, र दुवै अझै सेवाकै प्रमाणीकरणमा निर्भर छन्।

सर्त एक: के पोर्ट सत्रभन्दा लामो बाँच्नुपर्छ

उल्टो फर्वार्डिङ त्यसलाई बनाउने SSH सत्र जति बाँच्छ, ठ्याक्कै त्यति बाँच्छ। लिङ्क टुट्दा सुन्ने हराउँछ र सहकर्मीले ढिलो बाटोको सट्टा अस्वीकृत जडान देख्छ। systemd युनिट र रिस्टार्ट नीतिसहित आदेशको अनुगमनले यसलाई सुधार्छ, र ExitOnForwardFailure=yes असफल बाइन्डलाई तुरुन्तै देखिने बनाउँछ, फर्वार्डिङ बिना चलिरहेको सत्र छोड्नुको सट्टा।

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

सेवाले राति तीन बजे कसैले नहेरी जवाफ दिनुपर्ने भए, सर्भरले प्रकाशित गरेको पोर्ट भएको आकारमा कम चल्ने भाग हुन्छन्, किनकि चालु राख्नुपर्ने एकमात्र प्रक्रिया सुरुङ आफै हो।

सर्त दुई: फायरवाल र लग कसका हुन्

उल्टो आकारले सबै नीति दुई ठाउँमा राख्छ। sshd ले AllowTcpForwarding मार्फत टाढाको फर्वार्डिङ नै अनुमति छ कि छैन निर्धारण गर्छ, र GatewayPorts ले सुन्ने लूपब्याकमा बाँधिन्छ कि हरेक ठेगानामा भनी निर्धारण गर्छ। पूर्वनिर्धारित no हुँदा सर्भरबाहिरको सहकर्मी फर्वार्डिङ सफल भए पनि पोर्टमा पुग्न सक्दैन, र त्यो बिग्रिएको सुरुङजस्तो देखिन्छ, वास्तवमा त्यो बाइन्ड ठेगाना हो।

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

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

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

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

सर्त तीन: एउटा पोर्ट कि धेरै, र नाम कसको

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

नामले यसलाई अझ जटिल बनाउँछ। उल्टो फर्वार्डिङ SNI अनुसार रुट गर्ने TCP प्रोक्सीपछाडि बस्न सक्छ, जबकि अनुवादित पोर्ट सामान्यतया प्रति सेवा एउटा पोर्ट हुन्छ। सेवाले आफै TLS अन्त्य गर्छ र मूल होस्टनाम चाहिन्छ भने, प्रोक्सी दृष्टिकोणले त्यो जोगाउँछ, र DNAT दृष्टिकोणले सेवाले त्यो पोर्टमा त्यो नाम स्वीकारेमा मात्र जोगाउँछ।

तीन सर्तमध्ये कसले आकार निर्धारण गर्यो लेख्नुहोस्। नत्र दोस्रो सेवा थप्ने अर्को व्यक्तिले कम सन्दर्भसहित त्यही तुलना फेरि खोल्नेछ।

निर्णय गर्नुहोस्, त्यसपछि बाहिरबाट परीक्षण गर्नुहोस्

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

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

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

आकार काम गर्न थालेपछि पोर्ट, मालिक र अनुगमन विधि सुरुङ कन्फिगरेसनको छेउमा लेख्नुहोस्। कसैको शेल इतिहासमा मात्र भएको पहुँच सुधार एक रिबुट टाढाको दोहोरिने घटना हो।

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