શાખા અને પ્રયોગશાળા વચ્ચેની કડી માટે રાઉટેડ VPN કે બ્રિજ્ડ LAN

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

જોડવાની બે રીત, એક સ્પષ્ટ સમાધાન

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

બ્રિજ્ડ કડી એક જ લેયર 2 ડોમેન બંને સાઇટ પર ફેલાવે છે. શોધ પ્રોટોકોલ કામ કરે છે, ઉપકરણો જાતે દેખાવા લાગે છે, અને દરેક બ્રોડકાસ્ટ, દરેક ARP વિનંતી અને દરેક multicast પેકેટ હવે ટનલ પાર કરવાનો ઉમેદવાર છે, એટલે કે મોટા પ્રમાણમાં ટ્રાફિક જે સ્થાનિક સેગમેન્ટ માટે બનેલા પ્રોટોકોલ વહન કરે છે, અલગ MTU અને બદલાતા રાઉન્ડ-ટ્રિપ સમયવાળા WAN માટે નહીં.

રાઉટિંગ તમને શું આપે છે

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

ત્રીજો એ છે કે તે ટનલ ખરેખર શું વહન કરે છે તેની સાથે મેળ ખાય છે. IPsec નીતિ પ્રીફિક્સની જોડી છે, અને દરેક બાજુ ફોરવર્ડિંગનો માર્ગ ગેટવે પર ફોરવર્ડિંગ ચાલુ કરીને સામાન્ય IP રાઉટિંગ છે:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

તમે જે છોડો છો તે બ્રોડકાસ્ટ દ્વારા શોધ છે. આ સાચું નુકસાન છે અને બધું બ્રિજ કરીને ટાળવાને બદલે જાણી જોઈને બદલવું જોઈએ.

બ્રિજિંગનો ખર્ચ

બ્રિજિંગે લેયર 2 ફ્રેમ ટનલમાંથી વહન કરવા પડે છે, એટલે કે સાદા નીતિ-આધારિત ટનલને બદલે IPsec ઉપર GRE કે VXLAN જેવું એન્કેપ્સ્યુલેશન. જેવું આ અસ્તિત્વમાં આવે, બંને સાઇટ એક જ નિષ્ફળતા ડોમેન વહેંચે છે. Spanning tree ટનલને કડી ગણે છે, બ્રોડકાસ્ટ ટ્રાફિક ટનલની બેન્ડવિડ્થ ખાય છે, અને જે પણ ઉપકરણ ઓછા વિલંબવાળા સેગમેન્ટને ધારી લે છે તે એવી રીતે ખોટું વર્તે છે જેને કોઈ પણ છેડેથી જોડવું મુશ્કેલ છે.

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

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

બ્રોડકાસ્ટ વગર નામો

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

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

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

રાઉટેડ ડિઝાઇન ચકાસી શકાય તેવી બનાવો

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

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

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