ESXi ગેસ્ટ VPN: રૂટિંગ કે બ્રિજિંગ — પોર્ટ ગ્રુપ પહેલાં નિર્ણય લો
રૂટેડ TUN ને પરત રૂટ જોઈએ; બ્રિજ્ડ TAP ને લેયર 2 પહોંચ અને વધુ પહોળી પોર્ટ-ગ્રુપ નીતિ જોઈએ. promiscuous મોડ વિસ્તારતાં પહેલાં ભૂમિકા નક્કી કરો.
પેકેટ રૂટ કરો અથવા Ethernet ડોમેન વિસ્તારો: પોર્ટ ગ્રુપનો ફેરફાર તે પસંદગી પછી આવે છે. ખાનગી સરનામું ધરાવતી એપ્લિકેશનમાંથી પરિણામો સરખા દેખાઈ શકે છે, જ્યારે હાઇપરવાઇઝરની જરૂરિયાતો સાવ અલગ હોય છે. તેથી પહેલાં પોર્ટ ગ્રુપ પહોળું કરવામાં આવે છે અને ડિઝાઇનનો પ્રશ્ન પછી જવાબ પામે છે, સામાન્ય રીતે બ્રોડકાસ્ટ વાવાઝોડા પછી. આ તપાસો ક્રમમાં કરો અને જ્યાં સુધી જરૂરિયાત અસ્પષ્ટ છે ત્યાં સુધી થોભો, કારણ કે કોઈ પણ પોર્ટ-ગ્રુપ સેટિંગ એવી ડિઝાઇન સુધારતું નથી જે કદી પસંદ જ કરવામાં આવી ન હોય.
નિર્ણય સેવાના માલિકનો છે; હાઇપરવાઇઝર રૂપરેખાંકને તેનો અમલ કરવો જોઈએ, આકસ્મિક રીતે તેને નક્કી ન કરવું.
દૂરનું છેડું ખરેખર શું જોઈએ છે તે તપાસો
દૂરના ક્લાયન્ટે પહોંચવાની સેવાઓ અને તેઓ વાપરતા પ્રોટોકોલની યાદી બનાવો. જો યાદી જાણીતા પ્રીફિક્સ પરની થોડી TCP સેવાઓ હોય, તો રૂટિંગ પૂરતું છે. જો કોઈને ખરેખર લેયર 2 નિકટતા જોઈએ — બ્રોડકાસ્ટ-આધારિત શોધ, બિન-IP પ્રોટોકોલ, ગેટવે ન સ્વીકારતું ઉપકરણ — તો રૂટિંગ તેની નકલ કરી શકતું નથી અને તે વહેલું કહેવું જોઈએ. તે યાદીમાંની બિન-IP એન્ટ્રીઓ વિશે પ્રામાણિક રહો, કારણ કે ત્યાં જ રૂટેડ ડિઝાઇન એક અઠવાડિયા પછી ચુપચાપ નિષ્ફળ જાય છે.
પછી ક્લાયન્ટ પૂલ તપાસો. રૂટેડ ડિઝાઇનને સરનામાંની શ્રેણી અને દૂરના છેડે સ્પષ્ટ પરત રૂટ જોઈએ; બ્રિજ્ડ ડિઝાઇનને વિસ્તરેલા Ethernet ડોમેન પાસે સરનામાં ફાળવણી અને અલગતા હોવી જોઈએ. તમે જે પણ પસંદ કરો, આ VM ની બહારના કોઈએ તેને સ્વીકારવું પડશે.
દરેક ડિઝાઇન વર્ચ્યુઅલ નેટવર્ક પાસેથી શું માગે છે
બંને ડિઝાઇન વર્ચ્યુઅલ નેટવર્કે શું સહન કરવું પડે તેમાં અલગ પડે છે, અને કોષ્ટક તે જોવાનો સૌથી ટૂંકો રસ્તો છે:
| ડિઝાઇન | ગેસ્ટ બાજુની ભૂમિકા | વર્ચ્યુઅલ નેટવર્કે શું સમાવવું પડે | ખોટું પસંદ કરો તો નિષ્ફળતાનો પ્રકાર |
|---|---|---|---|
| રૂટેડ TUN | અલગ પ્રીફિક્સ વચ્ચે રાઉટર | રૂટેડ ક્લાયન્ટ પૂલ અને દૂરના છેડે પરત માર્ગો | ક્લાયન્ટ ગેટવે સુધી પહોંચે છે અને તેની પાછળની સેવા સુધી કદી પહોંચતા નથી |
| બ્રિજ્ડ TAP | જોડાતા ક્લાયન્ટ માટે લેયર 2 બ્રિજ | વધારાની Ethernet ઓળખ, બ્રોડકાસ્ટ ટ્રાફિક અને VLAN નિયમો | vSwitch ફ્રેમ છોડી દે છે, અથવા ડિઝાઇનને એવો promiscuous મોડ જોઈએ જે કોઈએ મંજૂર કર્યો નથી |
રૂટિંગ બ્રોડકાસ્ટ ડોમેનને જ્યાં છે ત્યાં રાખે છે અને ગેટવે કઈ સેવાઓ ઓળંગે તે મર્યાદિત કરવાની કુદરતી જગ્યા આપે છે. બ્રિજિંગ સીમા ખસેડે છે: ક્લાયન્ટ વિસ્તરેલા Ethernet ડોમેનના સહભાગી બને છે, અને સરનામાં ફાળવણી, અલગતા તથા કોઈપણ લેયર 2 નીતિ હવે તેમને લાગુ પડે છે. પસંદ કરેલી પંક્તિ ફેરફાર-રેકોર્ડમાં લખો. “રૂટેડ TUN, ક્લાયન્ટ પૂલ 10.90.0.0/24, કોર પર પરત રૂટ” જેવું વાક્ય આગલા ઇજનેરને પોર્ટ-ગ્રુપ સેટિંગ્સથી ડિઝાઇન ફરી ચર્ચવાથી રોકે છે.
કોના ફ્રેમ કોણ જોઈ શકે
પોર્ટ ગ્રુપને અડકતાં પહેલાં પ્લેટફોર્મ માલિકને એક પ્રશ્ન પૂછો: શું ડિઝાઇન માગે છે કે આ VM અન્ય સહભાગીઓને સંબોધિત ફ્રેમ મેળવે? જવાબ ના હોય તો આ વિભાગનું કંઈ લાગુ પડતું નથી, કારણ કે રૂટેડ TUN ને એ દૃશ્યતા કદી જોઈતી નથી. જવાબ હા હોય તો, promiscuous મોડ વિશે Broadcom નું માર્ગદર્શન એ મુખ્ય વાંચન છે: તે જણાવે છે કે VM vSwitch માંથી કેટલું વધુ જોઈ શકે છે અને એ નીતિને એક પોર્ટ ગ્રુપ સુધી સીમિત રાખવાની સલાહ આપે છે.
આને પરવાનગી નહીં, જરૂરિયાત-તપાસ તરીકે લો. બ્રિજિંગની જરૂર લખાયેલી હોય ત્યારે એક સમર્પિત જોડાણ માટે સેટિંગ ચાલુ કરો, અને બાકી બધે બંધ રાખો. બીજા બ્રિજ ઉદાહરણમાંથી નકલ કરેલો પહોળો VLAN ટ્રંક એ ભાગ છે જે દૂર કરવાનું કોઈને યાદ રહેતું નથી, અને એક-VLAN ડિઝાઇન એક-VLAN જ રહેવી જોઈએ.
કયું પોર્ટ ગ્રુપ બદલાયું અને કેમ, તે ડિઝાઇન-પંક્તિ લખ્યાની એ જ જગ્યાએ નોંધો. એ જ જોડી આગલી ઓડિટ શક્ય બનાવે છે.
ગેસ્ટની વસ્તુઓ સ્પષ્ટ રાખો
Linux ની અંદર, બ્રિજ સભ્યપદ અને સરનામાની માલિકી અલગ વસ્તુઓ છે, અને તેમને ભેગા કરવાથી મૂંઝવતી અડધી-કામ કરતી સ્થિતિ ઊભી થાય છે. સરનામાં બ્રિજ ઇન્ટરફેસને અથવા રૂટેડ ટનલને આપો, એક જ માર્ગની બંને બાજુએ નહીં, અને સભ્ય પોર્ટને IP રૂપરેખાંકનથી મુક્ત રાખો.
એક સબનેટને સ્વતંત્ર રીતે રૂટેડ TUN પર અને અસંબંધિત Ethernet ઇન્ટરફેસ પર મૂકવાનું ટાળો. એ રૂપરેખાંકન એક જ પ્રીફિક્સ સુધી બે માર્ગ બનાવે છે, અસમમિત જવાબો અને flapping વિશેનો સપોર્ટ થ્રેડ જે બંનેમાંથી કોઈ માર્ગનો ઉલ્લેખ કરતો નથી. જો ગેસ્ટ કન્ટેનર કે સ્થાનિક હાઇપરવાઇઝર પણ હોસ્ટ કરે, તો તપાસો કે તેઓ પહેલેથી એ જ uplink માં બ્રિજ કરી રહ્યા નથી. એક NIC પર બે બ્રિજ એ ડિઝાઇન છે, ફેરફાર-વિન્ડો દરમિયાન શોધવાનો અકસ્માત નહીં.
ping થી નહીં, પેકેટ-માર્ગથી ખાતરી કરો
ફક્ત પહોંચ નહીં, વાસ્તવિક માર્ગ ચકાસો. ક્લાયન્ટથી ખાતરી કરો કે કયું સ્રોત સરનામું દૂરની સેવા સુધી પહોંચે છે, પછી ખાતરી કરો કે જવાબ એ જ માર્ગે પાછો આવે છે. ગેસ્ટ પર ચોક્કસ ફ્લો માટે ફોરવર્ડિંગ કાઉન્ટર તપાસો, અને પોર્ટ ગ્રુપ પર ખાતરી કરો કે પસંદ કરેલી ડિઝાઇનની જરૂરતાથી વધુ કોઈ દૃશ્યતા સક્ષમ કરવામાં આવી નથી.
છેલ્લે નિષ્ફળતાની દિશા કસો. ટનલ બંધ કરો અથવા ક્લાયન્ટ અલગ કરો અને તપાસો કે ટ્રાફિક ચુપચાપ એવા રૂટેડ માર્ગ પર પાછો પડતો નથી જેને તમે ન વપરાયેલું માન્યું હતું, કારણ કે એ પડવું જ બ્રિજ્ડ ડિઝાઇનને ચુપચાપ અનિચ્છિત રાઉટર બનાવે છે.