એક TAP સર્વર કે ઘણા? બ્રિજ પર OpenVPN ક્લાયન્ટ

ઘણા TAP ક્લાયન્ટને દરેક માટે એક સર્વર પ્રોસેસ, એક UDP પોર્ટ અને હોસ્ટ પર એક TAP ઉપકરણની જરૂર નથી. ઇથરનેટ મોડમાં એક OpenVPN સર્વર ઘણા પ્રમાણીત ક્લાયન્ટ સ્વીકારી શકે છે અને તેમને એક જ બ્રિજ સાથે જોડી શકે છે, અને સ્તર 2 ના સેગમેન્ટને વિસ્તારવાની આ જ દસ્તાવેજી પદ્ધતિ છે. એક-પ્રોસેસ ડિઝાઇન એ છે જે મેન્યુઅલ દસ્તાવેજીકૃત કરે છે, અને સામાન્ય રીતે તે જ યોગ્ય ડિફોલ્ટ છે.

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

બે આર્કિટેક્ચર, બે સેટિંગ નહીં

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

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

તેથી સરખામણી એ વિશે છે કે ક્લાયન્ટને ક્યાં પહોંચવું છે, પ્રદર્શન વિશે નહીં. પહેલાં સ્તર પસંદ કરો, પછી નક્કી કરો કે કેટલી પ્રોસેસ તેની સેવા કરશે.

server-bridge સહાયક શું કરે છે

server-bridge સહાયક બહુ-ક્લાયન્ટ ઇથરનેટ મોડ ગોઠવે છે. તેનું સરનામા-પૂલ સ્વરૂપ ગેટવે, નેટમાસ્ક અને બ્રિજ્ડ સબનેટની અંદરની સમર્પિત શ્રેણી લે છે, ઉદાહરણ તરીકે 192.168.50.1 પર ગેટવે અને 192.168.50.160 થી 192.168.50.199 સુધીનો પૂલ.

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

એવા ડિપ્લોયમેન્ટ માટે DHCP-પ્રોક્સી સ્વરૂપ છે જ્યાં બાહ્ય સર્વર સરનામાં આપે છે. તેની પોતાની પૂર્વશરતો છે, અને બંને સ્વરૂપ મિશ્ર કરવાથી દસ્તાવેજ જે સંઘર્ષની ચેતવણી આપે છે તે જ ઊભો થાય છે. બ્રિજ્ડ સબનેટ માટે એક જ ફાળવનાર પસંદ કરો.

અલગીકરણ પ્રોસેસની સંખ્યામાંથી આવતું નથી

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

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

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

ક્યારે ઘણી પ્રોસેસ હજી યોગ્ય છે

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

જો ઘણી વાપરો તો દરેકને પોતાનું શ્રોતા અને ઉપકરણ-માલિકી આપો અને સરનામા શ્રેણીઓનું સંકલન કરો. જે બંને સર્વર માને છે કે એ જ બ્રિજ પર એ જ પૂલ તેમનો છે, તે આખરે એ જ સરનામું આપશે.

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

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