สร้างฐานข้อมูลระบุตำแหน่งภูมิศาสตร์ของ IP จากศูนย์

 (ipapi.is)
5 คะแนน โดย GN⁺ 2023-09-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ฐานข้อมูลระบุตำแหน่งภูมิศาสตร์ของ IP จะเชื่อมช่วง IP เข้ากับ ประเทศ·เมือง·รหัสไปรษณีย์·เขตเวลา·พิกัด โดย ipapi.is มีทั้งฐานข้อมูล CSV ฟรีและฐานข้อมูลเชิงพาณิชย์แบบ CSV/MMDB
  • รุ่นฟรีครอบคลุมพื้นที่ IPv4·IPv6 ได้ไม่ครบทั้งหมดและมีความแม่นยำต่ำกว่า แต่รุ่นเชิงพาณิชย์เป็น ฐานข้อมูลฉบับเต็ม ที่ใช้กับฟิลด์ location ของ API และอัปเดตอย่างน้อยสัปดาห์ละ 2 ครั้ง
  • หากจะสร้างเอง ต้องใช้ทั้ง geoloc·geofeed จาก WHOIS, การอนุมานตำแหน่ง จากฟิลด์ที่อยู่·คำอธิบายใน WHOIS และโครงการสาธารณะอย่าง RIPE IPmap·geofeed-finder·OpenGeoFeed ร่วมกัน
  • ความแม่นยำอาจสั่นคลอนเมื่อเครือข่ายกระจายอยู่หลายพื้นที่ หรือมีการจัดสรรใหม่·ให้เช่า IP โดย ณ เดือนกรกฎาคม 2023 ของ RIPE NCC ค่า coverage ของ geoloc อยู่ที่ 2.3% และ coverage ของ URL geofeed อยู่ที่ 0.17%
  • ข้อมูลที่เก็บมาแล้วจำเป็นต้อง เสริมข้อมูล·ทำมาตรฐาน เช่น หา พิกัดจากเมือง·ประเทศ หรือหาเมืองที่ใกล้ที่สุดจากพิกัด โดย ipapi.is ใช้ไฟล์ข้อมูลรหัสไปรษณีย์·เมือง·ประเทศของ GeoNames

โครงสร้างของฐานข้อมูลระบุตำแหน่งภูมิศาสตร์ของ IP

  • IP to Geolocation Database คือฐานข้อมูลที่เก็บข้อมูลตำแหน่งภูมิศาสตร์ตามช่วง IP
  • ที่อยู่ IP สามารถระบุตำแหน่งได้ด้วยข้อมูลต่อไปนี้
    • ประเทศ เมือง รัฐ รหัสไปรษณีย์
    • เขตเวลา
    • ละติจูด ลองจิจูด
  • ฐานข้อมูลของ ipapi.is แบ่งเป็นรุ่นฟรีและรุ่นเชิงพาณิชย์
    • รุ่นฟรีดาวน์โหลดได้ในรูปแบบ CSV
    • รุ่นเชิงพาณิชย์มีให้ทั้งรูปแบบ CSV และ MMDB
    • รุ่นเชิงพาณิชย์ครอบคลุมพื้นที่ IPv4·IPv6 ทั้งหมด
    • รุ่นฟรีมีเพียงบางส่วนของพื้นที่ IPv4·IPv6
  • ฐานข้อมูลเชิงพาณิชย์อัปเดต อย่างน้อยสัปดาห์ละ 2 ครั้ง

ความต่างระหว่างรุ่นฟรีกับรุ่นเชิงพาณิชย์

  • ฐานข้อมูลระบุตำแหน่งภูมิศาสตร์ของ IP แบบฟรีมี จำนวนรายการน้อยกว่า รุ่นเชิงพาณิชย์ และไม่ครอบคลุมพื้นที่ที่อยู่ IPv4·IPv6 ทั้งหมด
  • รุ่นฟรีมีความแม่นยำของตำแหน่งภูมิศาสตร์ต่ำกว่า
  • แหล่งข้อมูลหลักของรุ่นฟรีคือข้อมูล WHOIS และ RFC 8805 Geofeeds
  • ฐานข้อมูลเชิงพาณิชย์คือฐานข้อมูลฉบับเต็มที่ใช้กับฟิลด์ location ของ API ของ ipapi.is
  • รุ่นเชิงพาณิชย์คำนวณตำแหน่งจากหลายแหล่งข้อมูลร่วมกัน
    • ระเบียน WHOIS
    • การวัด latency แบบ active จาก ping และ traceroute
    • RFC 8805 Geofeeds
    • การค้นหา reverse DNS

ฟอร์แมตฐานข้อมูลและฟิลด์ความแม่นยำ

  • ไฟล์ฐานข้อมูลอยู่ในรูปแบบ CSV หรือ MMDB
  • ฟิลด์หลักจะเก็บช่วง IP ตำแหน่ง พิกัด และความแม่นยำไว้ด้วยกัน
    • ip_version: IPv4 คือ 4, IPv6 คือ 6
    • start_ip, end_ip: IP เริ่มต้น·สิ้นสุดของช่วงเครือข่าย
    • continent, country_code, country, state, city, zip
    • timezone, latitude, longitude
    • accuracy
  • accuracy ใช้ระบุระดับความแม่นยำโดยประมาณของข้อมูลตำแหน่งภูมิศาสตร์ตั้งแต่ 1 ถึง 5
    • 1: แม่นยำสูงมาก โดยปกติไว้ใจได้ถึงระดับเมือง
    • 2: แม่นยำสูง โดยทั่วไปไว้ใจได้ถึงระดับเมือง
    • 3: แม่นยำปานกลาง ไม่น่าเชื่อถือมากนักในระดับเมือง
    • 4: แม่นยำต่ำ โดยปกติแม่นในระดับประเทศ
    • 5: แม่นยำต่ำมาก คาดหวังได้เพียงระดับประเทศ

