ใช้ ipinfo ที่บ้าน: วิธีหาตำแหน่งของ IP ใน CLI ด้วยการวัด latency

• เครื่องมือ CLI ที่ใช้ latency เพื่อ ประมาณตำแหน่งของที่อยู่ IP ในระดับประเทศ·รัฐ·เมือง ได้
• ใช้ โพรบมากกว่า 3,000 ตัวของเครือข่าย Globalping เพื่อทำการวัด ping และ traceroute สำหรับแต่ละ IP
• เปรียบเทียบค่า latency แบบเป็นขั้นตอนจาก ทวีป → ประเทศ → รัฐ → เมือง แล้วตัดสินว่าพื้นที่ที่มีค่าต่ำสุดคือพิกัดจริง
• จากการทดสอบ พบความแม่นยำที่สอดคล้องกับผลของ ipinfo ในกรณีอย่าง โปแลนด์·ฟลอริดา·ไมอามี
• เป็น เครื่องมือ CLI โอเพนซอร์ส ที่ทุกคนรันได้ และพิสูจน์ให้เห็นถึง ความใช้งานได้จริงของการตรวจสอบตำแหน่ง IP แบบอิง latency

---

ภาพรวมของการประมาณตำแหน่ง IP แบบอิง latency

• ได้สร้าง เครื่องมือ CLI ที่สามารถระบุตำแหน่งที่อยู่ IP ได้ในระดับ ประเทศ รัฐของสหรัฐฯ และเมือง
  • GitHub repository: jimaek/geolocation-tool
• อ้างอิงกรณีที่ ipinfo พิสูจน์ว่า ผู้ให้บริการ VPN มีการ ลงทะเบียนข้อมูลตำแหน่งปลอม
  • ipinfo สร้าง เครือข่ายโพรบขนาดใหญ่ เพื่อ ติดตามและทดสอบ ping กับทุก IP สำหรับตรวจสอบตำแหน่งทางกายภาพจริง
• แนวทางนี้ช่วย ตัดปัญหาความคลาดเคลื่อนของข้อมูลสาธารณะ และทำให้สามารถระบุตำแหน่งได้อย่างน่าเชื่อถือโดยอิงจาก latency และข้อมูล hop

การใช้เครือข่าย Globalping

• Globalping เป็นโปรเจ็กต์โอเพนซอร์สที่ขับเคลื่อนโดยชุมชน และสามารถ โฮสต์โพรบแบบคอนเทนเนอร์ได้เอง
  • ปัจจุบันมี โพรบมากกว่า 3,000 ตัว กระจายอยู่ทั่วโลก
  • ผู้ใช้สามารถใช้เครือข่ายนี้ทำ การทดสอบเครือข่าย เช่น ping และ traceroute ได้
• เครื่องมือ CLI ทำงานอัตโนมัติด้วย ไลบรารี globalping-ts
  • ทดสอบ ping กับ IP ที่ป้อนเข้ามาจากหลายทวีป
  • เลือกทวีปที่มีค่า latency ต่ำที่สุด
  • จากนั้นจึงวัดละเอียดต่อด้วยโพรบหลายตัวภายในทวีปนั้น

โครงสร้างการวัดแบบเป็นขั้นตอน

• ขั้นที่ 1 (ตรวจหาทวีป) : ทดสอบ ping ด้วยโพรบ 5 ตัวต่อทวีป
  • ตัวอย่างผลลัพธ์: ยุโรป 32.39ms, อเมริกาเหนือ 137.18ms → เลือกยุโรป
• ขั้นที่ 2 (ตรวจหาประเทศ) : วัดด้วยโพรบ 50 ตัวภายในทวีปที่เลือก
  • ผลลัพธ์: โปแลนด์ 7.29ms, เยอรมนี 13.42ms, ลิทัวเนีย 17.65ms → ตัดสินเป็นโปแลนด์
• ขั้นที่ 3 (ตรวจหารัฐในสหรัฐฯ) : ทดสอบด้วยโพรบ 50 ตัวในสหรัฐฯ
  • IP ที่ NordVPN ระบุว่าอยู่ใน ‘บาฮามาส’ ถูกตัดสินว่าจริง ๆ อยู่ที่ ฟลอริดา (0.45ms)
• ขั้นที่ 4 (ตรวจหาเมือง) : วัดด้วยโพรบ 36 ตัวภายในรัฐ
  • ผลลัพธ์: ไมอามี (0.00ms) ตามด้วย West Palm Beach และ Tampa

