હોસ્ટ રૂટ્સને અડ્યા વિના નેમસ્પેસમાં VPN રાઉટિંગની ચકાસણી કરો
ત્રણ સિમ્યુલેટેડ ભૂમિકાઓ, ત્રણ અલગ સંદર્ભો અને દરેક લિંક માટે એક veth. હોસ્ટને અડતા પહેલાં નેમસ્પેસ લેબની હોસ્ટ-રૂટ લેબ સાથે તુલના કરો.
બે લેબ સમાન VPN ટોપોલોજીનું મોડેલ બનાવી શકે છે અને સંપૂર્ણપણે જુદી રીતે નિષ્ફળ જઈ શકે છે: એક નેટવર્ક નેમસ્પેસમાં રહે છે, બીજી હોસ્ટની પોતાની રૂટ્સ પર. નેમસ્પેસ આવૃત્તિ દરેક ઇન્ટરફેસ, રૂટ અને સોકેટને એવા સંદર્ભમાં રાખે છે જે તમે ડિલીટ કરી શકો છો, જ્યારે હોસ્ટ આવૃત્તિ ઝડપથી શરૂ થાય છે અને પાછળ સ્થિતિ છોડી દે છે. એ જ બાકી રહેલી સ્થિતિ એ કારણ છે કે એક મહિના પછી બીજી લેબનું પુનરાવર્તન કરવું મુશ્કેલ છે. પહેલાં સફાઈની તુલના કરો, કારણ કે તે નક્કી કરે છે કે તમે પ્રયોગ બે વાર ચલાવી શકો છો કે નહીં.
એક જ લેબ બનાવવાની બે રીતો, અને ક્યારે કઈ જીતે છે
હોસ્ટ-રૂટ લેબમાં તમે જે મશીન પર કામ કરો છો તેમાં ટનલ ઇન્ટરફેસ અને રૂટ્સ ઉમેરો છો, તેથી પ્રયોગ તમારા shell, તમારા પેકેજ મેનેજર અને અન્ય દરેક કનેક્શન સાથે ભાગ્ય વહેંચે છે. નેમસ્પેસ લેબમાં દરેક ભૂમિકાને ઇન્ટરફેસ, સરનામાં, રૂટ્સ અને સોકેટ્સનો પોતાનો સ્ટેક મળે છે, અને નેમસ્પેસ ડિલીટ કરવાથી તે બધું દૂર થઈ જાય છે. કોઈ પણ મોડેલ વધુ સાચું નથી, કારણ કે તેઓ જુદા જુદા પ્રશ્નોના જવાબ આપે છે. જ્યારે વિષય રાઉટિંગ અને ફોરવર્ડિંગ હોય ત્યારે નેમસ્પેસ પસંદ કરો, અને જ્યારે વિષય એ હોય કે એક ડેસ્કટોપ ક્લાયન્ટ કેવી રીતે એકીકૃત થાય છે ત્યારે હોસ્ટ લેબ પસંદ કરો.
| Aspect | Namespace lab | Host-route lab |
|---|---|---|
| Isolation | Full stack per role | Shares the host stack |
| Cleanup | Delete named namespaces | Manual route and rule removal |
| Realism | Strong for routing | Needed for GUI clients |
બંનેને ભેગા કરવું એ સામાન્ય ભૂલ છે: ફક્ત હોસ્ટ ક્લાયન્ટ સામે ચકાસાયેલી નેમસ્પેસ લેબ બંને ગોઠવણોમાંથી કોઈના વિશે કંઈ સાબિત કરતી નથી. પહેલી લિંક બનાવતા પહેલાં નક્કી કરો કે તમે કયો પ્રશ્ન પૂછો છો.
દરેક ભૂમિકા માટે એક સંદર્ભ, જાણી જોઈને જોડાયેલ
દરેક ભૂમિકા માટે એક નેમસ્પેસ બનાવો અને દરેક veth જોડીનું દરેક છેડું તેના માલિક સંદર્ભમાં ખસેડો. પહેલા ચાર કમાન્ડ આકાર જોવા માટે પૂરતા છે:
ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns clientલેબને એવી રેન્જ આપો જે હોસ્ટ પર કોઈની સાથે ઓવરલેપ ન થાય, અને શરૂ કરતા પહેલાં લખો કે કયો નેમસ્પેસ કયા સરનામાનો માલિક છે. કામ કરતી લેબને બે અલગ માર્ગોની જરૂર છે: એક બાહ્ય માર્ગ જેથી VPN એન્ડપોઇન્ટ તેના પીઅર સુધી પહોંચે, અને સુરક્ષિત સંસાધન માટે પરત માર્ગ. તેમને બે નિર્ણય તરીકે મોડેલ કરો, કારણ કે ફક્ત બહાર જતો અડધો ભાગ બનાવતી લેબ હેન્ડશેક ટેસ્ટ પાસ કરે છે અને એપ્લિકેશન ટેસ્ટમાં નિષ્ફળ જાય છે.
ફોરવર્ડિંગ ભૂમિકા એ છે જ્યાં લેબ રસપ્રદ બને છે
એક ભૂમિકાએ ફોરવર્ડ કરવું પડે, જેનો અર્થ છે તે નેમસ્પેસની અંદર ફોરવર્ડિંગ સક્ષમ કરવું અને ડિઝાઇનને જે નિયમની જરૂર હોય તે ઉમેરવો. ફોરવર્ડિંગ સ્થિતિ દરેક નેમસ્પેસ માટે અલગ હોય છે, તેથી હોસ્ટ સેટિંગ લેબ માટે અપ્રસ્તુત છે અને લેબ સેટિંગ બહાર લીક થતી નથી, જેમ કે નેટવર્ક નેમસ્પેસ દસ્તાવેજીકરણ વર્ણવે છે. WireGuard દસ્તાવેજ કરે છે કે ઇન્ટરફેસ અને તેનું બાહ્ય સોકેટ જુદા જુદા નેમસ્પેસમાં રહી શકે છે, જે ઉપયોગી યુક્તિ અને તમારી જાતને મૂંઝવવાની ઉત્તમ રીત છે. એવું ન ધારો કે ઇન્ટરફેસ ખસેડવાથી કનેક્શનનો દરેક ભાગ એકસરખી રીતે ખસે છે.
ટેસ્ટ પેકેટ પછી ફોરવર્ડિંગ કાઉન્ટર તપાસો, કારણ કે ક્યારેય મેળ ન ખાધેલો નિયમ અને પેકેટ ફેંકી દેનારો નિયમ રૂટ ટેબલમાં એકસરખા દેખાય છે. ફક્ત કાઉન્ટર તેમને અલગ પાડે છે.
બેઝલાઇન નોંધો, પછી એક રૂટ તોડો
શું અસ્તિત્વમાં છે તે નોંધવાથી શરૂ કરો, દરેક લીટીની બાજુમાં સંદર્ભ લખો. નેમસ્પેસ વાંચો, પછી ટેસ્ટ ગંતવ્ય તેમાંથી એકની અંદર જે રૂટ લેશે તે, પછી તેને વહન કરતી લિંક પરના કાઉન્ટર:
ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-gત્રીજું કમાન્ડ એ છે જે લોકો છોડી દે છે, અને ત્યાં જ પુરાવો રહે છે: ફેંકાયેલા અને ભૂલોના કાઉન્ટર તમને કહે છે કે પેકેટ ફોરવર્ડિંગ ભૂમિકા સુધી પહોંચ્યું છે કે નહીં. ફેરફાર પછી એ જ ત્રણ દૃશ્યો કેપ્ચર કરો, અને પુરાવો તમારી યાદ નહીં, ડિફ થવા દો. પછી બરાબર એક વસ્તુ તોડો, કાં તો રૂટ ડિલીટ કરીને અથવા ફોરવર્ડિંગ માર્ગ પર નકાર નિયમ ઉમેરીને, અને તમે અનુમાન કરેલ લક્ષણની ખાતરી કરો: જવાબ વિના પૂર્ણ થયેલો હેન્ડશેક, અથવા ટાઇમઆઉટને બદલે નામ ઉકેલવામાં નિષ્ફળતા. ફક્ત સફળતા દર્શાવતી લેબ ખૂબ ઓછું શીખવે છે.
સફાઈ એ છે જે આગલી રનને પુનરાવર્તનીય બનાવે છે
સફાઈને તમે નામ આપેલા સંસાધનો સુધી મર્યાદિત રાખો, કારણ કે સંપૂર્ણ ફાયરવોલ રીસેટ અથવા હોસ્ટ રૂટ દૂર કરવું એ પુનરુત્પાદનક્ષમતા નથી, તે બીજી ઘટના છે. ટોપોલોજી, ચોક્કસ કમાન્ડ અને તમે અપેક્ષા રાખેલા અવલોકનો સાચવો, જેથી આગલી રન અગાઉની સ્થિતિ કયા સંદર્ભમાં હતી તે અનુમાન કરવાને બદલે એ જ નિષ્ફળતા ફરી ઉત્પન્ન કરે. તે રેકોર્ડ વિના લેબ એક વાર્તા છે, પ્રક્રિયા નહીં.
લેબ માટે સ્થાનિક રીતે જનરેટ કરેલા ઓળખપત્રો વાપરો, અને ઉત્પાદન એકાઉન્ટને વહેંચાયેલા ઉદાહરણોથી દૂર રાખો. પછી દરેક નેમસ્પેસ ડિલીટ કરો અને ખાતરી કરો કે હોસ્ટ દૃશ્ય અપરિવર્તિત છે, જે આ મોડેલ પસંદ કરવાનું આખું કારણ છે. જે લેબ તમે સ્વચ્છ રીતે દૂર કરી શકતા નથી તે વધારાના પગલાં સાથેનો હોસ્ટ ફેરફાર છે.