રાઉટેડ કે બ્રિજ્ડ VPN: ક્લાયન્ટે શું પહોંચવું છે તેના આધારે પસંદ કરો

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

ટિકિટ ડેસ્ક પર એકસરખી દેખાતી બે વિનંતીઓ

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

આ જુદા પ્રશ્નો છે, અને બંનેનો જવાબ બ્રિજથી આપવો એ કર્મચારીની એક્સેસને કોઈ કારણ વગર આખા ઓફિસ LAN સુધી વિસ્તારે છે.

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

રૂટ LAN સભ્યપદ કરતાં સાંકડો છે

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

રૂટને પરવાનગી સાથે ભેળવશો નહીં. ક્લાયન્ટને સબનેટ સુધી કેવી રીતે પહોંચવું તે કહેવાથી તેને બીજું ગંતવ્ય અજમાવવાથી રોકાતું નથી.

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

બ્રિજ પ્રવેશનો પ્રશ્ન બદલે છે

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

કયા ઉપકરણો જોડાઈ શકે, કયા ફ્રેમ પ્રકાર પસાર થવા જોઈએ અને ક્યાં અનિચ્છનીય ક્રિયાપ્રતિક્રિયા અવરોધાય છે તે નક્કી કરો. સરનામાંકન અને DHCP સત્તા વિભાજિત નેટવર્કનો ભાગ બને છે, અને એક સેગમેન્ટ પર બે DHCP સર્વર તમે ધારો છો તે જ ગૂંચવણ ઊભી કરે છે.

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

ફિલ્ટરિંગ બંને ટોપોલોજીમાં છે

બ્રિજ સ્વભાવે અફિલ્ટરપાત્ર નથી, અને રૂટ સ્વભાવે સુરક્ષિત નથી. Linux બ્રિજ ફિલ્ટરિંગને તેના પોતાના હૂક અને પોતાની નિયમ-વાક્યરચના છે, અને રાઉટેડ IP ફોરવર્ડિંગ માટે લખાયેલો નિયમ બ્રિજ્ડ ફ્રેમ્સ પર આપમેળે લાગુ પડતો નથી.

સીમાનું વચન આપતા પહેલા પ્લેટફોર્મ ખરેખર શું સપોર્ટ કરે છે તે તપાસો:

bridge link show
nft list ruleset

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

ત્રણ પ્રયાસોથી સીમા સાબિત કરો

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

એક જ ક્લાયન્ટથી મંજૂર અને નકારેલા માર્ગ ચલાવો, અને બંને નોંધો:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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