ความแม่นยำและข้อจำกัด

• ‘magic field’ ของ Globalping จะสุ่มเลือกโพรบในระดับทวีป จึงอาจมีบางประเทศไม่ถูกเลือก
  • ทำให้มีโอกาสเกิด การตัดสินผิดเป็นประเทศเพื่อนบ้าน ได้
• หากต้องการเพิ่มความแม่นยำ ควร ระบุโพรบตามประเทศ·รัฐด้วยตนเอง และ ปรับจำนวนโพรบ
  • ตัวอย่าง: ในอเมริกาเหนือ แนะนำให้ใช้โพรบสหรัฐฯ 200 ตัว แคนาดา 20 ตัว เม็กซิโก 10 ตัว
• เวอร์ชันปัจจุบันใช้จำนวนโพรบน้อยที่สุดเพื่อให้ ผู้ใช้ที่ไม่ยืนยันตัวตนก็ยังรันได้
  • หากยืนยันตัวตนแล้วจะทดสอบได้ 500 ครั้งต่อชั่วโมง และเครดิตเพิ่มเติมสามารถรับได้จาก การโฮสต์โพรบหรือการสนับสนุนบน GitHub

การรันและการใช้งานเครื่องมือโอเพนซอร์ส

• คำสั่ง: geolocate $IP
  • ปรับจำนวนโพรบในแต่ละขั้นได้ด้วยออปชัน –limit
• สามารถดูวิธีใช้งานทั้งหมดได้จาก เอกสารบน GitHub
• ยินดีรับข้อเสนอแนะการปรับปรุงผ่าน Pull Request
• สามารถ ขอเครดิตฟรี และ เข้าร่วมโฮสต์โพรบ ได้
  • โฮสต์โพรบ: jsdelivr/globalping-probe

บทสรุป

• การประมาณตำแหน่ง IP แบบอิง latency เป็นวิธีที่ แม่นยำและใช้งานได้จริง หากมีจุดสังเกตมากเพียงพอ
• ด้วย เครือข่าย Globalping และเครื่องมือ CLI โอเพนซอร์ส ทุกคนสามารถตรวจสอบตำแหน่งจริงของ IP ได้อย่างง่ายดาย
• ยืนยันศักยภาพการนำไปใช้ในงานอย่าง การตรวจสอบการปลอมตำแหน่ง VPN การวิเคราะห์เส้นทางเครือข่าย และการดีบักประสิทธิภาพ

[GN⁺]

ความคิดเห็นจาก Hacker News

• เป็นโปรเจ็กต์เล็ก ๆ ที่ทดลองดูว่าสามารถทำ การประมาณตำแหน่งทางภูมิศาสตร์ ได้ด้วยบริการอย่าง Globalping หรือไม่
  ตอนนี้ยังเป็นแค่ระดับเดโม จึงยังไม่พอสำหรับใช้งานจริง
  ถ้าจะใช้อย่างจริงจัง แต่ละขั้นต้องมี probe อย่างน้อย 500 ตัว
  ผู้เขียนตั้งใจหลีกเลี่ยงการทำ optimization เพื่อไม่ให้เกินข้อจำกัดของผู้ใช้แบบไม่ระบุตัวตน
  • น่าจะลองใช้วิธีแบบ gradient descent ที่ลดจำนวน probe แต่ยังเพิ่มประสิทธิภาพได้
    เริ่มจากวัด 3 ครั้งในหลายทวีป แล้วตัด probe ที่ช้าที่สุดทิ้ง พร้อมเพิ่ม probe ใหม่ใกล้ฝั่งที่เร็วกว่า ทำซ้ำไปเรื่อย ๆ
    แบบนี้อาจ “ติดตาม” ตำแหน่งจริงได้แบบเรียลไทม์ แทนที่จะแบ่งเป็น 5 ขั้น
    แนวคิดคือมอง latency เป็น สนามศักย์สเกลาร์ แล้วใช้ความชันของมัน
  • ในทางทฤษฎี probe แค่ 3 ตัวก็น่าจะพอไม่ใช่หรือ?
• น่าประทับใจที่ทำโดยไม่ใช้ AI
  commit message ที่มีแค่คำเดียวก็ดูน่าขำ แต่กลับให้ความรู้สึกเป็นงานของมนุษย์ดี
  • ในโค้ดมีเส้นคั่น “══════” เลยทำให้รู้สึกว่าบางส่วนน่าจะถูกสร้างโดย Claude