วิธีดูตัวอย่าง MMDB

  • สามารถดาวน์โหลดตัวอย่าง MMDB ได้ด้วย curl
  • สามารถอ่านตัวอย่างด้วย mmdbctl
    • mmdbctl read -f json-pretty 0.239.249.144 locationSample.mmdb
  • ตัวอย่างผลลัพธ์จะคืนข้อมูลต่อไปนี้สำหรับ IP 0.239.249.144
    • เมือง Copenhagen
    • ประเทศ Denmark
    • พิกัด 55.67594, 12.56553
    • เครือข่าย 0.239.249.144-0.239.249.151
    • แหล่งที่มา geofeed|https://api.arelion.com/public/v1/geolocation

การใช้งานและข้อจำกัดของการระบุตำแหน่ง IP

  • การระบุตำแหน่งภูมิศาสตร์ของ IP คือกระบวนการแมปที่อยู่ IP เข้ากับ ตำแหน่งทางภูมิศาสตร์ ที่นิยามด้วยละติจูด·ลองจิจูด
  • ธุรกิจและผู้ให้บริการออนไลน์นำข้อมูลตำแหน่งภูมิศาสตร์ไปใช้ได้หลายรูปแบบ
    • โฆษณาแบบกำหนดกลุ่มเป้าหมาย
    • การตรวจจับและป้องกันการทุจริต
    • การทำเนื้อหาให้เหมาะกับท้องถิ่น
    • DRM และการปฏิบัติตามข้อกำหนด
    • ความปลอดภัยเครือข่าย
    • การวิเคราะห์และอินไซต์
  • มีเหตุผลเชิงโครงสร้างที่ทำให้การระบุตำแหน่ง IP ไม่แม่นยำเสมอไป
    • เครือข่าย IPv4·IPv6 ที่ได้รับการจัดสรรอาจกระจายอยู่หลายพื้นที่ทางภูมิศาสตร์
    • มีเครือข่ายที่ออกแบบมาให้ครอบคลุมหลายพื้นที่ เช่น เครือข่ายมือถือหรือเครือข่ายดาวเทียม
    • เมื่อ Regional Internet Registry หรือบริษัทให้เช่า IP มีการจัดสรรใหม่หรือจัดสรรต่อ เครือข่าย IP ตำแหน่งก็อาจเปลี่ยนได้
  • การระบุตำแหน่งที่อยู่ IP เป็นเรื่องซับซ้อน แต่ก็สามารถให้ความแม่นยำในระดับที่ API ที่อยู่ IP มองข้ามได้ยาก

งานที่ต้องทำเมื่อสร้างจากศูนย์

  • ที่อยู่ IP แต่ละรายการบนอินเทอร์เน็ตมีองค์กรใดองค์กรหนึ่งเป็นเจ้าของหรือดูแล
  • Regional Internet Registry(RIR) เช่น ARIN และ APNIC จะเก็บข้อมูลความเป็นเจ้าของไว้ในฐานข้อมูล WHOIS
  • ระเบียน WHOIS ไม่ได้มีข้อมูลตำแหน่งภูมิศาสตร์ของเครือข่ายที่จัดสรรไว้อยู่เสมอไป
  • องค์กรเจ้าของเครือข่ายสามารถใช้ IP ในตำแหน่งทางภูมิศาสตร์ที่ต้องการได้ และยังอาจจัดสรรให้บุคคลที่สามหรือปล่อยเช่าบล็อก IP ได้ด้วย
  • การรวบรวมข้อมูลตำแหน่งภูมิศาสตร์แบ่งใหญ่ ๆ ได้เป็น 3 แนวทาง
    • ดึงข้อมูลตำแหน่งโดยตรง เช่น geoloc, geofeed จากระเบียน WHOIS
    • อนุมานตำแหน่งทางอ้อม จากที่อยู่ไปรษณีย์ คำอธิบาย และข้อมูลประเทศใน WHOIS
    • ใช้โครงการสาธารณะอย่าง RIPE IPmap, geofeed-finder, OpenGeoFeed

