અનેક માર્ગો પર VPN: વાહકે આપવાની ચાર બાંયધરી

બીજી WAN લિંક ઉમેરો અને ટનલ ઉપર આવે છે, તો પણ એક માર્ગ ડગમગે ત્યારે ફાઇલ નકલ અટકી જાય છે. લિંક સ્વસ્થ છે અને VPN પ્રક્રિયાઓ ચાલી રહી છે; જે ખૂટે છે તે વાહક અને ટનલ વચ્ચેનો કરાર છે. ઘણા સોકેટ આપમેળે એક જોડાણ જેવા વર્તતા નથી, અને તેમની ઉપરની એપ્લિકેશન ડિલિવરી તૂટે ત્યાં સુધી ફરક જોઈ શકતી નથી. કરારનો દરેક ભાગ એવી નિષ્ફળતા સાથે મેળ ખાય છે જે તમે ચકાસી શકો, અને એ જ તેને ઉપયોગી બનાવે છે.

ઉત્પાદન પસંદ કરતા પહેલા એ કરાર લખો. તેના ચાર ભાગ છે: VPN જે સ્ટ્રીમ મેળવે છે, વાહક ખૂટતો ડેટા કેવી રીતે પુનઃપ્રાપ્ત કરે છે, કઈ એન્ડપોઇન્ટ ઓળખ માર્ગ બદલાવમાં ટકે છે, અને માર્ગ નિષ્ફળ થાય ત્યારે આખી સિસ્ટમ કેવી રીતે વર્તે છે.

લક્ષણ: લિંક ચાલુ છે, સત્ર તો પણ તૂટે છે

બંને લિંક ચાલુ દર્શાવતો મોનિટરિંગ ગ્રાફ ફક્ત એ સાબિત કરે છે કે દરેક માર્ગ ટ્રાફિક વહન કરી શકે છે. તે સાબિત કરતો નથી કે VPN એક ક્રમબદ્ધ સ્ટ્રીમ જુએ છે, કે એક માર્ગ પર ખોવાયેલો પેકેટ બીજા પર પુનઃપ્રાપ્ત થાય છે, અથવા સાથી હજુ પણ જાણે છે કે કયા સત્ર સાથે વાત થઈ રહી છે. કરારનો બાકીનો ભાગ ગ્રાફ ન દર્શાવી શકે તે આવરી લે છે.

જ્યારે સ્થાનાંતરણ અટકે, ત્યારે શોધો કે વાહકે બચેલા માર્ગ પર ડિલિવરી ચાલુ રાખી કે નહીં. જો બીજી લિંક નિષ્ક્રિય હોય ત્યારે સત્ર મરે, તો વાહકે તેનો કદી ઉપયોગ કર્યો નથી. જો સત્ર ટકે પણ ડેટા ક્રમ વગરનો કે બેવડો આવે, તો વાહક જોડાણ-સ્તરના કરાર વિના પેકેટ ખસેડી રહ્યો છે. બંને બાજુના સમયચિહ્નો સામાન્ય રીતે આ સ્પષ્ટ કરે છે.

એ જ ફરક ઉપાય નક્કી કરે છે. રૂટિંગ કે નીતિની સમસ્યાને માર્ગ-પસંદગી બદલવાની જરૂર છે; ખૂટતા ક્રમ અને પુનઃપ્રાપ્તિ સ્તરને બીજું પરિવહન જોઈએ, મોટું બફર નહીં.

પ્રથમ બાંયધરી: જોડાણ-સ્તરે બાઇટ સ્ટ્રીમ

જો VPN ને વિશ્વસનીય ક્રમબદ્ધ સ્ટ્રીમ જોઈએ, તો વાહકે વ્યક્તિગત માર્ગની ઉપર બાઇટ શ્રેણીઓ ઓળખવી પડશે. દરેક આધારભૂત TCP જોડાણ ફક્ત પોતાના સેગમેન્ટની સંખ્યા કરે છે, તેથી પ્રાપ્તકર્તા ફક્ત તે સંખ્યાઓથી માર્ગો વચ્ચે પુનર્વ્યવસ્થા કરી શકતો નથી.