• สงสัยว่าเซิร์ฟเวอร์เป้าหมายจะสามารถเพิ่ม latency แบบจงใจ ตาม source IP เพื่อหลอกตำแหน่งได้หรือไม่
  • ทำได้สบาย
    ตัวอย่างเช่นใช้เครื่องมืออย่าง fakeroute เพื่อหลอกได้แนบเนียนขึ้น
    อาจแทบไม่มีประโยชน์เชิงปฏิบัติ แต่เป็นไอเดียที่สนุกดี
  • ไม่ถึงกับทำไม่ได้ แต่แค่ไม่ตอบ ping ก็ง่ายขายกว่าเยอะ
  • traceroute เองก็เป็นเครื่องมือที่ตีความยากอยู่แล้ว จึง ปลอมแปลงได้ง่ายมาก
    เหมือนกรณีในอดีตที่ The Pirate Bay แกล้งทำเหมือนย้ายไปเกาหลีเหนือ โดย AS สามารถใส่ AS ปลอมเพิ่มในเส้นทาง BGP เพื่อให้ดูสมจริงขึ้นได้
    เทคโนโลยีแบบนี้อาจกลายเป็น เกมไล่จับกับ VPN ได้เหมือนกัน
    ดูเพิ่มเติม: การถกเถียงใน Reddit, กรณีใน HN
  • ISP ท้องถิ่นบางแห่งในสหรัฐฯ (เช่น Xfinity, Charter) มี latency แบบแฝงอยู่แล้วจาก Bufferbloat
    แม้แต่สาย 1000/30Mbps ก็ยังเกิด latency ได้ถึง 2500ms
• เคยเห็นแนวทางคล้ายกันในงานวิจัย ‘You Can’t Cheat Time’ ที่นำเสนอใน DEFCON 31
  วิดีโอบรรยาย
  ข้อจำกัดของการระบุตำแหน่งด้วย ping มีดังนี้:
  IP มักมีข้อมูลตำแหน่งอยู่ในฐานข้อมูลอยู่แล้ว, ความไม่สมมาตรของ routing ทำให้โมเดลระยะทางผิดเพี้ยน, Anycast/CDN ทำให้ IP เดียวอยู่ได้หลายภูมิภาค, และ ICMP อาจถูกบล็อกหรือมีลำดับความสำคัญต่ำ
  ฉันใช้โมเดล HTTP(S) latency + ML(SVR) แทน ping และฝึกด้วยข้อมูล 39,000 รายการ
  สำหรับเซิร์ฟเวอร์หลัง CloudFront ความคลาดเคลื่อนอยู่ราว 600 กม.
  สิ่งสำคัญยิ่งกว่าความแม่นยำคือ การตรวจจับ sandbox, มัลแวร์ geofence, และ การให้สัญญาณตำแหน่งเสริมเมื่อฐานข้อมูล IP ใช้ไม่ได้
  • ถ้าอยากหลบการติดตาม ก็สามารถเพิ่ม ดีเลย์แบบสุ่ม ให้ทุกแพ็กเก็ต หรือกำหนดกฎดีเลย์ตามแหล่ง ping เพื่อให้ดูเหมือนอยู่ในตำแหน่งที่ต้องการได้
