หลักการสื่อสารกับอุปกรณ์ที่ใช้ Private IP โดยไม่ต้องตั้งค่า port-forwarding บน router 1


โดย อานันท์ (โรเจอร์) สีห์พิทักษ์เกียรติ

ที่มา

เมื่อไม่นานมานี้ผู้เขียนได้ซื้อ IP Camera มาลองใช้ที่บ้าน ซึ่งจากประสบการณ์ในการใช้อุปกรณ์แนวนี้ก็คิดไว้ในใจว่าถ้าอยากเข้ามาดูจากเน็ตภายนอกบ้านก็คงต้องไปตั้งค่า router (ทำ port forwarding ตั้งค่า dyn DNS ฯลฯ) แต่ปรากฏว่าเจ้ากล้องที่ซื้อมาพอเชื่อมต่อเข้ากับเน็ตบ้านแล้วมันเข้ามาดูภาพตัวกล้องได้จากเน็ตข้างนอกโดยไม่ต้องไปยุ่งกับ router เลย เหตการณ์นี้ทำให้รู้สึกสองอย่างคือ กล้องมันเจ๋ง ใช้ง่าย ภาพชัดเจน ไม่หน่วงด้วย อย่างที่สองคืองงว่ามันทำได้ยังไง คิดตามหลักเท่าที่รู้เรื่อง IP จริง IP ปลอม (Public/Private IP) แล้วไม่เข้าใจจริงๆ ว่าเขาทำกันยังไง คำถามคือ มือถือเราเข้าถึง IP ปลอมของกล้องจากเน็ตภายนอกได้ยังไง

 

ผู้เขียนมีสมมุติฐานว่าผู้อ่านมีพื้นฐานความเข้าใจเกี่ยวกับระบบเครื่อข่ายโดยเฉพาะเรื่องหลักการทำ NAT มาแล้ว

คำตอบแรกที่เหมือนจะใช่ – UPnP/IGD

เนื่องจากบนกล่องของกล้องวงจรปิดที่ซื้อมามีความสามารถที่ชื่อ PnP (Plug-and-Play) ติดมา เลยใช้คำนี้เป็นตัวตั้ง ใช้เวลาค้นในเน็ตสักพักจึงไปพบเจ้า UPnP (Universal Plug-and-Play) เข้า ซึ่งเป็นมาตรฐานการสื่อสารข้อมูลวิดีโอ,ภาพ และอย่างอื่นๆ ซึ่งอาจเคยเห็นกันมาบ้างเวลาใช้โปรแกรมพวก XBMC/Kodi หรือทีวีที่สนับสนุน DLNA ดูๆ ไปแล้วมันไม่ค่อยเกี่ยวเท่าไหร่แต่ไปพบว่า UPnP มีความสามารถหนึ่งที่ชื่อ IGD ซึ่งดูจะตอบคำถามของผมได้เป็นอย่างดี

UPnP/IGD

เจ้า IGD (Internet Gateway Device Protocol) นี้สร้างขึ้นมาใช้กับการเล่นเกมออนไลน์, การสื่อสารแบบ Peer-to-Peer, Remote Desktop ซึ่งคิดๆ ไปแล้วงานทั้งหมดนี้มักเป็นการสื่อสารกับ Private IP ทั้งสิ้น (เมื่อก่อนใช้อย่างเดียวไม่เคยสงสัยว่ามันทำงานยังไง) หลักการสำคัญของ IGD ถ้าพูดให้ง่ายๆ คือ อุปกรณ์ที่ใช้ Private IP สามารถขอข้อมูล NAT ของมันจาก router ได้ (รู้สึกว่าจะสั่งให้ router สร้าง, ลบ, กำหนด Lease time ฯลฯ ได้ด้วย [อ้างอิง]) ซึ่งอุปกรณ์ที่ใช้ Private IP นี้ก็สามารถส่งข้อมูลดังกล่าวขึ้นไปไว้ที่ server ที่ไหนสักที่ได้ ใครที่ต้องการสื่อสารกับอุปกรณ์นี้ก็สามารถถามข้อมูลนี้จาก server แล้วทำการเชื่อมต่อได้เลย

เงื่อนไขการใช้ UPnP/IGD คือ router ต้องสนับสนุนโปรโตคอลนี้ ซึ่งเห็นว่า router ตามบ้านส่วนใหญ่ใช้ได้ (ของบ้านผมเองก็มี)

 

