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 स्वयं डाउन हो। वह इंटरफ़ेस चुनें जो वस्तु और उसके जीवनचक्र का स्वामी है; उत्पाद पृष्ठ के स्वचालन दावे उसका विकल्प नहीं हैं।