คุณเชื่อมต่อ VPN เปิดโน้ตบุ๊ก และคาดว่าซีลหนักจะรันบนเซิร์ฟเวอร์ ในทางปฏิบัติ อุโมงค์ส่งผ่านเพียงแพ็กเก็ต มันไม่ได้ติดตั้งตัวประเมิน ไม่ได้ให้สิทธิ์การใช้งาน และไม่ได้เลือกว่าเครื่องใดจะรันโค้ด สิ่งเหล่านี้เป็นสามเรื่องแยกกัน และเวิร์กโฟลว์เคอร์เนลระยะไกลต้องการทั้งสามอย่างก่อนที่การคำนวณแรกจะเชื่อถือได้

ความเข้าใจผิด: การเชื่อมต่อ VPN คือการตั้งค่า

VPN จัดเตรียมเส้นทางเครือข่ายระหว่างแล็ปท็อปกับเซิร์ฟเวอร์ นั่นมีประโยชน์และมักจำเป็น เพราะช่องทางเปิดใช้งานและการเชื่อมต่อเคอร์เนลต้องไปถึงโฮสต์ระยะไกล แต่มันไม่ได้บอกว่าโฮสต์นั้นมีเคอร์เนล Wolfram หรือไม่ สิทธิ์การใช้งานอนุญาตให้มีโฟลว์ที่สองพร้อมกันหรือไม่ หรือส่วนหน้าถูกกำหนดค่าให้ใช้มันหรือไม่

แล็ปท็อปที่ได้รับการจัดการอาจมีเฉพาะส่วนหน้า โดยสิทธิ์ผูกกับเซิร์ฟเวอร์ ตรงกันข้ามก็เกิดได้: สิทธิ์การใช้งานเดสก์ท็อปบนแล็ปท็อปไม่ได้อนุญาตเคอร์เนลบนโครงสร้างพื้นฐานที่ใช้ร่วมกัน ทั้งสองกรณีไม่ได้รับการแก้ไขด้วยการเชื่อมต่ออุโมงค์ใหม่

ทดสอบสมมติฐานนี้แต่เนิ่น ๆ ประเมิน $MachineName ในโน้ตบุ๊กใหม่และเปรียบเทียบคำตอบกับโฮสต์ที่คุณคาดหวัง หากมันคืนชื่อแล็ปท็อป ซีลนั้นรันในเครื่อง ไม่ว่า VPN จะดูแข็งแรงเพียงใด

แยกส่วนหน้าออกจากตัวประเมิน

ส่วนหน้าคือหน้าต่าง: มันแก้ไขซีล แสดงผลลัพธ์ และบันทึกไฟล์โน้ตบุ๊ก เคอร์เนลคือโฟลว์ที่ประเมินนิพจน์และเก็บคำจำกัดความไว้ในหน่วยความจำ การปิดส่วนหน้าไม่ได้ย้ายเคอร์เนล และการบันทึกโน้ตบุ๊กไม่ได้บันทึกสถานะของเคอร์เนล

เมื่อเชื่อมต่อเคอร์เนลระยะไกลแล้ว ตำแหน่งไฟล์ของโน้ตบุ๊กและไดเรกทอรีทำงานของเคอร์เนลเป็นคนละเรื่อง Directory[] รายงานไดเรกทอรีของตัวประเมิน และนี่คือเส้นทางที่สำคัญสำหรับ Import Export และชื่อไฟล์แบบสัมพัทธ์ ชุดข้อมูลที่อยู่ข้างโน้ตบุ๊กบนแล็ปท็อปไม่สามารถมองเห็นได้จากเคอร์เนลที่รันบนอีกเครื่อง

ตัดสินใจว่าข้อมูลจะไปถึงเซิร์ฟเวอร์อย่างไรก่อนเขียนการวิเคราะห์: ตำแหน่งที่เมานต์ใช้ร่วมกัน ขั้นตอนการถ่ายโอนที่ได้รับอนุมัติ หรือฐานข้อมูลที่เซิร์ฟเวอร์เข้าถึงได้โดยตรง ตัวเลือกนี้ส่งผลต่อการทำซ้ำได้ เพราะโน้ตบุ๊กที่พึ่งพาเส้นทางบนแล็ปท็อปจะล้มเหลวในครั้งถัดไปที่มีคนอื่นรันมัน

เปิดใช้งานเคอร์เนลผ่านช่องทางที่ได้รับอนุมัติ

คู่มือเคอร์เนลระยะไกลของ Wolfram อธิบายการเพิ่มรายการเคอร์เนล การเลือกเครื่องระยะไกล และการเปิดใช้งานผ่าน SSH เส้นทางไฟล์เรียกทำงานและอาร์กิวเมนต์ในตัวอย่างเป็นของเวิร์กโฟลว์ผลิตภัณฑ์นั้น ปรับให้เข้ากับโฮสต์และเวอร์ชันที่ผู้ดูแลระบบระบุ แทนที่จะวางโดยไม่เปลี่ยนแปลง

ตัวตนของโฮสต์เป็นส่วนหนึ่งของการตั้งค่า ตรวจสอบคีย์โฮสต์ SSH ผ่านกระบวนการขององค์กร ใช้วิธีการตรวจสอบสิทธิ์ที่ออกให้ และเก็บคีย์ส่วนตัวและรหัสผ่านไว้นอกไฟล์โน้ตบุ๊กที่แชร์หรือคอมมิตในรีโพซิทอรี โน้ตบุ๊กที่มีคำสั่งเปิดใช้งานและรหัสผ่านคือการรั่วไหลของข้อมูลรับรอง ไม่ใช่ความสะดวก