example network fixed

กรณีศึกษา

สมมุติว่าเราต้องการเชื่อมต่อมือถือเข้ากับกล้อง IP Camera ที่ใช้ UPnP/IGD ดังภาพข้างต้นสิ่งที่ควรจะเกิดขึ้นมีดังนี้

  1. พอกล้องต่อเข้ากับเน็ตได้ IP = 192.168.1.100 ซึ่งเป็น Private IP กล้องก็จะทดลองติดต่อกับ server สักตัวหนึ่งที่อยู่บนอินเตอร์เน็ต (ซึ่งใช้ Public IP) เพื่อให้ router สร้าง NAT รายการใหม่ขึ้นมา (หรือว่ามันสามารถสั่งงาน router ให้สร้างรายการ NAT ขึ้นมาโดยไม่ต้องส่งข้อมูลก็ได้ อันนี้ไม่แน่ใจ แต่คิดว่าวิธีแรกง่ายกว่า)  เช่น ข้อมูลที่ออกจากกล้องอาจบอกว่าส่งจาก 192.168.1.100:45315 ไปยัง 100.0.0.1:80 (45315 คือเลขพอร์ทต้นทางซึ่งเป็นค่าสุ่ม) พอผ่าน NAT บน router ข้อมูลต้นทางก็จะกลายเป็นส่งจาก 200.0.0.1:45315 (Public IP) ไปยัง 100.0.0.1:80 พร้อมสร้างรายการในตาราง NAT ว่ามีการแปลง 192.168.1.100:45315 เป็น 200.0.0.1:45315  (บางครั้งเลขพอร์ทอาจไม่เหมือนเดิมด้วย แต่ก็ไม่มีผลอะไร)
  2. กล้องก็จะขอข้อมูลรายการ NAT ที่เกิดขึ้นจากข้อ 1 มาเก็บไว้  (192.168.1.100:45315 แปลงเป็น 200.0.0.1:45315) router ที่สนับสนุน UPnP จะสามารถส่งข้อมูลนี้ให้ได้
  3. กล้องจะส่งข้อมูล Public IP ที่ได้จากรายการ NAT ( 200.0.0.1:45315) ไปยัง server ซึ่งสมมุติว่าคือตัวเดิมในข้อ 1 เป็นการบอกกับโลกข้างนอกว่าถ้าอยากติดต่อกับกล้องให้ติดต่อมาที่ 200.0.0.1:45315 ซึ่งต้องส่งเลข ID หรือ serial number ของตัวกล้องไปด้วย
  4. โทรศัพท์มือถือต้องติดตั้ง App และบันทึกเลข ID ของกล้องลงไป (ตัวที่ผมใช้เขียนติดอยู่ใต้เครื่อง มี 2D bar code ให้ใช้มือถือยิงได้)
  5.  เมื่อโทรศัพท์ต้องการติดต่อกับกล้อง ก็จะเริ่มจากการไปถาม server ว่า ID ของกล้องนี้ใช้ IP และ port อะไร ซึ่ง server ก็จะส่ง 200.0.0.1:45315 มาให้
  6. โทรศัพท์ก็ติดต่อไปยัง 200.0.0.1:45315 ซึ่งพอมาถึงตัว Router มันก็จะแปลงต่อ (ข้อมูลตาราง NAT มีอยู่แล้วจากข้อ 1) ให้กลายเป็น 192.168.0.100:45315 เพื่อให้สามารถติดต่อกับกล้องได้ในที่สุด

เท่าที่ศึกษามา XBOX live, Play Station Network รวมทั้งโปรแกรมบิตทอร์เรนท์ Transmission ใช้ UPnP ในการสื่อสารกับ Private IP [อ้างอิง]

ข้อสังเกต:

  • ถ้าใครเคยทำ port forwarding และ Dynamic DNS มาอย่างผมก็อาจจะรู้สึกว่าวิธีการนี้มันก็คล้ายๆ กัน เพียงแต่ส่วน forwarding อย่างเกิดขึ้นโดยอัตโนมัติ และ Dynamic DNS ก็เปลี่ยนจากการใช้ชื่อ Host เป็นการใช้เลข ID แต่จุดเด่นของวิธีใหม่นี้คือทุกอย่างเกิดขึ้นเองโดยอัตโนมัติ

