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

VLAN-જાણકાર મોડ ખરેખર શું બનાવે છે

ફક્ત સર્વર માટેના TAP ડિપ્લોયમેન્ટમાં vlan-tagging સક્રિય હોય ત્યારે ડિમન તેના TAP ઉપકરણ અને દરેક જોડાયેલા ક્લાયન્ટને આંતરિક સ્વિચના પોર્ટ તરીકે મોડેલ કરે છે. ક્લાયન્ટ પોર્ટ ટેગ વગરના હોય છે, અને તેમનું VLAN જોડાણ સર્વર પર દરેક ક્લાયન્ટના vlan-pvid સંદર્ભ દ્વારા સેટ થાય છે, ક્લાયન્ટ મોકલે છે તેનાથી નહીં. મોડેલનો આખો મુદ્દો આ જ છે: સભ્યપદ એ પ્રમાણિત સહભાગી વિશે સર્વર તરફથી લેવાયેલો નિર્ણય છે. ક્લાયન્ટ પ્રોફાઇલમાં કંઈપણ જાણવાની જરૂર નથી કે તે કયા VLANમાં આવે છે.

સર્વરની TAP બાજુ vlan-accept દ્વારા પોતાની ટેગ કરેલી કે ટેગ વગરની સ્વીકૃતિ નીતિ મેળવે છે. તે સ્વિચમાં આગળ મોકલવાનું ફક્ત મેળ ખાતા VID વચ્ચે જ થાય છે, client-to-client સેટ હોય ત્યારે પણ, તેથી જુદા જુદા VLANના બે ક્લાયન્ટ સર્વર દ્વારા એકબીજા સુધી પહોંચી શકતા નથી, જોકે બંને તેની સાથે જોડાયેલા છે.

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

સોંપણીઓ પ્રમાણિત ક્લાયન્ટ ઓળખને અનુસરવી જોઈએ, ક્લાયન્ટ પોતાના વિશે આપે છે તે મૂલ્યને નહીં. બાકી રહેલી સોંપણી ક્વોરેન્ટાઇન સ્થિતિ પણ નથી: ક્લાયન્ટ મૂળભૂત PVID પર પહોંચે છે, તેથી ખૂટતી ccd એન્ટ્રી શાંત નીતિ-નિર્ણય છે, તટસ્થ નહીં.

ટ્રાન્સપરન્ટ ટ્રંક તેના બદલે શું માંગે છે

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

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

ફ્રેમની સાઇઝને પોતાનું બજેટ જોઈએ. ટેગ કરેલી ઈથરનેટ ફ્રેમ અને એન્કેપ્સ્યુલેશન માર્ગદર્શિકામાંથી કોપી કરેલા પેલોડ આંકડા કરતાં મોટા હોય છે, અને રાઉટેડ ટનલ માટે યોગ્ય રહેલું MTU એ ટ્રંક માર્ગ કામ કરે છે તેનો પુરાવો નથી.

જવાબ નક્કી કરતી ત્રણ શરતો

પ્રથમ, ક્લાયન્ટ પ્લેટફોર્મ TAP ને સમર્થન આપે છે ખરું? Android અને iOS આપતા નથી, અને macOSનું સમર્થન મર્યાદિત છે, તેથી મોબાઇલ વપરાશકર્તાઓનો કાફલો VLAN કેવી રીતે ગોઠવાયા હોય તે ધ્યાનમાં લીધા વિના બંને TAP ડિઝાઇનને બાદ કરે છે. રાઉટેડ TUN સત્ર IP પેકેટ લઈ જાય છે, ઈથરનેટ ફ્રેમ નહીં, અને સર્વર બાજુનું કોઈપણ VLAN ગોઠવણ તેને બદલતું નથી. ટોપોલોજી ડિઝાઇન કરતાં પહેલાં કાફલો તપાસો, કારણ કે આ શરત ટાળી શકાતી નથી. સ્વિચનું કામ પૂરું થયા પછી સૌથી વધુ વાર મળી આવતી શરત પણ આ જ છે.

બીજું, VLAN કોણ સોંપે છે? જવાબ «સર્વર, કોણ પ્રમાણિત થયું તેના આધારે» હોય તો સ્વિચ મોડેલ યોગ્ય છે. જવાબ «હાલનું સ્વિચ માળખું, પહેલેથી હયાત ટેગ સાથે» હોય તો તમને ટ્રંક ડિઝાઇનની જરૂર છે.

ત્રીજું, નેટવર્કનો કેટલો ભાગ પહોંચી શકાય તેવો હોવો જોઈએ? સ્વિચ મોડેલ રચનાથી જ દરેક ક્લાયન્ટને એક VLANમાં રાખે છે. ટ્રંક ડિઝાઇન બ્રિજ છે, અને ખોટી ગોઠવાયેલી બ્રિજ એવા બ્રોડકાસ્ટ ડોમેન જોડે છે જે અલગ રહેવાના હતા.

તમે કરેલી પસંદગીની કસોટી

એક ક્લાયન્ટ જોડો જે માન્ય VLANમાં હોવો જોઈએ અને એક જે ન હોવો જોઈએ, પછી સર્વર પરથી નહીં, ખરા છેડા પરથી પરીક્ષણ કરો. સર્વર બાજુની પહોંચ સાબિત કરે છે કે બ્રિજ કે સ્વિચ છે; તે સાબિત કરતું નથી કે ક્લાયન્ટ કયા VLANમાં પહોંચ્યો.

ip -d link show tap0
bridge vlan show

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

ડિપ્લોયમેન્ટ બેમાંથી કઈ ડિઝાઇન વાપરે છે તે નોંધો. «VLAN-જાણકાર» કહેતી નોંધ અસ્પષ્ટ છે, અને પછીનો ઇજનેર પહેલાં શીખેલી ડિઝાઇન ધારી લેશે. OpenVPN VLAN સંદર્ભસ્વિચનું વર્તન અને દરેક ક્લાયન્ટનો સંદર્ભ વ્યાખ્યાયિત કરે છે, અને તમે કયું મોડેલ ચલાવો છો તેની પુષ્ટિ કરવાનો સૌથી ટૂંકો માર્ગ એ છે.

સંબંધિત લેખો