पोर्ट फर्वार्डिङ वनाम VPN पहुँच: प्याकेट वास्तवमा कहाँ जान्छ

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

DNAT नियम गन्तव्य पुनः लेख्छ र त्यहीँ रोकिन्छ

Linux गेटवेमा सेवा प्रकाशित गर्नु भनेको nat तालिकाको PREROUTING श्रृंखलामा नियम, वा nftables मा त्यसको समतुल्य। नियम सार्वजनिक ठेगाना र पोर्टसँग मिल्छ, त्यसपछि गन्तव्यलाई अनुप्रयोगको निजी ठेगानामा पुनः लेख्छ। स्रोत ठेगाना, स्रोत पोर्ट र पेलोड अछुत रहन्छ, र conntrack ले म्यापिङ अभिलेख गर्छ ताकि जवाफ बाहिर जाँदा फेरि लेखियोस्। यो व्यवहार RFC 3022 मा वर्णित परम्परागत ठेगाना अनुवाद मोडेल हो।

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

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

नियमले पछि भेटिने असफलता मोडहरू पनि निर्धारण गर्छ। यदि गेटवे फर्वार्ड गर्छ तर अनुप्रयोगको होस्टसँग ग्राहकतर्फ फर्कने मार्ग छैन भने जवाफ गलत स्रोतसहित बाहिर जान्छ र ह्यान्डसेक रोकिन्छ। दोस्रो नियम पहिले मिल्यो भने क्रमले नतिजा निर्धारण गर्छ, र iptables -t nat -L -n -v ले कुन नियमले प्याकेट लियो भनी प्रमाणित गर्ने काउन्टर देखाउँछ।

सुरुङले श्रोता देख्नुअघि प्याकेट बेर्छ

VPN ले अनुप्रयोग प्रकाशित गर्दैन। ग्राहकले गेटवेको सार्वजनिक ठेगानातर्फ लक्षित बाह्य प्याकेट बनाउँछ, भित्री प्याकेट त्यसभित्र इन्क्रिप्ट गर्छ, र गेटवेले डिक्रिप्ट गरी भित्री प्याकेटलाई निजी गन्तव्यतर्फ रुट गर्छ। WireGuard मा बाह्य ढुवानी UDP हो, सामान्यतया उच्च पोर्टमा; OpenVPN TCP 443 मा हुँदा मार्ग हेर्ने जोकोहीलाई बाह्य प्याकेट TLS जस्तो देखिन्छ।

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

बेर्नाले हेडर ठाउँ खर्च गर्छ, र यो नै माप्न सकिने परिणाम भएको एकमात्र संयन्त्र-स्तरको भिन्नता। बाह्य IP हेडर र UDP र WireGuard को आफ्नै हेडरले मार्गको MTU मा खान्छ, त्यसैले ठूला प्याकेट टुक्र्याउनुपर्छ वा भित्री TCP स्ट्याकले आफ्नो MSS सीमित गर्नुपर्छ। फर्वार्ड गरिएको मार्गमा चल्ने स्थानान्तरण सुरुङमा अड्किन सक्छ जब बीचको उपकरणले सानो MTU संकेत गर्ने ICMP फाल्छ।

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

अवस्थिति प्रवेशद्वारमा निर्धारण हुन्छ, साइफरले होइन

दुवै डिजाइन एउटै TLS श्रोतामा टुंगिन्छन्, त्यसैले दुवैले उही प्रमाणपत्र, उही प्रोटोकल संस्करण र उही अनुप्रयोग लगइन पाउँछन्। बदलिने कुरा यो हो कि कसलाई ह्यान्डसेक सुरु गर्न अनुमति छ। सार्वजनिक फर्वार्डमा, 203.0.113.10:443 सम्म पुग्ने जोकोही होस्टले तपाईंको अनुप्रयोग अनुमति जाँचिनु अघि नै TCP ह्यान्डसेक र TLS ClientHello पाउँछ। सुरुङबाट मात्र पहुँचमा, श्रोतासम्म गेटवेले सुरुङमा रुट गर्ने ठेगानाबाट मात्र पुग्न सकिन्छ, र अपरिचितको SYN गेटवे नीतिमा मर्छ।

यो भिन्नता पहुँचको बारेमा हो, गोपनीयताको होइन। फर्वार्ड गरिएको HTTPS सेवा सादा पाठ होइन, र VPN ले अनुप्रयोग प्रमाणीकरणको आवश्यकता हटाउँदैन: सुरुङ प्रवेशले उपकरणले यो सञ्जालमा प्याकेट पठाउन सक्छ कि भन्ने जवाफ दिन्छ, जबकि फाइल अनुप्रयोगले प्रयोगकर्ताले कागजात पढ्न सक्छ कि भन्ने। दुवैलाई मिसाउनु नै टोलीहरू सम्पूर्ण LAN दिने VPN र एउटै साझा पासवर्ड भएको अनुप्रयोगसम्म पुग्ने बाटो हो।

श्रोता र नीति छुट्टाछुट्टै जाँच्नुहोस्, किनकि जुनसुकै पनि तपाईंको अनुमानभन्दा फराकिलो हुन सक्छ:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

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

मार्ग नाप्नुहोस्, लेबल होइन

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

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

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

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

डिजाइन पूर्ण भनी घोषणा गर्नु अघि चार कुरा पुष्टि गर्नुहोस्: श्रोता कुन ठेगानामा बाँधिएको छ, कुन नियम वा रुटले प्याकेट भित्र लिन्छ, ग्राहकको वास्तविक ठेगानाबाट फर्कने मार्ग चल्छ कि, र ठूला पेलोड MTU पार गर्छन् कि। यी प्रत्येकका लागि माथि आदेश छ, र कुनैको पनि जवाफ «सुरक्षित» शब्द वा ब्यान्डविथ चार्टले दिँदैन।