શું બે સાઇટને સાઇટ VPN માટે સમાન VLAN ID ની જરૂર છે?
સમાન VLAN ID રાઉટેડ સાઇટ VPN ને સુધારી શકતા નથી: ટનલ IP પ્રીફિક્સ વહન કરે છે, તેથી પહોંચ નક્કી કરે છે એડ્રેસ પ્લાન અને સિલેક્ટર, સ્વિચ ટેગ નહીં.
બે ઓફિસમાં સમાન VLAN નંબર હોવાથી લાગે કે તે સાઇટ-થી-સાઇટ ટનલમાં મદદ કરશે, અને તે ટનલ જે વહન કરે છે તેમાં કંઈ બદલતું નથી. એક VLAN ID એક બિલ્ડિંગની અંદર Ethernet પ્રસારણ ડોમેનને ચિહ્નિત કરે છે; ટનલ ગેટવે વચ્ચે IP પેકેટ ફોરવર્ડ કરે છે. બે સાઇટ સંપૂર્ણપણે અલગ VLAN નંબરિંગ વાપરીને પણ એકબીજા તરફ રાઉટ કરી શકે છે, અને બે સાઇટ સમાન VLAN નંબરિંગ વાપરીને પણ એકબીજા સુધી પહોંચી શકતા નથી. પહોંચ નક્કી કરતો ચલ એ એડ્રેસ પ્લાન છે.
દંતકથા: બંને છેડે સમાન VLAN ID
આ માન્યતા વાજબી જગ્યાથી આવે છે. એક બિલ્ડિંગની અંદર, એક જ VLAN ના બે પોર્ટ વાત કરી શકે છે અને અલગ VLAN ના બે પોર્ટ નહીં, તેથી VLAN નંબર એવું લાગે છે જે કનેક્ટિવિટી આપે છે. રાઉટેડ ટનલની પાર ટેગ વર્ણવી શકે એવો કોઈ વિભાજિત Ethernet સેગમેન્ટ નથી, અને ગેટવે ક્યારેય VLAN લેબલની આપ-લે કરતા નથી.
ટનલને જે જોઈએ છે તે છે એકબીજા પર ઓવરલેપ ન કરતા બે એડ્રેસ સ્કોપ અને તેમની વચ્ચેના ટ્રાફિકને મંજૂરી આપતી નીતિ. કોઈપણ ઓફિસમાં VLAN બદલો અને ટનલ કામ કરતી રહે છે, કારણ કે ટનલ કન્ફિગરેશનમાં કંઈએ તેનો ઉલ્લેખ કર્યો ન હતો. આ જ પરીક્ષણ વિવાદનો નિર્ણય કરે છે: VLAN ફરી નંબર કરો, એડ્રેસ અકબંધ રાખો અને જુઓ ટનલ ટકે છે કે નહીં.
ઊલટું પરીક્ષણ પણ એટલું જ જાણકારીપૂર્ણ છે. બંને ઓફિસને સમાન સબનેટ આપો અને સમાન VLAN નંબર કેટલા પણ હોય, તે એડ્રેસને અસ્પષ્ટ રહેવા દેશે નહીં.
ટનલ ખરેખર શું વહન કરે છે
IPsec એડ્રેસ, પ્રોટોકોલ અને પોર્ટમાં વ્યક્ત નીતિ અનુસાર IP પેકેટનું રક્ષણ કરે છે. IPsec આર્કિટેક્ચર IP સ્તર પર તે સિલેક્ટરનું વર્ણન કરે છે, જે સ્વિચ ટેગ વર્ણવે છે તેના કરતાં ઘણા સ્તર ઉપર છે. જ્યારે પેકેટ ટનલમાં પ્રવેશે છે ત્યારે તે VLAN છોડી ચૂક્યું હોય છે; ટેગ સ્થાનિક સ્વિચ વાપરી લે છે.
નીતિ-આધારિત અને રૂટ-આધારિત ડિઝાઇન ટનલ કેવી રીતે પસંદ કરે છે તેમાં અલગ પડે છે, તેમાં નહીં કે શું વહન કરી શકે છે. નીતિ-આધારિત પીઅર ટ્રાફિક સિલેક્ટર મેળવે છે અને મેળ ખાતા પેકેટ ટનલમાં મોકલે છે. રૂટ-આધારિત પીઅર ટનલ ઇન્ટરફેસ પર ટ્રાફિક રાઉટ કરે છે અને નિર્ણય રાઉટિંગ ટેબલને સોંપે છે. બંને હજી રક્ષણ ક્ષેત્ર પર વાટાઘાટ કરે છે, તેથી ટનલ તરફ જતો રૂટ પીઅર જે રક્ષણ માટે સંમત થયા છે તેને વિસ્તારતો નથી.
આ ભેદ સામાન્ય અડધી નિષ્ફળતા સમજાવે છે: રૂટ અસ્તિત્વમાં છે, પેકેટ ટનલમાં પ્રવેશે છે, અને સામેનો છેડો તેમને કાઢી નાખે છે કારણ કે વાટાઘાટ કરેલા સિલેક્ટરમાં તે પ્રીફિક્સ ક્યારેય ન હતું. સ્થાપિત નીતિઓ વાંચવાથી ખબર પડે છે કે કયું ક્ષેત્ર ખરેખર અમલમાં આવ્યું.
ip xfrm policy
ip route show
swanctl --list-sasજે ઓવરલેપ ખરેખર તોડે છે
અલગ સબનેટવાળી બે ઓફિસ ટનલ દ્વારા સ્વચ્છ રીતે રાઉટ થાય છે, અને તેમના VLAN નંબર અપ્રસ્તુત છે. સમાન સબનેટવાળી બે ઓફિસ નહીં, કારણ કે આપેલા એડ્રેસની વિનંતીના બે શક્ય અર્થ હોય છે અને રાઉટિંગ ટેબલ ફક્ત એક જ પસંદ કરી શકે છે. એક સાઇટ ફરી નંબર કરવી એ સ્વચ્છ ઉકેલ છે, અને DNS તથા ફાયરવોલ ફેરફાર ગણતરીમાં લીધા પછી તે સામાન્ય રીતે વિકલ્પો કરતાં સસ્તું હોય છે.
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
જ્યારે ફરી નંબર કરવું અશક્ય હોય, ત્યારે ઇરાદાપૂર્વકની અનુવાદ ડિઝાઇન દરેક બાજુને અલગ એડ્રેસ દૃશ્ય આપી શકે છે. તેનો અર્થ એક-થી-એક મેપિંગ, મેળ ખાતા સિલેક્ટર, અનુવાદિત દૃશ્ય પ્રતિબિંબિત કરતી DNS એન્ટ્રી અને ફરીથી લખાણ સહન કરતું પરત રાઉટિંગ. તે વાસ્તવિક કાર્યાત્મક ખર્ચ સાથેની સમર્થિત ડિઝાઇન છે, અને VLAN ID બદલવાથી જે થાય છે તે આ નથી.
બંને છેડે સમાન VLAN નંબર ક્યારેક સહિયારા ટેમ્પલેટનો સંયોગ હોય છે, અને તે સંયોગને કાર્યકારી ટનલનું કારણ ગણવાથી પછી કંઈ તૂટે ત્યારે ખોટો ફેરફાર થાય છે.
દરેક સ્તર માટે એક કામ, લેખિતમાં
સ્થાનિક સ્વિચ નક્કી કરે છે કે કયા પોર્ટ પ્રસારણ ડોમેન વહેંચે છે, અને તેનું VLAN નંબરિંગ સ્થાનિક હિસાબ છે જે બીજી કોઈ સાઇટને જાણવાની જરૂર નથી. ગેટવે પીઅરને પ્રમાણિત કરે છે અને વાટાઘાટ કરેલા રક્ષણ ક્ષેત્રને લાગુ કરે છે. રાઉટિંગ ટેબલ નક્કી કરે છે કે ડિક્રિપ્ટ થયેલું પેકેટ આગળ ક્યાં જશે, અને એક્સેસ નીતિ નક્કી કરે છે કે તે પેકેટને બિલકુલ મંજૂરી હોવી જોઈતી હતી કે નહીં.
આ કામો અલગ રાખવાથી જ ફેરફાર સલામત બને છે. એક ઓફિસમાં VLAN ફરી નંબર કરવાથી સ્થાનિક સ્વિચ, DHCP સ્કોપ અને કદાચ ફાયરવોલ ઝોનને અડે છે, અને ટનલને અડતું નથી. પ્રીફિક્સ ફેરફાર ટનલ સિલેક્ટર, બંને બાજુના રૂટ અને એક્સેસ નીતિને અડે છે, અને સ્વિચ ટેગને અડતો નથી.
પરત રૂટ, ખાનગી DNS અને એપ્લિકેશન ઓળખની જરૂરિયાત ફરી અલગ કામ છે, અને તેમાંથી કોઈ પણ બીજી સાઇટથી VLAN નંબર કોપી કરીને આવતું નથી. જે ડિઝાઇન દસ્તાવેજ પહોંચી શકાય તેવા પ્રીફિક્સ અને મંજૂર સેવાઓની સૂચિ આપે છે તે સ્વિચ બદલાવ પછી પણ ટકે છે; જે VLAN નંબરની સૂચિ આપે છે તે ટકતું નથી.
ટેગ ટનલ સુધી પહોંચે છે એમ માની લેતા પહેલાં બ્રિજ સાધનોથી સ્થાનિક ચિત્રની પુષ્ટિ કરો.
bridge vlan show
ip -br addr
ip route get 10.62.0.20જ્યારે layer-2 વિસ્તરણ જ ખરી જરૂરિયાત હોય
કેટલીક ડિઝાઇનને સાઇટો વચ્ચે ખરેખર Ethernet વર્તનની જરૂર હોય છે: પ્રસારણ શોધ પર આધારિત જૂની એપ્લિકેશન, મશીન ખસે ત્યારે એડ્રેસ જાળવવો પડે એવું સ્થળાંતર, અથવા layer-2 ધારણાઓ સમાવતો પ્રોટોકોલ. આવા કિસ્સાઓને ફ્રેમ વહન કરતું ઓવરલે અથવા બ્રિજ્ડ સેવા જોઈએ, અને પછી VLAN સદસ્યતા, લૂપ અટકાવ અને નિષ્ફળતા સંભાળ એન્ડ-ટુ-એન્ડ બાબતો બને છે.
તે ઘણું મોટું નિષ્ફળતા ક્ષેત્ર છે, અને ફાઇલ શેરિંગ ચાલુ કરવાના પ્રયાસનું આકસ્મિક પરિણામ નહીં, સભાન પસંદગી હોવી જોઈએ. સામાન્ય ફાઇલ સર્વર, ડેટાબેઝ કે વેબ એપ્લિકેશનને અધિકૃત IP માર્ગ જોઈએ છે, અને તેની નીચે ખેંચાયેલા પ્રસારણ ડોમેન વિના તે વધુ સુખી રહેશે.
VPN કરારને પહોંચી શકાય તેવા પ્રીફિક્સ અને મંજૂર સેવાઓ તરીકે લખો, અને VLAN લેબલ ફક્ત ત્યાં નોંધો જ્યાં સ્થાનિક કામગીરીને તેની જરૂર હોય. પછી દરેક ઓફિસ દરેક ફેરફારને ટનલ પુનઃરચનામાં ન બદલીને પોતાનું સ્વિચિંગ ફરી નંબર કરી શકે છે.