Multipath TCP પ્રમાણભૂત ઉદાહરણ છે. તે એક વિશ્વસનીય બાઇટ સ્ટ્રીમ રજૂ કરતી વખતે ઘણા TCP ઉપસ્ટ્રીમનું સમન્વયન કરે છે, ડેટા-સ્તરના ક્રમ મેપિંગ અને સ્વીકૃતિ સાથે. એપ્લિકેશન સ્ટ્રીમ વાંચે છે, તે ઉપસ્ટ્રીમ નહીં જેણે સંજોગવશાત પહેલું ટુકડું આપ્યું.

Linux પર MPTCP દરેક સોકેટ માટે IPPROTO_MPTCP દ્વારા opt-in છે. જ્યારે વાટાઘાટો બહુમાર્ગી વર્તન વાપરી શકતી નથી, દસ્તાવેજીકૃત વિકલ્પ સામાન્ય TCP છે, એટલે કે એપ્લિકેશન બીજા માર્ગનો કદી ઉપયોગ કર્યા વિના એક માર્ગ પર ચાલુ રાખી શકે છે. કર્નલ સેટિંગ લાગુ પડી હોવાનું ધારવાને બદલે તૈનાત સોકેટે ખરેખર કયું વર્તન નક્કી કર્યું તે તપાસો.

બીજી બાંયધરી: ક્રમ, બેવડાવ અને પુનઃપ્રાપ્તિ

વિવિધ વિલંબ અને નુકસાન-દર ધરાવતા માર્ગો વાહકને બફરિંગ, પુનર્વ્યવસ્થા અને પુનઃપ્રેષણ માટે મજબૂર કરે છે. કરારે જણાવવું પડશે કે કેટલું બફરિંગ માન્ય છે, એપ્લિકેશન કયું પ્રતિદબાણ જુએ છે, અને કયો માર્ગ પુનઃપ્રેષણ વહે છે.

જોડાયેલો રહીને ડિલિવરી બંધ કરતો માર્ગ સ્વચ્છ બંધ થવા કરતાં અઘરો છે. વાહકે તેને ઓળખવો, બાકીનો ડેટા ખસેડવો અને કદી ન આવતા સેગમેન્ટની અનંત રાહ ન જોવી જોઈએ. બંને લિંક ચાલુ છે તેની સાદી ચકાસણી આ સ્થિતિ આવરી લેતી નથી.

બેવડાવને પોતાનો નિયમ જોઈએ. એક જ પેલોડ બંને માર્ગો પર મોકલવાથી વિલંબ સુધરી શકે છે, પણ પ્રાપ્તકર્તાએ નકલ VPN સુધી પહોંચે તે પહેલાં દબાવી દેવી પડશે. IPsec anti-replay દરેક સુરક્ષા-સંલગ્નતા માટે વૈકલ્પિક છે અને ક્રમ-સંખ્યાઓ ચકાસે છે; પેકેટ પુનર્વ્યવસ્થિત કે પુનઃવગાડતું બેવડાવ સ્તર તેને સક્રિય કરી શકે છે અથવા ટનલ પડે ત્યાં સુધી સમસ્યા છુપાવી શકે છે.

ત્રીજી બાંયધરી: એન્ડપોઇન્ટ ઓળખ અને માર્ગનો સમાવેશ

સાથીને નવો માર્ગ દેખાય ત્યારે સત્ર ઓળખવાની સ્થિર રીત જોઈએ. જો દરેક માર્ગ અલગ ટનલ તરીકે પ્રમાણિત થાય, તો VPN એકને બદલે બે સત્ર જોઈ શકે છે. જો વાહક માર્ગોને એક સત્ર હેઠળ જોડે, તો નવો માર્ગ કેવી રીતે પ્રમાણિત થાય અને જૂનાનું શું થાય તે નક્કી કરવું પડશે.

નોંધો કે કયા સરનામાં અને ઓળખકર્તા સ્થિર રહે છે: ટનલનો એન્ડપોઇન્ટ, વાહકનો સત્ર ઓળખકર્તા અને વચ્ચેનો કોઈપણ પ્રોક્સી. પ્રોક્સી ઉપલબ્ધતા અને વિશ્વાસની બીજી સીમા ઉમેરે છે, જ્યારે તે સુરક્ષિત પેલોડ કદી ન જુએ ત્યારે પણ.

