નેટવર્ક નેમસ્પેસમાં WireGuard: સોકેટ કેમ પાછળ રહી ગયું

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

લક્ષણ: યોગ્ય નેમસ્પેસ, પણ પેકેટ નહીં

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

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

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

સોકેટનું જન્મસ્થળ કેમ છે

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

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

તમે સોકેટ જ્યાં ઇચ્છો ત્યાં જ તેને બનાવો

ઉકેલ એ છે કે ઉપકરણને બહાર બનાવીને ખસેડવાને બદલે લક્ષ્ય નેમસ્પેસની અંદર જ બનાવો. ધારો કે મંજૂર નેમસ્પેસ પહેલેથી અસ્તિત્વમાં છે અને નામ વપરાયેલું નથી:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

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

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

માર્ગની બંને બાજુ વાંચો

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

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

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