กำหนดปฏิบัติการ VPN ก่อนเปรียบเทียบ API
การควบคุมการเชื่อมต่อ การจัดเตรียมโปรไฟล์ การบริหารผู้ใช้ และการสังเกตเป็น 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 |
เงื่อนไขความสำเร็จคือช่องที่ผู้คนข้ามไป และเป็นสิ่งที่ตัดสินว่าการเชื่อมต่อทำงานหรือไม่ การตั้งค่าที่บันทึกไว้ไม่ใช่ tunnel ที่ทำงานอยู่ และบัญชีที่ปิดไม่ใช่เซสชันที่จบแล้ว
ถ้าสองปฏิบัติการต้องใช้ผู้เรียกต่างกัน นั่นคือสองการเชื่อมต่อ การรวมไว้ในบัญชีบริการเดียวมักหมายถึงการให้อำนาจมากกว่าที่แต่ละอย่างต้องการ
จับคู่อินเทอร์เฟซกับชั้นที่มันเป็นเจ้าของจริง
อินเทอร์เฟซการจัดการของชุมชน OpenVPN พูดคุยกับ daemon ผ่าน TCP หรือซ็อกเก็ต Unix คำสั่งรวมถึงการสังเกตสถานะและสัญญาณถึง daemon
นั่นทำให้มันเป็นช่องควบคุม daemon ไม่ใช่ API การสมัครสมาชิกที่โฮสต์ไว้หรือบริการลงทะเบียนผู้ใช้ การอ่านเอกสารอย่างระมัดระวังช่วยให้คุณไม่สร้างบนชั้นที่ไม่ได้เป็นเจ้าของวัตถุ
เอกสารนั้นยังบอกว่าโพรโทคอลไม่มีการเข้ารหัสของตัวเอง ใครก็ตามที่เข้าถึงซ็อกเก็ตได้สามารถควบคุม daemon ได้ จึงควรมองว่าเป็นการควบคุมที่ละเอียดอ่อน ไม่ใช่ฟีดเมตริก ผูกกับ loopback หรือซ็อกเก็ต Unix และวางไว้หลังการจัดวางที่จำกัดหากผู้เรียกจากระยะไกลต้องการ การเปิดสู่อินเทอร์เน็ตเพื่อความสะดวกเปลี่ยนช่องควบคุมให้เป็นเหตุการณ์
ระบุพฤติกรรมหลังการเรียก
การยอมรับไม่เหมือนกับการทำให้เสร็จสิ้น daemon อาจตอบกลับก่อน tunnel จะขึ้น ดังนั้นรอเหตุการณ์เสร็จสิ้นหรือล้มเหลวตามเอกสารและเชื่อมโยงกับคำขอที่คุณส่ง
ตัดสินใจว่าผู้เรียกทำอะไรหากคำตอบหายไป การทำซ้ำการสร้างหรือการเชื่อมต่อใหม่แบบไม่ดูอะไรเลยไม่เหมือนกับการตรวจสอบว่าคำขอแรกมีผลแล้วหรือไม่
การถอดการเข้าถึงมีอย่างน้อยสามการกระทำที่ต่างกัน: บล็อกการลงชื่อเข้าใช้ในอนาคต ยุติเซสชันที่ใช้งานอยู่ และเพิกถอนข้อมูลรับรอง ขอสิ่งที่่นโยบายต้องการจริง และระบุในสัญญาว่าอันไหนเป็นอันไหน อย่าติดป้ายการอัปเดตบัญชีที่สำเร็จหนึ่งครั้งว่าเป็นการเพิกถอนทั้งหมดโดยไม่มีหลักฐาน ความแตกต่างนี้สำคัญในช่วงเหตุการณ์เมื่อนาฬิกาเดิน
ตรวจสอบสัญญาด้วยการนำร่อง
การนำร่องเล็กๆ ที่ได้รับอนุมัติควรครอบคลุมความสำเร็จ การปฏิเสธ การขัดจังหวะ และการลองใหม่ ตามด้วยปฏิบัติการของแอปพลิเคชันที่ควรได้รับอนุญาตหรือถูกปฏิเสธ
สำหรับอินเทอร์เฟซระดับ daemon สองคำสั่งฝึกการสังเกตและสัญญาณ:
echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505ให้เฉพาะอำนาจที่ปฏิบัติการต้องการ เก็บความลับออกจากบันทึกประจำ และบันทึกรายละเอียดส่วนตัวให้พอที่จะบอกว่าเป้าหมายใดได้รับผลกระทบและจบลงอย่างไร
เขียนเส้นทางการกู้คืนสำหรับกรณีที่ API ควบคุมเองล่ม เลือกอินเทอร์เฟซที่เป็นเจ้าของวัตถุและวงจรชีวิตของมัน คำกล่าวอ้างเรื่องระบบอัตโนมัติบนหน้าผลิตภัณฑ์ไม่ใช่สิ่งทดแทน