નીતિ પણ અહીં જ રહે છે. અણધાર્યા નેટવર્કથી જોડાતો માર્ગ ટેકનિકલી માન્ય હોઈ શકે અને તેમ છતાં ઇચ્છિત વિશ્વાસ-મોડલનું ઉલ્લંઘન કરી શકે. નક્કી કરો કે નવા માર્ગ આપમેળે સ્વીકારાય છે, પ્રમાણીકરણ માંગે છે કે નકારાય છે.

ચોથી બાંયધરી: નિષ્ફળતા હેઠળ મર્યાદિત વર્તન

માર્ગની સંપૂર્ણ નિષ્ફળતા ચકાસો, ફક્ત ધીમો માર્ગ નહીં. બચેલા માર્ગે સત્ર અમર્યાદિત મેમરી વૃદ્ધિ વિના ઉપાડવું જોઈએ, અને પુનઃપ્રાપ્તિ એપ્લિકેશન સહન કરી શકે તેનાથી લાંબા ટાઇમર પર આધારિત ન હોવી જોઈએ. નિષ્ફળ માર્ગ પાછો આવે ત્યારે વાહકે પુનઃસંતુલન કરવું કે પ્રવાહ જ્યાં છે ત્યાં રાખવું તે નક્કી કરવું પડશે.

બફરિંગ, પુનઃપ્રેષણ અને માર્ગ-સંખ્યાની મર્યાદા નક્કી કરો, પછી તેમને નુકસાન, પુનર્વ્યવસ્થા, બેવડાવ અને વિલંબ-અસંતુલન હેઠળ ચકાસો. કુલ બેન્ડવિડ્થ અહીં સૌથી ઓછી રસપ્રદ સંખ્યા છે; ડિલિવરીની સાતત્ય અને મેમરી મર્યાદા જ કરાર છે.

વાહકની પુનઃપ્રાપ્તિ સ્થિતિને VPN ની ક્રિપ્ટોગ્રાફિક સ્થિતિથી અલગ રાખો. સ્થાપિત પ્રમાણીકરણ કે એન્ક્રિપ્શનની જગ્યા લેતો પોતાનો વિશ્વસનીયતા સ્તર કોઈ શોર્ટકટ નથી, અને સ્તરો વચ્ચે ક્રમ-સંખ્યાઓનો પુનરુપયોગ replay સુરક્ષા અને નિદાનને અવિશ્વસનીય બનાવે છે.

વાહકને પરીક્ષણ યોજના સાથે સ્વીકારો

ચારેય બાંયધરી પાસ કે ફેલ ચકાસણી તરીકે લખો: એક ક્રમબદ્ધ સ્ટ્રીમ, નિર્ધારિત પુનઃપ્રાપ્તિ, સ્થિર સત્ર ઓળખ, મર્યાદિત નિષ્ફળતા વર્તન. દરેક ચકાસણી એક માર્ગ નબળો અને પછી એક માર્ગ દૂર કરીને ચલાવો.

માર્ગ બદલતી વખતે એક સફળ ફાઇલ સ્થાનાંતરણ સતત કામગીરી સાબિત કરતું નથી. પસંદગીના માર્ગને બદલતાં સ્થાનાંતરણ પુનરાવર્તિત કરો, અને વાહકનું દૃશ્ય તથા VPN ના પોતાના કાઉન્ટર બંને તપાસો. ડેટા કયા માર્ગે ગયો તે અંગે બંને સહમત ન હોય, તો કરાર હજુ અવલોકનયોગ્ય નથી.

મંજૂર મેટ્રિક્સ તૈનાતી સાથે રાખો. તે આગલા એન્જિનિયરને કહે છે કે કયું વર્તન વચન આપ્યું હતું, માર્ગોના કયા સંયોજન ચકાસાયા અને કઈ નિષ્ફળતા પદ્ધતિ હજુ અસમર્થિત છે, લિંક-સ્થિતિ દીવાઓ પરથી નવું અનુમાન કર્યા વિના.