ข้อมูลตำแหน่งโดยตรงแยกตาม RIR

  • RIPE NCC

    • อ็อบเจ็กต์ inetnum, inet6num ของ RIPE NCC ใช้จัดสรรเครือข่าย IP ให้กับองค์กร
    • ข้อมูลตำแหน่งภูมิศาสตร์อาจให้ผ่าน 2 แอททริบิวต์คือ geoloc และ geofeed
    • geoloc เก็บละติจูดและลองจิจูดในรูปแบบสตริง
    • ตัวอย่าง: 47.855374 12.132041
    • ณ เดือนกรกฎาคม 2023 ฐานข้อมูลของ RIPE NCC มี inetnum 4,190,644 รายการ และ inet6num 819,381 รายการ
    • ในจำนวนนี้มีอ็อบเจ็กต์ที่มีแอททริบิวต์ geoloc อยู่ 114,389 รายการ คิดเป็น coverage รวม 2.3%
    • geofeed เก็บ URL ของไฟล์ CSV ตามรูปแบบ RFC 8805
    • URL ของ geofeed อาจถูกบันทึกไว้ในแอททริบิวต์ geofeed โดยตรง หรือในรูปแบบ Geofeed {URL} ภายในแอททริบิวต์ remarks
    • ณ เดือนกรกฎาคม 2023 RIPE NCC มี URL geofeed ในแอททริบิวต์ remarks จำนวน 6,643 รายการ และมีระเบียน WHOIS ที่มีแอททริบิวต์ geofeed จำนวน 2,035 รายการ
    • coverage ของ URL geofeed อยู่ที่ 0.17% แต่ตัวเลขนี้อาจทำให้เข้าใจผิดได้ เพราะไฟล์ geofeed หนึ่งไฟล์อาจครอบคลุมหลายเครือข่าย

  • ARIN

    • ARIN ให้ข้อมูลตำแหน่งภูมิศาสตร์โดยใส่ URL ของ geofeed ไว้ในแอททริบิวต์ Comment ของอ็อบเจ็กต์ NetRange
    • เคยมีการขอเพิ่มแอททริบิวต์ geofeed โดยเฉพาะ แต่ถูกปฏิเสธด้วยเหตุผลว่า Comment หรือ Remark ก็เพียงพอแล้ว
    • ต่างจาก RIPE NCC ฐานข้อมูลของ ARIN ไม่ใช้แอททริบิวต์ geoloc

  • LACNIC

    • LACNIC มีความกระตือรือร้นเรื่องการรองรับตำแหน่งภูมิศาสตร์มากกว่า ARIN
    • LACNIC ให้บริการ Geofeed Service ที่สมาชิกสามารถส่งข้อมูลตำแหน่งภูมิศาสตร์ของที่อยู่ IP ที่ถือครองอยู่ได้
    • ข้อมูลสาธารณะมีให้ที่ milacnic.lacnic.net/lacnic/geofeeds
    • ฐานข้อมูล WHOIS ของ LACNIC ให้ข้อมูลตำแหน่งภูมิศาสตร์ในระดับเมืองโดยปริยาย
    • สามารถดาวน์โหลดฐานข้อมูลของ LACNIC ได้จากเซิร์ฟเวอร์ FTP ftp.lacnic.net/lacnic/dbase/

  • AFRINIC และ APNIC

    • AFRINIC ระบุว่าไม่ได้ให้บริการตำแหน่งภูมิศาสตร์ และไม่มีความสัมพันธ์อย่างเป็นทางการหรือเชิงปฏิบัติการกับผู้ให้บริการตำแหน่งภูมิศาสตร์
    • AFRINIC รองรับการใช้ URL geofeed ในแอททริบิวต์ remarks คล้ายกับ RIPE NCC
    • APNIC รองรับตำแหน่งภูมิศาสตร์ในระดับใกล้เคียงกับ RIPE NCC
      • แอททริบิวต์ geoloc
      • URL geofeed ในแอททริบิวต์ remarks
    • APNIC แสดงท่าทีเปิดกว้างต่อการปรับปรุงการรองรับข้อมูลตำแหน่งภูมิศาสตร์

วิธีอนุมานตำแหน่งจาก WHOIS

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

  • การอนุมานใน RIPE NCC

    • ในอ็อบเจ็กต์ inetnum, inet6num ของ RIPE NCC แอททริบิวต์ที่นำมาใช้ได้มีดังนี้
      • country: ให้ความแม่นยำได้เพียงระดับประเทศ
      • descr: คำอธิบายเครือข่าย ซึ่งอาจมีข้อมูลตำแหน่ง·ที่อยู่
      • netname: แยกวิเคราะห์ได้ยากและความน่าเชื่อถือต่ำ
      • address: โดยเคร่งครัดแล้วเป็นแอททริบิวต์ของอ็อบเจ็กต์ role และเก็บที่อยู่ไปรษณีย์
    • แอททริบิวต์ country ระบุรหัสประเทศแบบตัวอักษร ISO 3166-2 แต่ไม่ได้บอกว่าประเทศนั้นเป็นที่ตั้งสำนักงานใหญ่ ดาต้าเซ็นเตอร์ หรือผู้ใช้ปลายทาง
    • แอททริบิวต์ descr เป็นคำอธิบายแบบอิสระ แต่บางองค์กรใส่ข้อมูลตำแหน่งเครือข่ายและที่อยู่ไว้ ทำให้มีประโยชน์ต่อการอนุมานตำแหน่งภูมิศาสตร์
    • address อาจให้ความแม่นยำสูงได้ แต่หากสมมติว่าที่อยู่ไปรษณีย์ของอ็อบเจ็กต์ role ตรงกับสถานที่ใช้งานของที่อยู่ IP ก็อาจทำให้เกิดข้อผิดพลาด

  • การอนุมานใน ARIN

    • ใน ARIN แอททริบิวต์ WHOIS ต่อไปนี้ค่อนข้างเชื่อถือได้สำหรับองค์กรขนาดเล็ก หรือองค์กรที่กระจุกอยู่ในสถานที่เดียว
      • Address
      • City
      • StateProv
      • PostalCode
      • Country
    • องค์กรอย่างมหาวิทยาลัย โรงพยาบาล หรือหน่วยงานรัฐ อาจใช้งานที่อยู่ IP ในอ็อบเจ็กต์ NetRange ณ สถานที่เดียวกับที่อยู่ไปรษณีย์สำหรับการบริหารจัดการ
    • แต่ในกรณีของบริษัทใหญ่หรือองค์กรระดับประเทศที่มี NetRange จำนวนมาก ที่อยู่ไปรษณีย์สำหรับการบริหารจัดการอาจไม่ตรงกับสถานที่ใช้งาน IP จริง
    • ตัวอย่าง Google Fiber หากใช้ที่อยู่จาก WHOIS จะถูกระบุเป็น Mountain View, California แต่ผู้ให้บริการตำแหน่งภูมิศาสตร์ส่วนใหญ่จะระบุ IP นั้นว่าอยู่ที่ San Antonio, Texas

  • LACNIC, AFRINIC, APNIC

    • LACNIC ให้ข้อมูลตำแหน่งภูมิศาสตร์อยู่แล้วในฐานข้อมูล WHOIS จึงไม่จำเป็นต้องอนุมานเพิ่มเติม
    • AFRINIC ใช้ฟอร์แมตฐานข้อมูล WHOIS แบบเดียวกับ RIPE NCC จึงใช้หลักการเดียวกันได้
      • country, descr
      • address ของอ็อบเจ็กต์ role
    • APNIC ก็ใช้ฟอร์แมตฐานข้อมูล WHOIS แบบเดียวกับ RIPE NCC เช่นกัน จึงใช้หลักการเดียวกัน

