VPN માટે Linux નેટવર્ક નેમસ્પેસ: તે શું અલગ નથી કરતા

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

નેમસ્પેસ શું ધરાવે છે, અને સોકેટ ક્યાં જન્મે છે

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

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

નેમસ્પેસ શું અલગ કરતું નથી

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

ઉકેલ એ /etc/netns/<name>/resolv.conf પર પ્રતિ-નેમસ્પેસ ફાઇલ છે, અથવા તૈયાર કરેલી ફાઇલનું bind mount, જે અંદરથી પહોંચી શકાય તેવા રિઝોલ્વર તરફ દોરે છે. હોસ્ટ પર /etc/resolv.conf સંપાદિત કરવાથી નેમસ્પેસ જે જુએ છે તેમાં કંઈ બદલાતું નથી.

પ્રક્રિયાઓની ગોઠવણી એ જ નિયંત્રણ છે

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

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

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

એપ્લિકેશનના સંદર્ભથી પરીક્ષણ કરો

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

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

ફોરવર્ડિંગ, નિષ્ફળતા નીતિ અને ક્લીનઅપ

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

નેમસ્પેસના નામ, ઇન્ટરફેસ અને રૂપરેખાંકન કોનું છે તે નોંધો, જેથી ક્લીનઅપ ફક્ત ડિપ્લોયમેન્ટે બનાવેલું જ દૂર કરે. રોલબેક દરમિયાન હોસ્ટ નેટવર્કિંગ રીસેટ કરવું ક્લીનઅપને વિક્ષેપમાં ફેરવે છે. પાનું network_namespaces(7) ટૂંકું છે અને તે રસ્તો ડિઝાઇન કરતા પહેલાં વાંચવા જેવું છે.