OpenVPN TUN અને TAP: નિર્ણય આપતી ત્રણ શરતો

બે ટનલ એક જ ફાઇલ ટ્રાન્સફર લઈ જઈ શકે છે અને તેમ છતાં વાયર પર મૂકવાની વસ્તુમાં સંપૂર્ણ અલગ હોઈ શકે છે. એક બે સરનામાં વચ્ચે IP પૅકેટ ખસેડે છે; બીજું Ethernet ફ્રેમ ખસેડે છે અને તેને સેગમેન્ટમાં બ્રિજ કરી શકાય છે. એ ફરક નક્કી કરે છે કે કઈ એપ્લિકેશન કામ કરશે, કયા ક્લાયન્ટ જોડાઈ શકશે અને તમે કેટલું નેટવર્ક ડિઝાઇન સ્વીકારશો.

વ્યવહારમાં ત્રણ શરતો આને નક્કી કરે છે. તેમને ક્રમમાં પાર પાડો, કારણ કે પહેલી શરત સામાન્ય રીતે ચર્ચા પૂરી કરી દે છે.

દરેક ઇન્ટરફેસ ખરેખર શું લઈ જાય છે

TUN ઉપકરણ લેયર-3 પોઇન્ટ-ટુ-પોઇન્ટ ઇન્ટરફેસ છે: કર્નલ તેને IP પૅકેટ આપે છે અને ટનલ તેમને પીઅર સરનામા સુધી લઈ જાય છે. TAP ઉપકરણ લેયર-2 ઇન્ટરફેસ છે જે Ethernet ફ્રેમ લઈ જાય છે, અને એ જ બ્રિજિંગને શક્ય બનાવે છે, જેમ કર્નલ દસ્તાવેજીકરણ વર્ણવે છે. બંનેમાંથી કોઈ પણ પેલોડ કેવી રીતે એન્ક્રિપ્ટ થાય છે તે બદલતું નથી, અને કોઈ પણ મજબૂતાઈનું સેટિંગ નથી. પસંદગી એ વિશે છે કે છેડાઓએ શું બદલવું પડે, એ વિશે નહીં કે ટ્રાફિક કેટલો સારી રીતે સુરક્ષિત છે.

એક પરિણામ તરત જ આવે છે: બંને છેડાએ સહમત થવું પડે. એક ઉપકરણ પ્રકાર માટે ગોઠવાયેલો ક્લાયન્ટ બીજા માટે ગોઠવાયેલા સર્વર સાથે જોડાઈ શકતો નથી, બાકીનું ભલે ગમે તે મળે.

શરત એક: શું કંઈને લેયર બેની જરૂર છે?

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

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

શરત બે: શું ક્લાયન્ટ આ કરી શકે છે?

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

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

શરત ત્રણ: શું આ ખરેખર ઇન્ટરફેસનો પ્રશ્ન છે?

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

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

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

પ્રશ્ન એ નથી કે કયો વિકલ્પ વધુ મજબૂત છે. પ્રશ્ન એ છે કે ટ્રાફિકને ખરેખર કયો જોઈએ છે.