• น่าแปลกที่วิธีนี้ยังใช้ได้ทั้งที่ latency แกว่งมาก
  เมื่อก่อนตอนคุยกับเพื่อนชาวดัตช์ ฉันเคยเข้าถึงคอนเทนต์ NL จากอังกฤษด้วย latency ต่ำกว่าที่เขาได้เสียอีก
  น่าจะเป็นเพราะ คุณภาพของ peering ต่างกัน
  • ฉันทำงานที่ IPinfo
    ตอนนี้กำลังทำโครงการแบ่งปันข้อมูล routing และ peering ร่วมกับ IXP และองค์กรอินเทอร์เน็ตหลัก ๆ
    บางประเทศมีการ peering ตรงกับ IXP ในอีกทวีปหนึ่ง ทำให้ latency ต่างกันระดับหลายพันกิโลเมตร
    ยังมีกรณีจริงที่ทราฟฟิกระหว่างผู้ให้บริการสองรายในประเทศเดียวกันต้องวิ่งออกนอกประเทศแล้วค่อยย้อนกลับมา
    ตอนนี้กำลังแก้ความผิดเพี้ยนเหล่านี้ด้วย อัลกอริทึมภูมิสารสนเทศที่อิงการวัดจริง
    เป้าหมายสุดท้ายคือช่วยให้ IXP, ผู้ให้บริการ, และองค์กรกำกับดูแลอินเทอร์เน็ต แก้ปัญหาเหล่านี้ได้
  • อาจเป็นแค่ latency ของสายเชื่อมต่อท้องถิ่น ก็ได้
    บน VDSL หรือ DOCSIS แค่ช่วง 1 กม. แรกก็ทำให้เกิด latency 5~15ms ได้แล้ว
    ระหว่างลอนดอน–อัมสเตอร์ดัมอยู่ที่ประมาณ 7ms
  • อาจเป็นเพราะรับคอนเทนต์จากแคชใน PoP ที่อยู่ใกล้กว่าก็ได้
    แต่ก่อนแม้แต่ในเมืองหลักของเนเธอร์แลนด์เองก็ยังมีไฟเบอร์ไม่มาก
  • จากเมืองของฉันไปเซิร์ฟเวอร์ในฝรั่งเศส ระยะเส้นตรงแค่ 250 กม. แต่ถ้าคิดจาก ping กลับออกมาเป็น 2000 กม.
    แปลว่าระยะถูก ขยายเกินจริงมากกว่า 8 เท่า
    เซิร์ฟเวอร์ในอังกฤษไกลกว่าแต่ ping กลับต่ำกว่า
    วิธีที่อิง traceroute จึงสมจริงกว่า ping
• ขอบคุณ Dimitry มาก ทีม IPinfo ทั้งทีมรู้สึกยินดีที่ถูกพูดถึง
  นักวิจัยของทีมชื่อ Calvin จะไปบรรยายเรื่อง ภูมิสารสนเทศ IP ที่อิงการวัดจริง ในงาน NANOG96
  ลิงก์การบรรยาย
• เป็นไอเดียและการลงมือทำที่ยอดเยี่ยมมาก
  อยากเห็นโปรเจ็กต์แบบนี้ใน HN มากขึ้น
• จากบทความดูเหมือนว่าเป็นการเลือกตำแหน่งจาก ping ที่สั้นที่สุด ตรง ๆ
  วิธีนี้เรียบง่ายเกินไป น่าจะใช้ triangulation เพื่อให้แม่นยำกว่านี้ได้
  • อย่างที่บทความบอกไว้ เป้าหมายคือแค่ proof of concept แบบง่าย ๆ
    ถ้ามี probe มากพอและโชคช่วยนิดหน่อย มันก็ทำงานได้ดีกว่าที่คิด
    แน่นอนว่ายังมีวิธีที่ฉลาดกว่านี้อีกเยอะ
  • แต่ แพ็กเก็ตไม่ได้วิ่งเป็นเส้นตรง ดังนั้นการคำนวณระยะทางตรง ๆ จึงไม่มีความหมาย
• ขอแชร์ประสบการณ์จากการใช้เทคนิคนี้ในสภาพแวดล้อมบริการจริง
  1. ในการ routing บนอินเทอร์เน็ต trilateration ใช้แทบไม่ได้ผล
     เพราะฉะนั้นในทางปฏิบัติจึงมักใช้ค่าการวัดเดี่ยวที่ใกล้ที่สุด
     ถ้าอยากได้ข้อมูลที่มีประโยชน์จริง ต้องมีโหนดระดับหลักพันต่อเมือง
  2. การวัดแบบนี้เหมาะกับการใช้ ตรวจสอบความถูกต้อง ของข้อมูลตำแหน่งที่มีอยู่มากกว่า
  3. hop ใน traceroute มีประโยชน์มากในการหาตำแหน่งของเราเตอร์
     RIPE IPmap แมปเราเตอร์สาธารณะส่วนใหญ่ไว้ได้ค่อนข้างแม่นแล้ว
  4. มันใช้ได้ดีกับ IP ของโครงสร้างพื้นฐานหรือเซิร์ฟเวอร์ แต่มีข้อจำกัดกับเครือข่ายผู้ใช้ทั่วไป
     ขอแนะนำ ping.sx เป็นเครื่องมือเปรียบเทียบด้วย
  • วิดีโองาน DEFCON ก็น่าดูเช่นกัน: https://youtu.be/_iAffzWxexA
• ถ้าดู IP route ของเส้นทางย้อนกลับ มักจะระบุได้ค่อนข้างแม่นถึงระดับรัฐในสหรัฐฯ
  FQDN ของ hop สุดท้ายมักมี รหัสสนามบินหรือรหัสเมือง รวมอยู่ด้วย ซึ่งช่วยได้มาก