โครงการตำแหน่งภูมิศาสตร์สาธารณะ

  • RIPE IPmap

    • RIPE IPmap เคยเป็น API ที่ให้ข้อมูลตำแหน่งภูมิศาสตร์ของโครงสร้างพื้นฐานอินเทอร์เน็ตหลัก
    • ดูเหมือนว่าจะไม่ได้รับการบำรุงรักษาอีกต่อไป และดูเหมือนว่าไม่มีคอนทริบิวชันใหม่หลังปี 2019
    • RIPE IPmap อนุมานตำแหน่งภูมิศาสตร์ของที่อยู่ IP ด้วยหลายเอนจิน
    • เอนจิน latency และ single-radius ใช้ค่าการวัดจาก RIPE Atlas เพื่อให้รัศมี latency ของที่อยู่ IP
    • ค่าการวัด RTT ต่ำสุดให้ขอบบนของระยะทางสูงสุดที่เป็นไปได้ เนื่องจากข้อจำกัดความเร็วแสงในสื่อใยแก้วนำแสง
    • เอนจิน reverse-dns ดึงตำแหน่งระดับเมืองจากชื่อโฮสต์ในระเบียน PTR
    • สามารถดาวน์โหลดฐานข้อมูล RIPE IPmap ได้จาก https://ftp.ripe.net/ripe/ipmap/
    • ความแม่นยำและ coverage ของโครงการนี้ลดลงมากตามข้อมูลในเว็บไซต์ของผู้ดูแลเดิม

  • geofeed-finder

    • geofeed-finder เป็นเครื่องมือโอเพนซอร์สสำหรับค้นหาและดึงไฟล์ geofeed จากข้อมูล WHOIS
    • เครื่องมือนี้ยังตรวจสอบความเป็นเจ้าของ prefix, จัดการแคช และตรวจสอบรหัส ISO ด้วย
    • สามารถดึง geofeed จากข้อมูล WHOIS ได้ตาม RFC 9092
    • เนื่องจาก coverage ของข้อมูล geofeed ในเครือข่ายทั้งหมดต่ำมาก ประโยชน์ในการใช้งานจริงจึงมีจำกัด

  • LACNIC Geofeeds Service และ OpenGeoFeed

    • LACNIC Geofeeds Service ให้ข้อมูลตำแหน่งภูมิศาสตร์ของสมาชิก LACNIC จำนวนมาก
    • ข้อมูลเปิดให้ดาวน์โหลดสาธารณะที่ milacnic.lacnic.net/lacnic/geofeeds
    • เป็นโครงการสำคัญในแง่ที่แสดงให้เห็นว่าสามารถเก็บข้อมูลตำแหน่งภูมิศาสตร์ได้ในระดับ RIR
    • OpenGeoFeed เป็นโครงการโอเพนซอร์สที่รวบรวม geofeed สาธารณะที่เผยแพร่เองตาม RFC 9092
    • OpenGeoFeed มีไฟล์เดียวที่รวมไฟล์ geofeed สาธารณะที่ทราบทั้งหมดไว้ที่ opengeofeed.org/feed/public.csv
    • OpenGeoFeed ดูมีอนาคต แต่ดูเหมือน coverage ของ geofeed จะไม่อัปเดตนัก และมีโอกาสต่ำที่แหล่งข้อมูลจะได้รับการอัปเดตบ่อย

การเสริมข้อมูลและการทำมาตรฐาน

  • ข้อมูลตำแหน่งภูมิศาสตร์ดิบที่รวบรวมมาจากหลายแหล่งอาจไม่สมบูรณ์หรือไม่สอดคล้องกัน
  • อาจมีทั้งระเบียนที่มีข้อมูลประเทศ·เมืองแต่ไม่มีพิกัด และระเบียนที่มีพิกัดแต่ไม่มีข้อมูลประเทศ·เมือง
  • หากระเบียนต้นทางมีเพียงประเทศ ความแม่นยำก็มักไปได้ไม่เกินระดับประเทศ
  • ข้อมูลที่รวบรวมมาจำเป็นต้อง เสริมข้อมูล·แปลงให้อยู่ในฟอร์แมตร่วมกัน
  • การเสริมข้อมูลทำโดยใช้ฐานข้อมูลภูมิศาสตร์โอเพนซอร์ส
  • งานเสริมข้อมูลแบ่งเป็น 2 กรณี
    • ค้นหาละติจูดและลองจิจูดจากคู่เมือง·ประเทศ
    • ค้นหาเมืองและประเทศที่ใกล้ที่สุดจากละติจูด·ลองจิจูด
  • ipapi.is ใช้ฐานข้อมูลต่อไปนี้ในการเสริมข้อมูลตำแหน่งภูมิศาสตร์
    • GeoNames Postal Code Files: รหัสไปรษณีย์ทั่วโลก โดยยกเว้นบางประเทศด้วยเหตุผลทางกฎหมาย
    • cities500.zip: เมืองที่มีประชากรมากกว่า 500 คน
    • countryInfo.txt: เมทาดาทาของประเทศ เช่น เมืองหลวง ประชากร และทวีป

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

