સેટઅપ સ્ક્રિપ્ટ ચાલ્યા પછી VPN સર્વરનો માલિક કોઈ હોવું જોઈએ

બે અલગ કામો એક તરીકે વેચાય છે: મશીનને VPN સર્વરમાં ફેરવવું, અને બીજા કોઈના ગેટવેમાં જોડાવાનું હોય તેવા લેપટોપમાં VPN ક્લાયંટ ઉમેરવો. સેટઅપ સ્ક્રિપ્ટ પહેલાનો જવાબ આપે છે અને બીજાનો આપી શકતું નથી, તેના README શું કહે તે પછી પણ. setup-ipsec-vpn પ્રોજેક્ટ ને ઠોસ ઉદાહરણ તરીકે લો: તે સપોર્ટેડ Linux હોસ્ટ પર Libreswan અને xl2tpd વાપરીને IPsec/L2TP, Cisco IPsec કે IKEv2 સર્વર બનાવે છે. તે સર્વર માટેનો ડિપ્લોયમેન્ટ કરાર છે, કોઈપણ મશીન માટેની સામાન્ય રેસિપી નહીં. સ્ક્રિપ્ટ ચાલે તે પહેલાં તમારું કામ કયું છે તે નક્કી કરો, કારણ કે તે પછીનું બધું સર્વર વિશે છે.

હોસ્ટ વિશે પ્રામાણિક રહો

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

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

ઇન્સ્ટોલર ખરેખર શું લે છે

IPsec કન્ફિગરેશન અને સિક્રેટ ફાઇલ, L2TP ડેમન કન્ફિગરેશન, PPP વિકલ્પો અને હવે તે પોર્ટના માલિક systemd યુનિટની અપેક્ષા રાખો. પ્રોજેક્ટનું README કહે છે કે હાલની કન્ફિગરેશન ફાઇલોના ફેરફાર પહેલાં બેકઅપ લેવાય છે, જે ઉપયોગી છે અને હોસ્ટ બેકઅપ જેવું નથી. કયા ઘટકો ડિસ્ટ્રિબ્યુશનના પેકેજોથી અને કયા સ્ક્રિપ્ટ ફરી ચલાવીને કે ફરી લખીને અપડેટ થશે તે નક્કી કરો, કારણ કે આ અલગ નિષ્ફળતા રીતોવાળા બે જાળવણી માર્ગ છે.

તમે મંજૂર કરેલી આવૃત્તિ પિન કરો. વર્તમાન ડિફૉલ્ટ શાખા આપતું ડાઉનલોડ URL આવતા મહિને અલગ સામગ્રી પરત આપી શકે છે, તેથી તમે ચલાવેલ commit કે રિલીઝ નોંધો અને તેની નકલ રાખો. તે એક આદત જવાબદારી ન ઠરાવી શકાય તેવી સ્થિતિને એવી વસ્તુમાં ફેરવે છે જેના વિશે બીજી વ્યક્તિ રાત્રે બે વાગ્યે વિચારી શકે.

સ્ક્રિપ્ટ તમને શું આપી શકતું નથી

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

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

પ્રથમ ક્લાયંટ એ સ્વીકૃતિ પરીક્ષણ છે

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

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

હેન્ડઓફ પૃષ્ઠ લખો

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

હોસ્ટ બદલાય ત્યારે તે પૃષ્ઠ સમીક્ષા કરો, ફક્ત કંઈક તૂટે ત્યારે નહીં. જે હેન્ડઓફ દસ્તાવેજ કદી વંચાતો નથી તે દસ્તાવેજ છે જે ચૂપચાપ સાચો રહેવાનું બંધ કરી ગયો.