Linux VPN પર સરનામું, રૂટ, DNS અને ફાયરવોલની માલિકી કોની છે?

એક જ રૂટ માટે લડતી બે સ્ક્રિપ્ટ એ Linux VPN સમસ્યાનું સામાન્ય સ્વરૂપ છે, જે રૂટિંગ બગ તરીકે નોંધાય છે. એક ઘટક ટનલ ઉપકરણ બનાવે છે, બીજું ડિફૉલ્ટ રૂટ ઉમેરે છે, ત્રીજું રિઝોલ્વર રૂપરેખાંકન ફરીથી લખે છે, અને ચોથું ફાયરવોલ નિયમો ફરીથી લોડ કરે છે. તેમાંથી કોઈપણ બીજાનું કામ રદ કરી શકે છે, અને વિજેતા ફક્ત તે જ છે જે સૌથી છેલ્લે ચાલ્યું. જે પ્રશ્નનો જવાબ આપવો યોગ્ય છે તે એ નથી કે કઈ પૅકેજ ઇન્સ્ટૉલ કરવી, પણ એ કે સ્ટેટના દરેક ટુકડા માટે કયો ઘટક અધિકૃત છે.

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

ઉપકરણ અને તેના સરનામાં

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

સેશન પૂરું થાય ત્યારે ઉપકરણ કોણ દૂર કરે છે તે નોંધો. જે ઉપકરણ પોતાના સેશન કરતાં વધુ જીવે છે તે જૂનાં સરનામાં અને તેમની પાછળની મૂંઝવણનો સૌથી સામાન્ય સ્રોત છે.

રૂટ અને નીતિ નિયમો

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

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

DNS હંમેશા અલગ માલિક છે

રિઝોલ્વર ડીમન પોતાની ઓળખ હેઠળ પોતાની પ્રક્રિયા તરીકે ચાલે છે, તેથી તે આકસ્મિક રીતે ટનલના રૂટિંગ નિર્ણયો વારસો લેતું નથી. જ્યારે VPN DNS સર્વર ધકેલે છે, ત્યારે કંઈકે તેને રિઝોલ્વર પાળે તેવી પ્રતિ-લિંક રૂપરેખાંકનમાં અનુવાદિત કરવું પડે, અને પછી કંઈકે તેને દૂર કરવું પડે.

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

ફાયરવોલ સ્ટેટ, અને તેને કોણ પુનઃસ્થાપિત કરે છે

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

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

જીવનચક્ર: બૂટ, ફરી જોડાણ, ટિયરડાઉન

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

અવલોકન માટે ip monitor link address route કર્નલ ફેરફારો થતાં જ બતાવે છે, પણ તે ઈરાદો નહીં, ઘટનાઓની જાણ કરે છે: દૂર કરેલો રૂટ કઈ પ્રક્રિયાએ તેને દૂર કર્યો તે વિશે કંઈ કહેતો નથી. તેને માલિકી નકશા સાથે જોડો, અને મૂંઝવતું શટડાઉન ઉમેદવારોની ટૂંકી યાદી બની જાય છે.

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