ผมนึกว่าถึงบางอ้อในเรื่องนี้แล้ว แต่พอผมลองเข้าไปปิดบริการ UPnP ของ router และ restart เพื่อให้เลข Public IP มันเปลี่ยน โดยคาดหมายว่าจะทำให้เข้าดูกล้องจากเน็ตภายนอกไม่ได้ ปรากฏว่ามันยังใช้งานได้! ผมเลยชักงง ว่าตกลงมันใช้ UPnP หรือไม่ และนอกจาก UPnP แล้วยังมีมาตาฐานอื่นที่ใช้กันอีกหรือไม่ ค้นไปค้นมาจึงไปเจอคำตอบที่สองดังนี้

คำตอบที่สองที่ลงตัว – STUN, TURN, ICE

หลังจากค้นคว้าเพิ่มเตอมสักพักผมก็ไปพบวิธีที่ไม่ต้องใช้ความสามารถพิเศษของ Router แต่อย่างใด (UPnP ตัว router ต้องสนับสนุน) ซึ่งมาตรฐานนี้มาเป็นชุด  โดยวิธีการจะไม่ต่างจาก UPnP มากนักแต่จะมีส่วนของ Server มาให้ด้วย นอกจากนั้นวิธีนี้รู้สึกว่าจะเป็นที่ยอมรับมากกว่า เช่น โครงการ WebRTC ก็สนับสนุนวิธีการนี้ (Chrome กับ Firefox สามารถคุยกับ STUN Server ได้ผ่าน Java Script เลย)

STUN (Session Traversal Utilities for NAT)

ทำงานเกือบเหมือน UPnP ทุกอย่าง เพียงแต่มี STUN server กับ STUN client มาให้เป็นคู่ ในคณะที่ UPnP ไม่ได้พูดถึงส่วนของ server (เพราะคุมตัว router ได้เอง) ตัว client จะส่งข้อมูลไปยัง server แล้ว ตัว server จะยิงข้อมูลฝั่ง public IP กลับไปให้กับ client (UPnP จะถามเอาจาก router) ดังนั้น router จะไม่รู้เลยว่ากำลังเกิดอะไรขึ้น

example stun network

กรณีศึกษา

สมมุติกรณีเดียวกันกับตัวอย่าง UPnP ข้างต้นคือโทรศัพท์ต้องการคุยกับกล้องที่ใช้ STUN ซึ่งอยู่ใน Private network จะมีขั้นตอนดังนี้

  1. พอกล้องต่อเน็ตได้ IP = 192.168.1.100 ก็จะติดต่อไปยัง STUN server บนเน็ตซึ่งใช้ IP จริง (ผมพบว่ามี public STUN server ให้ใช้กันได้ด้วยนะครับ) เรียกว่า STUN Binding Request
    การส่งข้อมูลไปที่ Server นี้จะทำให้ router สร้าง NAT รายการใหม่ขึ้นมา เช่น ข้อมูลที่ออกจากกล้องอาจบอกว่าส่งจาก 192.168.1.100:45315 ไปยัง 100.0.0.1:80 (45315 คือเลขพอร์ทต้นทางซึ่งเป็นค่าสุ่ม) พอผ่าน NAT บน router ข้อมูลต้นทางก็จะกลายเป็นส่งจาก 200.0.0.1:45315 (Public IP) ไปยัง 100.0.0.1:80 พร้อมสร้างรายการในตาราง NAT ว่ามีการแปลง 192.168.1.100:45315 เป็น 200.0.0.1:45315
  2. Stun server จะส่งข้อมูล Public IP และเลข Port กลับมาใน Payload ของข้อมูลให้กล้องรับทราบ ดังนั้นกล้องจะรู้ว่าโลกภายนอกสามารถติดต่อตนเองได้โดยใช้ 200.0.0.1:45315
  3. กล้องจะส่งเลข ID หรือ Serial Number ของตนรวมทั้ง Public IP ที่ได้จากข้อ 2 ไปยัง Application server (อาจเป็นคนละเครื่องกับ STUN Server) เพื่อเก็บไว้
  4. ขึ้นตอนที่เหลือจะเหมือนกับข้อ 4-6 ของ UPnP
  5. โทรศัพท์มือถือต้องติดตั้ง App และบันทึกเลข ID ของกล้องลงไป (ตัวที่ผมใช้เขียนติดอยู่ใต้เครื่อง มี 2D bar code ให้ใช้มือถือยิงได้)
  6.  เมื่อโทรศัพท์ต้องการติดต่อกับกล้อง ก็จะเริ่มจากการไปถาม Application server ว่า ID ของกล้องนี้ใช้ IP และ port อะไร ซึ่ง server ก็จะส่ง 200.0.0.1:45315 มาให้
  7. โทรศัพท์ก็ติดต่อไปยัง 200.0.0.1:45315 ซึ่งพอมาถึงตัว Router มันก็จะแปลงต่อ (ข้อมูลตาราง NAT มีอยู่แล้วจากข้อ 1) ให้กลายเป็น 192.168.0.100:45315 เพื่อให้สามารถติดต่อกับกล้องได้ในที่สุด

