VPN प्रवाहमा क्लाइन्टको स्रोत पोर्ट र सर्भरको लिसनर
एउटै सुरुङमा दुई पोर्ट नम्बरको तुलना गर्नुहोस्: सर्भरको स्थिर लिसनर र क्लाइन्टको अल्पकालीन स्रोत, र तिनीहरूबीच राउटरको अनुवाद कसरी बस्छ।
एउटै कुराकानीमा दुई नम्बर देखिन्छन्, र दुवै गलत छैनन्। सर्भरको लगले सेवा दिने लिसनर देखाउँछ, ल्यापटपले डेटाग्राम पठाउने सकेट देखाउँछ, र बीचको राउटरले बाहिर जाँदा दोस्रोलाई फेरि लेख्न सक्छ। अंकको तुलना गर्नुभन्दा कुराकानीका दुई छेउको तुलना गर्नु बढी उपयोगी हुन्छ। तलको तुलनाले लिसनर, क्लाइन्ट सकेट र अनुवादित स्रोतलाई अलग राख्छ, किनकि तिनीहरू फरक प्रश्नको जवाफ दिन्छन्।
विपरीत छेउको वर्णन गर्ने दुई नम्बर
सर्भरको कन्फिगर गरिएको पोर्ट त्यो गन्तव्य हो जहाँ क्लाइन्ट डायल गर्छ। यसलाई नीतिले निश्चित गर्छ, यो प्रोफाइलमा देखिन्छ र सर्भरको तर्फ खुला हुनुपर्छ। क्लाइन्टको स्रोत पोर्ट स्थानीय रूपमा, सामान्यतया अल्पकालीन दायराबाट छानिन्छ, र जवाफलाई ओर्लने ठाउँ होस् भनेर हुन्छ। यो प्रत्येक पुनःजडानमा बदलिन सक्छ, र डिजाइनमा केही पनि यसको स्थिरतामा निर्भर छैन।
बीचको राउटरले त्यो स्रोतलाई आफ्नै 'NAT' म्यापिङमा फेरि लेख्न सक्छ। त्यसैले सर्भरमा देखिने नम्बरको ल्यापटपले छानेको नम्बरसँग प्रायः कुनै सम्बन्ध हुँदैन।
बाहिर जाँदा स्रोत नम्बर कहाँ बदलिन्छ
IPv4 को एउटा काल्पनिक उदाहरण लिनुहोस्: अनुवाद गर्ने राउटरको पछाडि एक क्लाइन्ट, एउटा 'UDP' लिसनर भएको सर्भर, र दुवैलाई पार गर्ने एउटै डेटाग्राम। तालिकाले तीन अवलोकन बिन्दुमा प्याकेट फेरि चलाउनुको सट्टा प्रत्येक छेउ र त्यससँग के हुन्छ भनेर नाम दिन्छ।
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
गन्तव्य हरेक पङ्क्तिमा स्थिर छ, र फेरिने स्रोतको पहिचान मात्र हो। UDP NAT का आवश्यकताहरू आन्तरिक ठेगाना र पोर्टलाई बाह्य म्यापिङबाट अलग गर्छन्, र यही दोस्रो र तेस्रो पङ्क्तिबीचको फरक हो। राउटरले क्लाइन्टको स्रोत पोर्ट राख्न सक्छ वा अर्को छान्न सक्छ; राखिन्छ भनेर अनुप्रयोगले मान्नु हुँदैन।
तीनै छेउ होस्टबाटै पढ्नुहोस्
तलका सूचीहरू तीन फरक मेसिनबाट आएका हुन् र सँगै पूरै कुराकानी देखाउँछन्। पहिलो सर्भरमा, दोस्रो क्लाइन्टमा र तेस्रो जहाँ म्यापिङ छ त्यहाँ चलाउनुहोस्। एउटा लग लाइनले कहिल्यै तीनै देखाउँदैन।
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194पहिलो सूचीले सर्भर सेवा पोर्टमा बाँधिएको प्रमाणित गर्छ र कुन प्रक्रियाले त्यसको स्वामित्व लिएको छ देखाउँछ। दोस्रोले क्लाइन्टको स्थानीय सकेट र डायल गरेको गन्तव्य देखाउँछ। तेस्रोले राउटरले बनाएको म्यापिङ देखाउँछ, र अनुवादित स्रोत देखिने एक मात्र ठाउँ त्यही हो। यही क्रममा पढ्नुहोस्, दुई नम्बर विरोधाभासी देखिन छाड्छन्।
पुनःजडानले के बदल्छ र के बदल्दैन
केही राउटरले क्लाइन्टको स्रोत पोर्ट खाली हुँदा राख्छन्, अरूले हरेक पटक फरक दिन्छन्। दुवै व्यवहार सामान्य हुन्, र पहिलो खोज्ने अनुप्रयोग दोस्रोमा टुट्छ। पुनःजडान वा सञ्जाल परिवर्तनपछि म्यापिङ बदलिनु सर्भरको खराबी होइन: क्लाइन्टले नयाँ सकेट खोल्छ, राउटरले आफ्नो भएको दिन्छ, र सर्भरले त्यही लिसनरमा नयाँ स्रोत देख्छ। खराबी तब हुन्थ्यो जब सर्भरले कुनै पनि क्लाइन्ट पोर्टमा पठाइएको ट्राफिक स्वीकार्ने अपेक्षा गरिन्थ्यो।
समुदायका OpenVPN क्लाइन्टले यो व्यवहार nobind मार्फत पाउँछन्, जसले अपरेटिङ सिस्टमलाई स्थानीय पोर्ट छान्न दिन्छ; टाढाको पोर्ट अझै प्रोफाइलबाट आउँछ। स्पष्ट रूपमा बाइन्ड गर्नु सचेत निर्णय हो, प्रोटोकलको आवश्यकता होइन। सर्भरले एउटा छेउ दिइरहन्छ र क्लाइन्टहरू आफ्नै स्थानीय पहिचान छान्छन्।
अभिलेखमा तहहरूलाई छुट्टाछुट्टै लेबल गर्नुहोस्
सुरुङभित्र आफ्नै पोर्ट भएको दोस्रो कुराकानी हुन्छ। सुरुङले बोक्ने HTTPS अनुरोधको गन्तव्य TCP 443 हो, जबकि बाहिरी इन्क्रिप्टेड जडानले UDP 1194 प्रयोग गर्छ, त्यसैले बाहिरी स्रोत पोर्ट बदल्दा भित्री सेवामा केही बदलिँदैन।
बाहिरी तहमा पनि प्रोटोकल महत्त्वपूर्ण छ। UDP 1194 र TCP 1194 फरक छेउ हुन्, र 'TCP' लिसनरले नम्बर मिल्यो भनेर कहिल्यै UDP डेटाग्राम पाउने छैन। परिनियोजनको कागजीकरण गर्दा सर्भर लिसनर, क्लाइन्ट सकेट र अनुवादित स्रोतलाई तीन फरक वस्तुका रूपमा लेबल गर्नुहोस्, र प्रत्येकमा यातायात थप्नुहोस्।
त्यसपछि नीतिले भूमिकाहरूको अनुसरण गरोस्। सर्भरले आफ्नो लिसनरमा अभिप्रेत यातायात खोल्छ र अझै साथीलाई प्रमाणित गर्छ; क्लाइन्टको फायरवलले इनबाउन्ड सेवा प्रकाशित नगरी आफ्नै आउटबाउन्ड आदानप्रदानका जवाफहरू स्वीकार्छ। स्टेटलेस फिल्टरले फर्कने दिशा स्पष्ट लेख्नुपर्छ, र सफा रेखाचित्रभन्दा बाहिर पनि यो भिन्नता महत्त्वपूर्ण हुनुको व्यावहारिक कारण यही हो।