อย่าเปิดตัวรับฟัง WSTP สู่อินเทอร์เน็ตเป็นทางลัด รูปแบบที่รองรับคือการเปิดใช้งานผ่าน SSH ซึ่งเก็บช่องทางเคอร์เนลไว้ในการเชื่อมต่อที่ผ่านการตรวจสอบสิทธิ์ หากทีมเครือข่ายอนุมัติการขนส่งอื่น ให้ใช้สิ่งนั้น แต่ถือว่าพอร์ตตัวประเมินที่เปิดอยู่เป็นการเปลี่ยนแปลงการออกแบบ ไม่ใช่ขั้นตอนการแก้ปัญหา

ตรวจสอบสิทธิ์ ข้อมูล และขนาดผลลัพธ์ก่อน

ยืนยันกับเจ้าของสิทธิ์การใช้งานว่าเซิร์ฟเวอร์สามารถรันเคอร์เนลสำหรับผู้ใช้รายนี้และอนุญาตเซสชันพร้อมกันได้ การคำนวณระยะไกลมักได้รับสิทธิ์แยกจากส่วนหน้าเดสก์ท็อป และการเปิดใช้งานที่ล้มเหลวเพราะสิทธิ์ดูคล้ายคำสั่ง SSH ที่ล้มเหลวจนกว่าจะมีคนอ่านข้อความของเซิร์ฟเวอร์

จากนั้นประเมินขนาดของผลลัพธ์ เคอร์เนลที่คืนนิพจน์ขนาดหลายกิกะไบต์จะส่งผ่านช่องทางเปิดใช้งานและช่องทางเคอร์เนลไปยังส่วนหน้า ซึ่งอาจทำให้หน่วยความจำของแล็ปท็อปหยุดชะงักหรือหมด เก็บการรวมข้อมูลหนักไว้บนเซิร์ฟเวอร์และคืนบทสรุป หรือเขียนผลลัพธ์ขนาดใหญ่ไปยังเส้นทางบนเซิร์ฟเวอร์และถ่ายโอนอย่างตั้งใจ

บันทึกเส้นทางไฟล์เรียกทำงาน อาร์กิวเมนต์เปิดใช้งาน และไดเรกทอรีทำงานในบันทึกการตั้งค่าของโน้ตบุ๊ก ผู้ใช้ถัดไปจะสร้างการจัดวางนี้ขึ้นใหม่แทนที่จะค้นพบอีกครั้งว่าเซิร์ฟเวอร์ใช้เส้นทางใดจากห้าเส้นทางที่เป็นไปได้

วินิจฉัยขั้นตอนตามลำดับ

ห้าขั้นตอนต้องสำเร็จ และแต่ละขั้นมีการทดสอบที่แตกต่างกัน เริ่มจากแล็ปท็อปและหยุดที่ความล้มเหลวแรกแทนที่จะเปลี่ยนการตั้งค่าหลายอย่างพร้อมกัน

nc -vz research.example.edu 22
ssh -v [email protected] 'hostname; command -v wolframscript'
ssh [email protected] 'wolframscript -code "$MachineName"'

การตรวจสอบ TCP ที่ล้มเหลวชี้ไปที่การกำหนดเส้นทาง DNS หรือปลายทางที่ VPN อนุญาต การตรวจสอบ TCP ที่สำเร็จแต่การเข้าสู่ระบบ SSH ล้มเหลวชี้ไปที่การตรวจสอบสิทธิ์หรือนโยบายคีย์โฮสต์ การเข้าสู่ระบบที่ทำงานได้แต่ไม่พบไฟล์เรียกทำงานชี้ไปที่การติดตั้งเคอร์เนลหรือเส้นทางที่ให้กับส่วนหน้า เคอร์เนลที่เริ่มทำงานแต่ไม่เคยเชื่อมต่อชี้ไปที่อาร์กิวเมนต์เปิดใช้งานหรือไฟร์วอลล์ภายใน

เก็บข้อผิดพลาดแรกที่มีความหมายไว้และส่งขั้นตอนฝั่งเซิร์ฟเวอร์ให้ผู้ดูแลระบบที่เป็นเจ้าของเครื่องนั้น การสร้างรายการเคอร์เนลซ้ำแล้วซ้ำอีกจะซ่อนว่าขั้นตอนใดล้มเหลวจริง และทิ้งหลักฐานที่ผู้ดูแลระบบต้องการ

สุดท้ายคุณต้องการหน้าต่างที่คุณจำได้ ตัวประเมินที่คุณตั้งชื่อได้ และเส้นทางที่ตกลงกันสำหรับโค้ดและไฟล์ VPN เป็นองค์ประกอบหนึ่งของเส้นทางนั้น และยิ่งเวิร์กโฟลว์สะท้อนสิ่งนี้เร็วเท่าใด ก็ยิ่งใช้เวลาน้อยลงในการเชื่อมต่ออุโมงค์ที่ไม่เคยเป็นปัญหากลับใหม่

บทความที่เกี่ยวข้อง