ข้อสังเกต

  • วิธีการนี้จะใช้งานได้เมื่อรายการในตาราง NAT บน router ยังคงอยู่ เนื่องจาก router ไม่ทราบว่ามีการใช้ STUN ดังนั้นข้อมูลในตารางนี้จะอยู่นานเพียงใดจะขึ้นอยู่กับนโยบายของตัว router เอง (เท่าที่ลองหาๆ ดูนิดหน่อย มีตั้งแต่ 5 นาที ถึง 5 วัน) ดังนั้น STUN client คงต้องมีการยิง update ตัวเองไปยัง STUN server อยู่บ่อยๆ เพื่อรักษาตาราง NAT ให้ใช้งานได้

วิธีการนี้จะใช้ไม่ได้กับ router ที่ใช้ Symmetric NAT (มักเป็น router ในองค์กรที่ต้องรักษาความปลอดภัย) เพราะ NAT ชนิดนี้จะกำหนดตายตัวเลยว่าต้นทางกับปลายทางต้องเป็น IP ที่ใช้ตอนสร้างรายการเท่านั้น (192.168.1.100 กับ 100.0.0.1 ในตัวอย่าง) ดังนั้นพอโทรศัพท์ซึ่งมี IP อื่นพยายามเข้าถึงกล้องมันก็จะถูกปฏิเสธ (ผมใช้เครือข่ายมหาวิทยาลัยเชียงใหม่ดูกล้องที่บ้านไม่ได้ก็เดาว่าเป็นด้วยเหตนี้ หรือไม่ก็มีนโยบาย firewall กั้นไว้) สถานการณ์นี้จะใช้ TURN เข้ามาช่วย

TURN (Traversal Using Relays around NAT)

พูดง่ายๆ  TURN จะทำตัวเป็น Proxy หรือตัวกลางในการรับส่งข้อมูลระหว่าต้นทางกับปลายทางในกรณีที่ต้นทางคุยกับปลายทางโดยตรงไม่ได้ ถ้าเป็นกรณีของกล้องรูปภาพทั้งหมดจะถูกส่งไปยัง TURN Server ก่อนแล้วจึงส่งมายังโทรศัพท์ ข้อดีของวิธีนี้คือใช้งานได้กับ router ทุกตัว แต่ข้อเสียก็ชัดเจนว่าเป็นการส่งข้อมูลสองต่อ สร้างภาระให้กับ TURN server และทำงานช้ากว่า

ICE (Interactive Connectivity Establishment)

เนื่องจากเราสามารถสื่อสารได้สองแบบคือ STUN และ TURN ดังนั้น ICE จึงถูกสร้างมาเพื่อช่วยเลือกว่า ณ ขณะนั้นควรใช้วิธีใด ถ้าใช้ STUN ได้ก็จะเลือก STUN ก่อน (เพราะประสิทธิภาพดีที่สุด) ถ้าไม่อย่างนั้นก็จะใช้ TURN แทน

หมายเหตุ

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

Link ที่เกี่ยวข้อง


Leave a comment

Your email address will not be published. Required fields are marked *

One thought on “หลักการสื่อสารกับอุปกรณ์ที่ใช้ Private IP โดยไม่ต้องตั้งค่า port-forwarding บน router

  • Eak

    เป็นประโยชน์มากๆครับ กำลังศึกษาเรื่องนี้อยู่พอดี