APIની સરખામણી કરતા પહેલાં VPN કામગીરી વ્યાખ્યાયિત કરો
કનેક્શન નિયંત્રણ, પ્રોફાઇલ પ્રદાન, વપરાશકર્તા વ્યવસ્થાપન અને અવલોકન જુદા જુદા API છે. પહેલાં ઑબ્જેક્ટ, ક્રિયા અને સફળતાની શરત નામ આપો.
એક ઉત્પાદન પૃષ્ઠ કહે છે કે તેમાં API છે, અને એકીકરણ બેઠક બીજા પ્રશ્ન પર અટકી જાય છે. કઈ કામગીરી, કયા ઑબ્જેક્ટ પર, કોના દ્વારા બોલાવાય છે, અને શું સફળતા ગણાય? ઉત્પાદનોની સરખામણી કરતા પહેલાં આ ચારના જવાબ આપવાથી સામાન્ય રીતે અડધા ઉમેદવારો દૂર થાય છે. તે બાકીની સરખામણીને પણ એવી વસ્તુ બનાવે છે જે કોઈ પરીક્ષણ નક્કી કરી શકે.
API છે એવા દાવાને એક કામગીરીથી બદલો
API એ પરિવહન છે, ક્ષમતા નહીં. REST એન્ડપોઇન્ટ, સ્થાનિક સોકેટ અને કમાન્ડ-લાઇન રેપરને બધાને API કહી શકાય, અને તે સમાન કામગીરી આપતા નથી.
દસ્તાવેજીકરણ ખોલતા પહેલાં કામગીરીને એક વાક્ય તરીકે લખો.
સ્થાનિક કનેક્શન શરૂ કરવું એ ક્લાયન્ટ-બાજુની ક્રિયા છે જેની સામે વપરાશકર્તા હોય છે. ઉપકરણ પ્રોફાઇલ જારી કરવું એ પ્રદાન ક્રિયા છે જેની પાછળ ઇન્વેન્ટરી હોય છે. વપરાશકર્તાની ઍક્સેસ નિષ્ક્રિય કરવી એ વહીવટી ક્રિયા છે જેમાં ઓડિટ ટ્રેલ હોય છે. આ ત્રણ સામાન્ય રીતે જુદા જુદા ઘટકોમાં રહે છે, જુદી જુદી ટીમોની માલિકીના, જુદા જુદા અધિકાર સાથે.
ચાર ક્ષેત્રો જે કરારને પરીક્ષણયોગ્ય બનાવે છે
દરેક કામગીરી માટે ચાર ક્ષેત્રો ભરો: ઑબ્જેક્ટ, ક્રિયા, બોલાવનાર અને સફળતાની શરત. જે કરારમાં એક ક્ષેત્ર ખૂટે છે તે ઇચ્છા છે.
કોષ્ટક એ આખી કાર્યપત્રક છે:
| Field | Question | Example |
|---|---|---|
| Object | What is being acted on? | One enrolled device |
| Action | Observe, create, change, start, stop, or revoke? | Revoke |
| Caller | Which identity calls it? | Deployment service |
| Success | What observable state proves it? | Future sign-in denied |
સફળતાની શરત એ ક્ષેત્ર છે જે લોકો છોડી દે છે, અને તે જ નક્કી કરે છે કે એકીકરણ કામ કરે છે કે નહીં. સાચવેલ સેટિંગ સક્રિય ટનલ નથી, અને નિષ્ક્રિય કરેલું ખાતું સમાપ્ત થયેલું સત્ર નથી.
જો બે કામગીરીઓને જુદા જુદા બોલાવનારની જરૂર હોય, તો તે બે એકીકરણો છે. તેમને એક સેવા ખાતામાં ભેગા કરવાનો અર્થ સામાન્ય રીતે બંનેમાંથી કોઈને જરૂર હોય તેના કરતાં વધુ અધિકાર આપવો છે.
ઇન્ટરફેસને તેના વાસ્તવિક સ્તર સાથે મેળવો
OpenVPNનું સમુદાય મેનેજમેન્ટ ઇન્ટરફેસ TCP અથવા Unix સોકેટ દ્વારા ડિમન સાથે વાત કરે છે. તેની આદેશોમાં સ્થિતિનું અવલોકન અને ડિમનને સંકેતોનો સમાવેશ થાય છે.
આ તેને ડિમન નિયંત્રણ ચેનલ બનાવે છે, હોસ્ટેડ સબ્સ્ક્રિપ્શન API કે વપરાશકર્તા નોંધણી સેવા નહીં. તેનું દસ્તાવેજીકરણ કાળજીપૂર્વક વાંચવાથી એવા સ્તર સામે નિર્માણ ટળે છે જે ઑબ્જેક્ટનો માલિક નથી.
તે દસ્તાવેજીકરણ એમ પણ કહે છે કે પ્રોટોકોલ પોતાનું કોઈ એન્ક્રિપ્શન ધરાવતું નથી. જે સોકેટ સુધી પહોંચી શકે તે ડિમનને નિયંત્રિત કરી શકે છે, તેથી તેને મેટ્રિક્સ ફીડ નહીં, સંવેદનશીલ નિયંત્રણ તરીકે ગણો. તેને loopback અથવા Unix સોકેટ સાથે બાંધો, અને દૂરના બોલાવનારને જરૂર હોય તો મર્યાદિત ગોઠવણી પાછળ મૂકો. સુવિધા માટે તેને ઇન્ટરનેટ પર ખુલ્લું કરવાથી નિયંત્રણ ચેનલ ઘટના બની જાય છે.
કૉલ પછીનું વર્તન નિર્દિષ્ટ કરો
સ્વીકૃતિ એ પૂર્ણતા નથી. ડિમન ટનલ ઉપર આવે તે પહેલાં પાછું ફરી શકે છે, તેથી દસ્તાવેજીકૃત પૂર્ણતા કે નિષ્ફળતાની ઘટનાની રાહ જુઓ અને તેને તમે મોકલેલી વિનંતી સાથે જોડો.
જવાબ ખોવાઈ જાય તો બોલાવનાર શું કરે તે નક્કી કરો. કોઈ રચના કે ફરી-કનેક્શનને આંધળું પુનરાવર્તન કરવું એ પ્રથમ વિનંતી પહેલેથી અસર કરી છે કે નહીં તે ચકાસવા સમાન નથી.
ઍક્સેસ દૂર કરવી એ ઓછામાં ઓછી ત્રણ જુદી ક્રિયાઓ છે: ભવિષ્યનું સાઇન-ઇન અવરોધવું, ચાલુ સત્ર સમાપ્ત કરવું અને ઓળખપત્ર રદ કરવું. નીતિ ખરેખર જે માગે તે માગો, અને કરારમાં કહો કે કઈ કઈ છે. પુરાવા વિના એક સફળ ખાતા અપડેટને સંપૂર્ણ રદ તરીકે લેબલ ન કરો. ઘટના દરમિયાન, જ્યારે ઘડિયાળ ચાલે છે, ત્યારે આ તફાવત મહત્ત્વનો છે.
પાયલોટ સાથે કરાર ચકાસો
નાના મંજૂર કરેલા પાયલોટમાં સફળતા, અસ્વીકાર, વિક્ષેપ અને ફરી પ્રયાસ આવરી લેવો જોઈએ, ત્યારપછી એ એપ્લિકેશન કામગીરી જેને મંજૂરી કે નિષેધ હોવો જોઈએ.
ડિમન સ્તરના ઇન્ટરફેસ માટે, બે આદેશો અવલોકન અને સંકેતનો અભ્યાસ કરે છે:
echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505કામગીરી જે અધિકાર માગે તે જ આપો. રહસ્યોને નિયમિત લોગની બહાર રાખો, અને કયું લક્ષ્ય પ્રભાવિત થયું અને કેવી રીતે પૂરું થયું તે કહેવા પૂરતી ખાનગી વિગતો લોગ કરો.
જ્યારે નિયંત્રણ API પોતે ડાઉન હોય તે કેસ માટે પુનઃપ્રાપ્તિ માર્ગ લખો. જે ઇન્ટરફેસ ઑબ્જેક્ટ અને તેના જીવનચક્રનો માલિક છે તે પસંદ કરો; ઉત્પાદન પૃષ્ઠ પરના ઓટોમેશન દાવાઓ તેનો વિકલ્પ નથી.