1 ความคิดเห็น

 
GN⁺ 2023-09-15
ความคิดเห็นจาก Hacker News

  • ผมอ่านบทความของเขามาตั้งแต่ก่อนเข้าร่วม IPinfo แล้ว และที่ IPinfo เราให้บริการ ข้อมูลตำแหน่งทางภูมิศาสตร์ของ IP
    เราใช้วิธีที่ขยายต่อจากแนวทางที่อธิบายไว้ที่นี่ และแม้จะใช้ชุดข้อมูลสาธารณะบางส่วน แต่ข้อมูลตำแหน่งหลักมาจาก การวัดแบบอิง ping
    เราส่ง ping ไปยังที่อยู่ IP จากเซิร์ฟเวอร์หลายแห่งทั่วโลก แล้วใช้การวัดพหุภาคี (multilateration) เพื่อระบุตำแหน่ง ping จากเซิร์ฟเวอร์เดียวให้ข้อมูลหนึ่งมิติได้แค่ว่าอยู่ที่ไหนสักแห่งในรัศมีหนึ่ง แต่ถ้าทำซ้ำจากหลายเซิร์ฟเวอร์ ตำแหน่งก็จะค่อย ๆ แม่นยำขึ้น
    หากวัดมากพอ ก็สามารถไปถึงความแม่นยำใกล้ระดับรหัสไปรษณีย์ได้ ปัจจุบันมีเซิร์ฟเวอร์ตรวจจับมากกว่า 600 เครื่องทั่วโลก และยังเพิ่มขึ้นเรื่อย ๆ
    ข้อมูลสาธารณะมักเก่า หรือไม่ได้อัปเดตบ่อย โดยทั่วไปไม่ละเอียดพอจะเป็นประโยชน์ และมักให้แค่ตำแหน่งระดับช่วง IP ขนาดใหญ่หรือระดับองค์กร
    นอกจากนี้ ชุดข้อมูลสาธารณะไม่มีขั้นตอนตรวจสอบความถูกต้อง เมื่อการซื้อขาย IPv4 และบริการ VPN เพิ่มขึ้น เราเคยเห็นกรณีที่มีการใส่ข้อมูลที่ไม่ถูกต้องเข้ามา ดังนั้นแม้เรายินดีรับรายงานแก้ไขตำแหน่ง IP แต่จะต้องตรวจสอบเสมอ
    จากประสบการณ์ในการดำเนินงานเครือข่ายตรวจจับ การซื้อเซิร์ฟเวอร์ในนิวยอร์กนั้นง่ายและถูกกว่าประเทศใดประเทศหนึ่งในแอฟริกากลางมาก ตำแหน่งของที่อยู่ IP ส่งผลอย่างมากต่อมูลค่าที่ IP นั้นให้ได้
    เรายังมีฐานข้อมูล IP-to-Country ASN ฟรีสำหรับใช้ในโปรเจกต์ด้วย: https://ipinfo.io/developers/ip-to-country-asn-database

    • สงสัยว่าเป็นแฟนบทความไหน บทความใน https://incolumitas.com/ หรือ https://ipapi.is/?
      ไอเดีย การสามเหลี่ยมจากเวลาแฝง ดีมาก ผมเคยใช้ข้อมูลเวลาแฝงเพื่อหลายอย่าง เช่น การตรวจจับ VPN และพร็อกซี แต่ไม่คิดว่าจะได้ตำแหน่งที่แม่นขนาดนั้น
      ถ้าทำการสามเหลี่ยมจากเวลาแฝงด้วยเซิร์ฟเวอร์ 600 เครื่อง ก็น่าจะได้ค่าประมาณที่ค่อนข้างดี และน่าประทับใจ
      แต่มีบางอย่างที่สงสัย ISP บางรายจัดการทราฟฟิก ICMP ด้วยลำดับความสำคัญต่ำหรือทำให้ประสิทธิภาพลดลง รับมืออย่างไร, ถ้าจะระบุตำแหน่ง IPv4 ทั้งหมด ก็ต้อง ping ที่อยู่หลายพันล้านรายการต่อเนื่อง วัดแค่ IP สุ่มหนึ่งตัวจากแต่ละ inetnum/NetRange ที่ถูกจัดสรรหรือไม่, และที่อยู่ IP ส่วนใหญ่ไม่ตอบ ICMP จึงสงสัยว่าหาเราเตอร์หน้าปลายทางแล้วจับตำแหน่งเราเตอร์นั้นหรือไม่
    • ที่อยู่ anycast ระบุ “ตำแหน่ง” ด้วยเวลาในการตอบกลับ ICMP ได้ยาก และบางกรณีก็ผูกกับตำแหน่งเชิงตรรกะต่างหาก ดูตัวอย่างได้ที่ https://blog.cloudflare.com/icloud-private-relay/
    • ในฐานะทั้งแฟนและลูกค้าของ IPinfo ผมใช้ API เพื่อใส่ข้อความในอีเมลแจ้งเตือนการเข้าสู่ระบบ เช่น “คุณเพิ่งเข้าสู่ระบบจากเบอร์ลิน เยอรมนี หากไม่ใช่คุณ คลิกที่นี่”
      ยังใช้ให้ข้อมูลประเทศในบันทึก audit ของลูกค้า รวมถึงป้องกันสแปมและตรวจจับการฉ้อโกงด้วย
    • สงสัยว่าเคยพิจารณาทำให้ดาวน์โหลดฐานข้อมูลใน รูปแบบ Parquet ได้หรือไม่
      แบบนั้นจะคัดลอกไฟล์ไปยัง S3, Google Cloud ฯลฯ แล้ว query ได้ทันทีด้วยเครื่องมือหลายชนิด ถึง CSV ก็ทำได้ แต่ไม่ลื่นไหลเท่า
    • เคยสงสัยว่าระบุตำแหน่งที่อยู่ IP ได้อย่างไรเมื่อไม่มีแหล่งข้อมูลเดิม คำอธิบายนี้คือสิ่งที่อยากรู้พอดี เลยน่าสนใจมาก

  • ถ้าไม่อยากทำเอง สามารถให้ Cloudflare ทำให้ฟรีด้วย Cloudflare Worker ง่าย ๆ ได้ คำขอ Cloudflare ทุกครั้งมีข้อมูลตำแหน่ง IP แบบคร่าว ๆ อยู่แล้ว
    จะส่งคำขอไปยัง URL นี้ที่รันบน Cloudflare Worker ก็ได้ น่าจะมีเวลาแฝงต่ำทั่วโลก: https://www.edenmaps.net/iplocation
    ใช้กับแอปเล็ก ๆ ได้ไม่เป็นไร แค่ขอว่าอย่าส่งคำขอวันละ 10 ล้านครั้งก็พอ

    • ดาวน์โหลด ฐานข้อมูล IP มาใช้เองดีกว่า แทนที่จะแชร์กับบุคคลที่สามว่า IP ใดอาจเคยเข้าถึงบริการของคุณ
    • มันบอกว่าอยู่ห่างจากชายฝั่งโซมาเลีย 100 กม. แต่จริง ๆ ผมอยู่ที่บรัสเซลส์ เบลเยียม ขอบคุณสำหรับความเป็นส่วนตัว :D
    • สงสัยว่ามีใครรู้ไหมว่า ตำแหน่งทางภูมิศาสตร์ของ Cloudflare ในคำขอ Worker แม่นยำแค่ไหน
    • ยอดเยี่ยม ถ้าเป็นไปได้ สงสัยว่าจะเปิดโค้ดนั้นเป็น โอเพนซอร์ส ได้ไหม
    • ผมอยู่มิวนิก แต่ Cloudflare ชี้ไปยังป่าสุ่มแห่งหนึ่งทางเหนือห่างไป 730 กม.

  • ผมอาศัยอยู่ในประเทศที่ภาษาประจำชาติไม่ใช่ภาษาแม่ของผม เลยเกลียดเว็บไซต์ที่ คาดเดาภาษาจากตำแหน่ง IP แล้วบังคับใช้มาก
    ทั้งที่เบราว์เซอร์ส่ง header ภาษามาอย่างชัดเจนมาก แต่กลับมองข้ามมัน แล้วกำหนดภาษาจากสมมติฐานแบบขี้เกียจ

    • ผมทำงานในบริการระบุตำแหน่งทางภูมิศาสตร์ของ IP แต่ผมก็เกลียดเรื่องนี้เหมือนกัน
      ในวงการเรียกว่า “การปรับแต่งประสบการณ์เว็บให้เฉพาะบุคคล” แต่มันเป็นวิธีที่น่ารำคาญ ผมไม่เคยแนะนำให้ใครทำแบบนั้น
      ถ้าจะใช้ตำแหน่งทางภูมิศาสตร์ของ IP เพื่อปรับแต่งเว็บไซต์ สิ่งที่ดีที่สุดน่าจะเป็นเรื่องอย่างภาษี ค่าจัดส่ง หรือวางประเทศของผู้ใช้ไว้บนสุดในดรอปดาวน์เลือกประเทศ
      นอกนั้นแทบคิดอะไรไม่ออก การแปลมักทำงานได้ไม่ดีและมีแต่รบกวน ต่อให้เว็บไซต์มีเจตนาดี การทำเวอร์ชันท้องถิ่นด้วย Google Translate ก็ไม่ใช่ความคิดที่ดี
    • ผมอยู่ในสหรัฐฯ แต่ตำแหน่งทางภูมิศาสตร์ของ IP บนอุปกรณ์ทั้งหมดชี้ไปยังพื้นที่ผิด ๆ
      แทบไม่มีเทคโนโลยีไหนที่ทำลายประสบการณ์อินเทอร์เน็ตประจำวันได้เท่าฐานข้อมูลพวกนี้
      อยากให้มันหายไปเลย
      แทนที่เว็บไซต์จะเดาผิดทุกครั้ง แล้วซ่อนขั้นตอนแก้ไขไว้หลังลิงก์และการโหลดหน้าหลายรอบ ก็ถามรหัสไปรษณีย์ตอนโหลดครั้งแรกไปเลย
      อีกอย่าง ไม่มีวิธีแก้ฐานข้อมูลให้ได้ “คำตอบที่ถูกต้อง” หรือ “คำตอบที่ดีกว่า” ด้วย เพราะแทบไม่มีกรณีที่ต้องการให้เว็บไซต์ใช้ตำแหน่งปัจจุบันจริง ๆ
      โดยทั่วไปผมตรวจสต็อกสินค้าของร้านในสถานที่ที่กำลังจะไป สรุปคือทั้งสาขานี้กำลังพยายามแก้ ปัญหาที่นิยามผิด
    • หงุดหงิดแบบเดียวกันมากจนเขียนบทความเกี่ยวกับเรื่องนี้ไว้ด้วย: https://www.fer.xyz/2021/04/i18n

  • ขึ้นอยู่กับการใช้งานและระดับความแม่นยำที่ต้องการ
    วิธีที่ดีที่สุดในการสร้างบริการระบุตำแหน่งทางภูมิศาสตร์คือการมี อุปกรณ์ 1 พันล้านเครื่อง ที่รายงานตำแหน่งของตนเองพร้อมกับ IP ไปด้วยพร้อมกัน ในทางปฏิบัติ Apple และ Google อยู่ในตำแหน่งนี้
    เพราะพวกเขาได้รับการอัปเดต IP และตำแหน่งอย่างต่อเนื่อง จึงมีฐานข้อมูลระบุตำแหน่งทางภูมิศาสตร์ที่ดีที่สุดในโลก
    ประเด็นสำคัญคือการสร้างแอปที่ผู้คนยินยอมให้ตำแหน่งโดยสมัครใจ และทำให้มีคนใช้แอปนั้นจำนวนมาก นั่นจึงเป็นเหตุผลที่ทุกแอปในทุกวันนี้ขอสิทธิ์เข้าถึงตำแหน่ง
    Foursquare มาถูกทางแล้ว แต่ล้ำหน้าเกินไป

    • แม้เมื่อ 10 ปีก่อน นโยบายความเป็นส่วนตัวภายในของ Apple ก็ป้องกันไม่ให้ Apple เก็บพิกัดละติจูด/ลองจิจูดที่แม่นยำ
      ต้องใช้ telemetry ของ HTTP session เพื่อประเมินว่า endpoint ใดเหมาะที่สุดสำหรับ IP หรือ subnet หนึ่ง ๆ และผลลัพธ์ก็คือการสร้างฐานข้อมูลคล้าย GeoIP ของตัวเองตามเงื่อนไขจริง
      ถึงอย่างนั้น ด้วยเหตุผลด้านความเป็นส่วนตัว ก็ต้องเก็บไว้แบบชั่วคราวเท่าที่เป็นไปได้ ผลลัพธ์ reverse geocoding ของ Apple Maps ไม่สามารถใช้หรือบันทึกได้นอกบริบทคำขอผู้ใช้แบบเรียลไทม์ เช่น การหาร้านอาหารใกล้เคียง

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

    • ดูเหมือนความเป็นไปได้ตรงกันข้ามจะมากกว่า Google มี ฐานข้อมูลระบุตำแหน่งทางภูมิศาสตร์ของ IP ที่ดีมากอยู่แล้ว และเมื่อไม่มีข้อมูลอื่น ก็น่าจะใช้มันเป็นตำแหน่งสำหรับการสำรวจ
    • เพราะอย่างนั้นบางครั้งจึงแสดงว่าฉันอยู่ที่แม่น้ำที่ไปพายเรือบ่อย ๆ และบางครั้งก็แสดงเป็นสถานที่ที่มีบ้านพักฤดูร้อน
    • Google Workspace กับ data localization และการตัดสินเขตอำนาจของหน่วยงานบังคับใช้กฎหมายก็ใช้สิ่งนี้ด้วย

  • น่าสนใจ แต่ดูเหมือนว่าการระบุตำแหน่งทางภูมิศาสตร์จริง ๆ จะไม่ได้ทำกันแบบนี้
    ข้อมูล ARIN/RIPE ไม่แม่นยำพอเกินกว่าระดับประเทศ จึงไม่ค่อยมีประโยชน์
    บริการระบุตำแหน่งเชิงพาณิชย์จะเชื่อมโยง IP ของไคลเอนต์กับตำแหน่งจริงที่รู้จัก เช่น ข้อมูล WiFi AP หรือพัสดุที่ส่งถึงผู้ใช้ อย่างน้อยก็ได้ยินมาแบบนั้นมาหลายสิบปีแล้ว

    • ทำงานในวงการ ad tech และเราจัดการตำแหน่งทางภูมิศาสตร์แบบนั้น
      มีตำแหน่งของอุปกรณ์ด้วย แต่ถ้าผู้ใช้ไม่ยินยอมแชร์ข้อมูล GPS การทำ targeting จะใช้แค่ IP address ผู้ให้บริการที่พบบ่อยคือ MaxMind ซึ่งแจกจ่ายฐานข้อมูลให้โฮสต์ไว้ในเครื่องแล้ว query ได้

  • คอมเมนต์ค่อนข้างออกแนวถากถาง แต่โดยส่วนตัวแล้วรู้สึกว่าน่าสนใจมากจริง ๆ
    นึกถึงตอนงานแรกที่เพิ่ม PostGIS และการค้นหาตามตำแหน่งลงในฐานข้อมูล ตอนนั้นอิงจากที่อยู่และรหัสไปรษณีย์

    • ใน MySQL ก็ทำได้ค่อนข้างง่าย เคล็ดลับอย่างหนึ่งคือใช้ สี่เหลี่ยมจัตุรัส แทนวงกลม ซึ่งช่วยหลีกเลี่ยงการคำนวณทางคณิตศาสตร์ได้มาก

  • เมื่อนานมาแล้ว ผมสร้าง http://www.hostip.info ขึ้นมา เป็นบริการที่รวบรวมตำแหน่งของ IP address แบบชุมชน และใช้แนวทางประมาณว่า “การคาดเดานี้ผิดหรือเปล่า? ช่วยแก้ให้หน่อย”
    ครั้งสุดท้ายที่ตรวจดูน่าจะราว 10 ปีก่อน ประเทศแทบจะถูกต้องสมบูรณ์ ภูมิภาคยังไม่สมบูรณ์ และเมืองแม่นกว่าการโยนเหรียญเล็กน้อย ข้อมูลทั้งหมดฟรี
    ไม่แน่ใจว่ายังอยู่ในเว็บหรือไม่ แต่เคยมีลูกบาศก์ 3D หมุนได้เพื่อแสดงที่อยู่ที่รู้จักหรือการค้นหาล่าสุด โดย x, y, z คือ octet สามตัวแรกของที่อยู่ และใช้สีต่างกันตามกลุ่ม เช่น ประเทศหรือทวีป
    เก่ามากจนเขียนด้วย Java applet ถ้าสร้างใหม่ตอนนี้ก็คงใช้ WebGL
    ขายไปนานแล้ว แต่ใส่เงื่อนไขไว้ว่าข้อมูลต้องคงความฟรีเสมอ ตอนแรกข้อเสนอที่ส่งมาทางอีเมลดูเหมือนหลอกลวงจนไม่เชื่อ แต่ดำเนินการผ่าน escrow.com ได้ราบรื่น และคิดว่าทั้งสองฝ่ายจบลงอย่างพอใจ ตอนนี้ก็เกือบ 20 ปีมาแล้ว

  • ดูเหมือนเป็นเวอร์ชันสมัยใหม่ของ GeoIP แบบอิง ping ที่กล่าวถึงก่อนหน้า: https://github.com/Ne00n/yammdb

    • มันเพียงแค่ลิงก์ไปยัง ไฟล์ mmdb ที่คอมไพล์ไว้แล้ว ดังนั้นหาก implementation ไม่ได้เปิดเผย ก็ไม่มีสิ่งที่เกี่ยวข้องให้มองว่าเป็น implementation “สมัยใหม่” ได้เลย

  • อยากทราบข้อเสนอแนะเกี่ยวกับวิธี ระบุตำแหน่งทางภูมิศาสตร์ ของ IP ศูนย์ข้อมูล แม้จะเป็นแบบคร่าว ๆ มากก็ตาม
    กำลังวิเคราะห์ข้อมูล traceroute อยู่ และรู้ตำแหน่งต้นทางกับปลายทาง แต่สิ่งที่สนใจคือช่วงกลางทาง
    ตัวอย่างเช่น สามารถอนุมานข้อมูลบางอย่างได้จากรหัสสนามบินที่อยู่ใน hostname ของโหนด
    ภายใต้สมมติฐานว่าโหนดหนึ่ง ๆ ไม่ได้มีสถานะย่ำแย่ ก็น่าจะสามารถอนุมานตำแหน่งจากเวลา RTT เฉลี่ยได้เช่นกัน
    ตัวอย่าง IP ที่น่าปวดหัวคือ 193.142.125.129, 129.250.6.113, 129.250.3.250 ปรากฏใน traceroute ของสหราชอาณาจักรและคิดว่าอยู่ในลอนดอน แต่ผลการระบุตำแหน่งทางภูมิศาสตร์กระจัดกระจายไปทั่วโลก

    • IP เหล่านั้นเป็นของ Google และ NTT และทั้งคู่ต่างก็ให้บริการเครือข่ายระหว่างประเทศขนาดใหญ่ จึงสามารถย้าย IP ไปทั่วโลกได้หากต้องการ ดังนั้นการระบุตำแหน่งจากการ lookup จึงไม่นิ่งอย่างที่เห็นแล้ว
      traceroute ไปยัง IP เหล่านั้นดูเหมือนว่าเครือข่ายกำลังไปลอนดอน
      IP ของ Google ไม่ตอบ ping แต่ฝั่ง NTT/Verio ตอบ ถ้า ping จากโฮสติ้งที่ตั้งอยู่ในลอนดอน มีโอกาสสูงที่จะได้การตอบสนองในระดับมิลลิวินาทีหลักเดียว และนั่นจะช่วยกำหนดขอบเขตบนของระยะทางจากลอนดอนได้
      หากลอง ping จากโฮสติ้งอื่น ๆ ในสหราชอาณาจักรและอีกฝั่งของช่องแคบด้วย ก็จะตรวจสอบได้ว่า ping ต่ำสุดมาจากโฮสติ้งลอนดอนหรือไม่ อย่างไรก็ตาม อาจเป็นเพียงการเชื่อมต่อที่ผ่านลอนดอน ส่วนตำแหน่งจริงอาจอยู่ที่อื่น จึงไม่สามารถรู้ได้อย่างสมบูรณ์
      ควรตรวจสอบจากจุดสังเกตอื่น ๆ ด้วย เพื่อดูว่าไม่ใช่ anycast เมื่อ ping ไปยัง 8.8.8.8 จากเครือข่ายส่วนใหญ่ทั่วโลกจะเจอจุดที่อยู่ใกล้ แต่ IP เหล่านี้แม้ในพื้นที่ซีแอตเทิล traceroute ก็ยังไปลอนดอน ดังนั้นอย่างน้อยในตอนนี้ก็มีแนวโน้มสูงว่าไม่ใช่ anycast
      หากไม่มีโฮสติ้งทั่วโลก ก็ลองหา looking glass สาธารณะของเครือข่ายที่เชื่อมต่อดี ๆ ซึ่งสามารถใช้ ping แบบนี้ได้เป็นครั้งคราว
    • TULIP ดูมีแวว
      ระบุไว้ว่า “วัตถุประสงค์ของ TULIP คือการค้นหาตำแหน่งของโฮสต์เป้าหมายที่ระบุด้วยชื่อ IP หรือที่อยู่ IP โดยใช้การวัดความหน่วงของ ping RTT จากโฮสต์ landmark อ้างอิงที่ทราบตำแหน่งดีไปยังเป้าหมาย”
      https://tulip.slac.stanford.edu/
      แต่ endpoint สำหรับส่งคำขอดูเหมือนจะตายไปแล้ว
    • มีไอเดียบางอย่างใน https://ensa.fi/papers/geolocation_imc17.pdf
      วิธีดึง RTT จาก probe ของ RIPE Atlas ที่ทราบตำแหน่งไปยัง IP ดังกล่าวใกล้เคียงกับไอเดียที่พูดถึง และอย่างไรก็น่าจะเป็นวิธีที่ดีที่สุด
    • หากคุณให้บริการแอปหรือเว็บเซอร์วิสยอดนิยม ก็คงจะมี หมายเลข AS ของตัวเอง ซื้อ IP block หลายชุดภายใต้ AS นั้น แล้วโฆษณา address เหล่านั้นจากศูนย์ข้อมูลหลายแห่งทั่วโลกที่ตนเป็นเจ้าของหรือเช่าอยู่
      การประกาศ BGP แบบนี้จะออกไปยัง upstream ISP ต่างกันในหลายตำแหน่ง
      หาก upstream ของการประกาศจากตำแหน่งหนึ่งเป็น ISP ท้องถิ่น ก็พอจะคาดเดาได้ระดับหนึ่งว่าศูนย์ข้อมูลนั้นอยู่ในภูมิภาคนั้น แต่ถ้าเป็น Tier 1 ISP ที่ให้การเชื่อมต่อโดยตรงทั่วโลก แม้แต่การคาดเดานั้นก็ยังยาก
      ความสัมพันธ์ BGP สามารถดูได้จากเครื่องมือ looking glass เช่น bgp.tools: https://bgp.tools/prefix/193.142.125.0/24#connectivity
      หากสามารถรัน traceroute จาก probe หลายตัวที่กระจายอยู่ทั่วโลกและทราบตำแหน่ง ก็สามารถดู IP คงที่ของอินเทอร์เฟซเราเตอร์กลางทางแล้วทำ triangulation ได้
      อย่างไรก็ตาม ถ้าใช้ CDN อย่าง Cloudflare เพื่อโฆษณา IP block ของตัวเองจาก PoP กว่า 200 แห่ง และให้ทราฟฟิกวิ่งผ่านเครือข่ายส่วนตัวของพวกเขาไปยังศูนย์ข้อมูลทั่วโลก วิธีนี้ก็จะใช้ไม่ได้เช่นกัน