NetBIOS บน VPN: ชื่อ เดตาแกรม และเซสชันเป็นบริการที่แยกจากกัน
คำขวัญเกี่ยวกับเราเตอร์นั้นกว้างเกินไป ตรวจสอบว่าแอปพลิเคชันของคุณใช้บริการใดในสามบริการ และแก้ชื่อด้วยการออกอากาศหรือผ่านเซิร์ฟเวอร์
«NetBIOS ไม่ข้ามเราเตอร์» ถูกพูดซ้ำราวกับว่าคำกล่าวนี้ตัดสินเรื่องการออกแบบแล้ว แต่ไม่ได้ตัดสิน การค้นหาชื่อด้วยการออกอากาศมักอยู่ในโดเมนการออกอากาศของตัวเอง แต่บริการ NetBIOS ยังใช้ทราฟฟิก IP แบบเจาะจงที่เราเตอร์ส่งต่อได้ดีก็ได้ คำถามที่มีประโยชน์ไม่ใช่ NetBIOS ข้ามเราเตอร์หรือไม่ แต่เป็นว่าแอปพลิเคชันของคุณใช้บริการใดในสามบริการของมัน
อินเทอร์เฟซซอฟต์แวร์ ไม่ใช่โปรโตคอลสายเดียว
RFC 1001 อธิบาย NetBIOS ว่าเป็นอินเทอร์เฟซที่แอปพลิเคชันเขียนโปรแกรมเข้าหา โดยมีชั้นการขนส่งหลายชั้นอยู่ข้างใต้ โมเดล TCP/UDP ของมันแยกบริการชื่อ การกระจายเดตาแกรม และบริการเซสชันออกจากกัน และรองรับการทำงานที่มีหรือไม่มีการออกอากาศ IP อย่างชัดเจน
| Service | What it does | Transport dependence |
|---|---|---|
| Name | Registers and resolves names | Broadcast, point-to-point, or a name server |
| Datagram | Connectionless messages, including broadcast | Broadcast domain or directed delivery |
| Session | Connection-oriented exchange | TCP connection to a named endpoint |
ตารางนี้เองที่ทำให้คำขวัญล้มเหลว บริการเซสชันระหว่างโฮสต์ที่ตั้งชื่อสองเครื่องเป็นการสนทนาแบบ IP ส่วนเดตาแกรมแบบออกอากาศไม่ใช่ การออกแบบ VPN หนึ่งแบบอาจตอบโจทย์อย่างแรกแต่ไม่ตอบอย่างที่สอง และการทดสอบที่พิสูจน์อย่างแรกก็ไม่บอกอะไรเกี่ยวกับอย่างที่สอง
ชนิดของโหนดเป็นตัวกำหนดว่าไคลเอนต์ขออะไร
โมเดลโหนดแบบออกอากาศ แบบจุดถึงจุด และแบบผสมของ RFC 1001 อธิบายว่าโฮสต์แก้ชื่ออย่างไร คือถามเครือข่ายท้องถิ่น ถามเซิร์ฟเวอร์ชื่อโดยตรง หรือลองวิธีหนึ่งแล้วลองอีกวิธีหนึ่ง โมเดลมีผลต่อทราฟฟิกที่ต้องอนุญาต ไม่ใช่ต่อว่าแอปพลิเคชันทำงานได้หรือไม่
การจัดเซิร์ฟเวอร์ชื่อแบบมีการจัดการให้เส้นทางจุดถึงจุดแก่ไคลเอนต์ แต่เฉพาะไคลเอนต์ที่กำหนดค่าให้ใช้เท่านั้น การวางเซิร์ฟเวอร์ไว้ที่ใดที่หนึ่งในเครือข่ายไม่ได้ทำให้แอปพลิเคชันสอบถามมัน และไคลเอนต์ที่ถูกทิ้งไว้ในโหมดออกอากาศจะยังถามเซกเมนต์ท้องถิ่นต่อไปจนหมดเวลา ที่อยู่ของเซิร์ฟเวอร์ต้องไปถึงการกำหนดค่าของไคลเอนต์ ผ่านเส้นทางการจัดการที่ไคลเอนต์นั้นเคารพ
ดังนั้นบันทึกการสังเกตสามข้อสำหรับแอปพลิเคชันที่เกี่ยวข้อง คือมันแปลงชื่อเซิร์ฟเวอร์เป็นที่อยู่อย่างไร การค้นหาหรือการส่งข้อความใช้การออกอากาศหรือปลายทางแบบเจาะจง และเซสชันจริงใช้ที่อยู่และการขนส่งใด ทั้งสามเป็นข้อเท็จจริงที่เป็นอิสระต่อกัน และแต่ละข้อมีวิธีแก้ของตัวเอง การแก้ชื่อสำเร็จหนึ่งครั้งเป็นหลักฐานเกี่ยวกับข้อแรกเท่านั้น
NetBIOS บน TCP/IP ไม่ใช่ NetBEUI
ทั้งสองถูกทำให้สับสนเพราะทั้งคู่ถูกเรียกว่ารุ่นเก่า NetBIOS บน TCP/IP บรรทุกบริการไว้ในแพ็กเก็ต IP ซึ่งอุโมงค์ที่เราเตอร์ส่งต่อนั้นขนส่งอยู่แล้ว ส่วน NetBEUI เป็นโปรโตคอลชั้น 2 ที่ไม่สามารถส่งต่อได้ และอุโมงค์ IP ไม่ได้ขนส่งเฟรมอีเทอร์เน็ตใด ๆ เพียงเพราะมันขนส่ง IP
การเพิ่มเส้นทาง IP ไม่สามารถเปลี่ยนเฟรมที่ไม่ใช่ IP ให้เป็นแอปพลิเคชัน IP ได้ หากแอปพลิเคชันพึ่งพาพฤติกรรมของชั้น 2 จริง ทางเลือกคือบริการชั้น 2 ที่จำกัดขอบเขตอย่างชัดเจน หรือเปลี่ยนแอปพลิเคชัน ไม่มีการเปลี่ยนแปลงเส้นทางใดที่ใช้แทนทั้งสองอย่างได้
เลือกการเปลี่ยนแปลงที่เล็กที่สุดที่ตอบโจทย์งาน
แชร์ SMB ที่มีอยู่ซึ่งเข้าถึงได้ด้วยชื่อ DNS ที่ได้รับอนุมัติและพาธ UNC ที่ชัดเจนไม่ต้องการส่วนขยายอีเทอร์เน็ต งานบริการไฟล์กับประสบการณ์การเรียกดูเป็นความต้องการที่แตกต่างกัน และมีเพียงอย่างหลังเท่านั้นที่ขึ้นกับรายการเพื่อนบ้าน การเข้าถึงแชร์ด้วยชื่อแก้โจทย์ได้โดยไม่ต้องยืดโดเมนการออกอากาศผ่านอุโมงค์
การเรียกดูคือส่วนที่มักล้มเหลว และล้มเหลวอย่างเงียบ ๆ เครื่องหนึ่งสามารถเปิดแชร์ตามพาธได้ในขณะที่รายการคอมพิวเตอร์ใกล้เคียงยังว่างอยู่ เพราะรายการถูกเติมด้วยการค้นหาด้วยการออกอากาศ และพาธใช้ DNS การตัดสินใจว่าคุณต้องการรายการเป็นความต้องการที่ต่างจากการตัดสินใจว่าคุณต้องการไฟล์ จดไว้ว่าผู้ใช้ขอสิ่งใดจริง ๆ ก่อนที่คุณจะออกแบบอะไร
เมื่อแอปพลิเคชันรุ่นเก่าต้องการการออกอากาศหรือเฟรมที่ไม่ใช่ IP จริง ๆ ให้ประเมินบริการชั้น 2 ที่จำกัดขอบเขตและมีเจ้าของที่ระบุชื่อ หรือเปลี่ยนแอปพลิเคชัน สะพานเชื่อมขยายโดเมนความล้มเหลวร่วมและขอบเขตของนโยบาย ซึ่งเป็นการตัดสินใจเชิงสถาปัตยกรรม ไม่ใช่ช่องทำเครื่องหมายที่เขียนว่า NetBIOS จัดทำเอกสารการดำเนินการเฉพาะที่อุโมงค์ต้องขนส่ง แล้วผู้ดูแลระบบจะประเมินคำขอได้แทนที่จะเดาเรื่อง «เครือข่าย Windows ทั้งหมด»