OpenVPN માં પહેલેથી બનાવેલ tun: બે માલિકી મોડેલની સરખામણી

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

નામ એ જોડાણ નથી

dev tun1 OpenVPN પાસે એ નામવાળું ઇન્ટરફેસ માંગે છે, અને પરંપરાગત યુઝરસ્પેસ બિલ્ડ તેને ખોલવાનો પ્રયાસ કરશે. જો નામ સામાન્ય tun કે tap પેટર્નને અનુસરતું ન હોય, તો પ્રોફાઇલને અનુરૂપ dev-type પણ જોઈએ, કારણ કે પ્રકાર ક્યારેય શબ્દમાળામાંથી અનુમાનિત થતો નથી. TAP ઉપકરણ બીજા લેબલવાળું TUN ઉપકરણ નથી: ખોટું જોડવાથી કાં તો સીધું નિષ્ફળ જાય છે, કાં તો એવી લિંક બને છે જે કોઈ અપેક્ષા ન રાખે તેવા ફ્રેમ વહન કરે છે. બીજા કોઈપણ પગલા પહેલા પ્રકાર તપાસો, કારણ કે પછીની દરેક તપાસ ધારે છે કે બંને પક્ષો તેના પર સહમત છે. ત્યારબાદ ખાતરી કરો કે પ્રક્રિયા ઉપકરણને ખરેખર ખોલી શકે છે, ફક્ત જોઈ શકે છે એ નહીં.

dev tun1
dev-type tun

નેટવર્ક ઇન્ટરફેસ અને /dev/net/tun અલગ વસ્તુઓ છે: એક નેમસ્પેસની અંદરની લિંક છે, બીજું એ કેરેક્ટર ઉપકરણ છે જે યુઝરસ્પેસ પ્રોગ્રામ જોડાવા માટે વાપરે છે. Linux TUN/TAP દસ્તાવેજીકરણ એ જોડાણ-માર્ગ અને ટકાઉ ઉપકરણો માટેની માલિકીના નિયમો વર્ણવે છે. જે root શેલ ip link ચલાવી શકે છે તે ફક્ત એ સાબિત કરે છે કે શેલ પાસે વિશેષાધિકાર છે, ડેમન પાસે છે એ નહીં. ઉપકરણ નોડની માલિકી, સેવાની ક્ષમતાઓનો સમૂહ અને તે જે વપરાશકર્તા તરીકે ચાલે છે — બધું મેળ ખાવું જોઈએ ખોલવું સફળ થાય તે પહેલા.

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

લિંક કોણ ગોઠવે છે: બે માલિકી મોડેલ

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

ifconfig-noexec ફક્ત સરનામાં આવરે છે: રૂટિંગ કોષ્ટક અસ્પૃષ્ટ રહે છે, અને રૂટ રૂપરેખા route-noexec ની છે. બંને નિર્દેશોને અલગ નિયંત્રણો અને અલગ માલિકો તરીકે ગણો, કારણ કે એક સેટ કરીને બીજાનું અનુમાન કરવું એ અડધી-ગોઠવાયેલી લિંકોનો સામાન્ય સ્રોત છે. દરેક સ્તર માટે બરાબર એક માલિક પસંદ કરો, સરનામાં એક જગ્યાએ અને રૂટ એક જગ્યાએ. નેટવર્ક મેનેજર અને VPN સહાયક બંને સરનામાં લખે તો ડિસ્કનેક્ટ બીજી બાજુ હજી જે સ્થિતિ પર આધાર રાખે છે તેને ભૂંસી નાખે છે.

જે નેમસ્પેસ મહત્વનું છે તેમાંથી ઉપકરણની તપાસ કરો

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

ip -details link show dev tun1
ip tuntap show

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

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

બે અલગ પ્રકારની ટકાઉપણું

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

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

ફક્ત સ્ટાર્ટઅપ ચકાસવાથી શું તૂટે છે

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

systemctl status openvpn-client@lab
ip -details link show dev tun1

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

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

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