दुई अपलिंक तर एउटै सुरुङ: फेलओभर, सन्तुलन वा बन्डिङ
फेलओभर, प्रति-प्रवाह सन्तुलन र एउटै प्रवाहको एकत्रीकरण तीन फरक वाचाहरू हुन्। दुई डिफल्ट मार्गले तपाईंलाई पहिलो दिन्छ, अरू दुई दिँदैन।
दुई इन्टरनेट लाइनले VPN लाई बढी उपलब्ध बनाउन सक्छन्, र केही कार्यभारका लागि छिटो पनि बनाउन सक्छन्, तर यी दुईमध्ये कुन हुने भन्ने कुरा संयन्त्रले निर्धारण गर्छ। दुई डिफल्ट मार्ग भएको राउटर बन्डेड होइन, र हजारौं आन्तरिक जडान बोक्ने सुरुङ पनि अझै एउटै बाह्य प्रवाह हो। वाचालाई पहिले नाम दिनु नै डिजाइन र महँगो निराशाबीचको भिन्नता हो। तलको तालिकाले प्रत्येकलाई टाढाको छेउमा के चाहिन्छ र लिङ्क गएपछि स्थानान्तरणलाई के हुन्छ भन्ने आधारमा विकल्पहरू छुट्याउँछ।
तीन वाचा, र एउटालाई मात्र साझेदार चाहिन्छ
फेलओभरले मनपर्ने लिङ्क हराएपछि पनि मार्ग उपलब्ध राख्छ। प्रवाह-ह्यास सन्तुलनले स्वतन्त्र प्रवाहहरूलाई दुवै अपलिंकमा फैलाउँछ। एउटा-प्रवाह एकत्रीकरणले एउटा स्थानान्तरणलाई एकैचोटि दुवै लिङ्क प्रयोग गर्न दिन्छ। यी फरक आवश्यकता भएका फरक उत्पादन हुन्, र अन्तिमलाई मात्र तपाईंको राउटरबाहिरको कुनै कुराको सहयोग चाहिन्छ।
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
त्यो तालिकामा दोस्रो लाइन किन्ने कारण अरू केही छैन। यसले गर्ने काम यो हो: फेलओभर डिजाइनलाई बन्डिङ ठानेर मूल्याङ्कन गर्नबाट रोक्छ।
राउटरलाई सुरुङ एउटै प्रवाह जस्तो किन देखिन्छ
भार सन्तुलन गर्ने राउटरले स्रोत र गन्तव्य ठेगानाहरूलाई पोर्टसँगै ह्यास गर्छ, त्यसपछि पूरै प्रवाह ह्यासले देखाएको ठाउँमा पठाउँछ। राउटरको दृष्टिकोणबाट VPN सुरुङ त्यस्तै एउटा प्रवाह हो, भित्र जे चले पनि। आन्तरिक जडानहरू कहिल्यै ह्यासको निर्णयसम्म पुग्दैनन्, किनकि बाह्य हेडरले मार्ग पहिले नै तय गरिसकेको हुन्छ। त्यसैले दोस्रो अपलिंकले धेरै प्रयोगकर्ताका लागि कुल क्षमता दोब्बर बनाउन सक्छ र एउटा प्रयोगकर्ताको ठूलो स्थानान्तरणमा केही पनि बदल्दैन।
दुई छुट्टै सुरुङले तपाईंलाई दुई उम्मेदवार दिन सक्छन्, तर तिनलाई अझै ट्राफिक बाँडफाँट गर्ने र अनुरोध लगेको मार्गमै जवाफ राख्ने जानाजानी नीति चाहिन्छ। त्यो चरण छोड्ने सामान्य परिणाम असममित राउटिङ हो। न्यूनतम भनेको प्रवाह, मनपर्ने लिङ्क र ब्याकअप लिङ्कको नाम लिने नीति हो।
इथरनेट बन्डिङ असम्बन्धित प्रदायकहरूसम्म जाँदैन, किनकि टाढाको छेउले एकत्रीकरण प्रोटोकलमा सहभागी हुनुपर्छ। सहयोग गर्ने अन्त्यबिन्दु नभएसम्म दुई ISP बीचको बन्डिङ अनुसन्धान परियोजना हो।
मल्टिपाथ TCP लाई दुवै छेउमा के चाहिन्छ
Linux को Multipath TCP कागजात ले एउटै जडानसँग सम्बन्धित धेरै उप-प्रवाहहरू वर्णन गर्छ। एउटा छेउमा कर्नेल समर्थन आफैंले केही बदल्दैन, किनकि साथीले पनि ती उप-प्रवाह स्वीकार्नुपर्छ। टाढाको तर्फ प्रोक्सी अर्को सामान्य व्यवस्था हो, र त्यो आफ्नै क्षमता र उपलब्धता भएको घटक बन्छ जसको योजना बनाउनुपर्छ। त्यही तर्कले WireGuard का लागि सजिलो उत्तर अस्वीकार गर्छ, जसको यातायात UDP हो: MPTCP ले TCP उप-प्रवाह बढाउँछ र डिजाइनमा अरू केही नभई त्यो सुरुङ एकत्रीकरण गर्न सक्दैन।
कर्नेल सुविधा सक्रिय छ कि छैन त्यसको वरिपरि डिजाइन गर्नुअघि जाँच्नुहोस्, किनकि धेरै वितरणहरूले यसलाई बन्द अवस्थामा दिन्छन्। यी तीन आदेशले एक मिनेटमा जवाफ दिन्छन्।
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showब्रोसर होइन, कार्यभार हेरेर छान्नुहोस्
कार्यभार धेरै स्वतन्त्र सत्रहरू भएमा, प्रवाह-ह्यास सन्तुलनले टाढाको छेउको सहयोगबिना क्षमता थप्न सक्छ। एउटा ठूलो स्थानान्तरण भएमा, एकत्रीकरणको डिजाइनले मात्र मद्दत गर्छ, र त्यो डिजाइनलाई सहयोग गर्ने साथी चाहिन्छ। लिङ्क मरेपछि पनि काम चलिरहनु आवश्यकता भएमा, उत्तर फेलओभर हो र एउटा स्थानान्तरणको थ्रुपुट अप्रासंगिक हुन्छ।
आवश्यकतालाई क्रियापद भएको एउटा वाक्यमा लेख्नुहोस्: एउटा ब्याकअप दोब्बर छिटो सकिन्छ, वा खसेको लिङ्कले सत्र अन्त्य गर्दैन। अस्पष्ट लक्ष्यहरूले कसैले स्वीकार वा अस्वीकार गर्न नसक्ने डिजाइन उत्पादन गर्छन्। त्यसपछि टाढाको छेउ के हुन सक्छ भनेर निर्णय गर्नुहोस्, किनकि सबैभन्दा सस्तो विकल्प प्रायः त्यही हुन्छ जसले त्यहाँ नयाँ केही माग्दैन। त्यो सीमाले पहिलो बैठकअघि नै ब्रोसरका अधिकांश दाबी हटाउँछ।
आवश्यकता कागजातमा तीनै वाचा छुट्टाछुट्टै राख्नुहोस्। तीनै दाबी गर्ने डिजाइनले सामान्यतया एउटा दिन्छ र बाँकी चुपचाप मान्छ। अर्को भागले वास्तवमा कुन दिइन्छ भनेर परीक्षण गर्छ।
एउटा स्थानान्तरण र धेरै परीक्षण गर्नुहोस्, त्यसपछि एउटा लिङ्क तान्नुहोस्
एउटा निरन्तर स्थानान्तरणलाई एउटै गन्तव्यतर्फका धेरै समानान्तर स्थानान्तरणसँग तुलना गर्नुहोस्, र प्रत्येकका लागि हानि, ढिलाइ र प्रति-लिङ्क प्रयोग रेकर्ड गर्नुहोस्। समानान्तर सत्रमा मात्र लाभ भए त्यसले प्रवाह वितरणतर्फ संकेत गर्छ, एउटा-प्रवाह एकत्रीकरणतर्फ होइन। एउटा अपलिंकको हानि छुट्टै परीक्षण गर्नुहोस्, किनकि दुवै लिङ्क चलिरहँदा क्षमताले स्थापित सत्रका लागि फेलओभरबारे केही भन्दैन। प्रत्येक परीक्षणअघि र पछि मार्ग, सकेट र पुनःपठन काउन्टर रेकर्ड गर्नुहोस्।
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5जब एउटै स्थानान्तरणले अझै एउटा अपलिंक प्रयोग गर्छ, डिजाइनले प्रवाह ह्यासले संकेत गरेको कुरा ठ्याक्कै गरिरहेको हुन्छ। जब समानान्तर स्थानान्तरण दुवैमा फैलिन्छन्, सन्तुलन चल्छ र एकत्रीकरण चल्दैन। डिजाइनले तीनमध्ये कुन वाचा साँच्चै पालन गर्छ रेकर्ड गर्नुहोस्, र अर्को क्षमता वार्ता विक्रेताको दाबीबाट होइन, प्रमाणबाट सुरु हुनेछ।