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

બે લીલા દીવા સરખામણી નથી

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

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

પ્રથમ રન પહેલાં અપેક્ષા નિશ્ચિત કરો

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

TunnelOwnerClient interface inside the namespaceProof commandRequired on disconnect
vpn-athe identity that owns profile A, recorded by nameits own tun device, never the host'sip -n vpn-a -4 route get 10.55.10.20traffic stops; no host-side fallback
vpn-ba separate owner, even when both run on one boxits own tun device in its own namespaceip -n vpn-b -4 route get 10.55.20.20verified separately, never inferred from A

રિઝોલ્વરની વાયરિંગને તે રેકોર્ડમાં પોતાની હરોળ જોઈએ છે, કારણ કે ખોટું બોલવાની સૌથી વધુ શક્યતા આ ક્ષેત્રમાં છે. નામાવકાશ સાથે જોડાયેલી ફાઇલો, જેમ કે /etc/netns/vpn-a/resolv.conf કમાન્ડ નામાવકાશની અંદર ચાલે ત્યારે તેમના સામાન્ય માર્ગો પર દેખાય છે, જેમ કે iproute2 નું નામાવકાશ સંદર્ભ વર્ણવે છે, પરંતુ નામ-સેવા સ્વિચ રૂપરેખાંકન અને તે શરૂ કરે તેવું કોઈપણ સ્થાનિક રિઝોલ્વર હજી પણ લુકઅપને હોસ્ટ તરફ પાછું ખેંચી શકે છે.

એક વખતે એક ટનલ, બીજી ડિસ્કનેક્ટેડ

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

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

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

બંને ઉપર, પછી એક વખતે એક નીચે

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

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

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

આ રેકોર્ડ શું દાવો કરી શકે અને શું નહીં

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

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

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

સંબંધિત લેખો