การตรวจสอบเนื้อหาที่จำกัดตามภูมิศาสตร์สำหรับสตรีมมิ่งและการปฏิบัติตามข้อกำหนด

บริการสตรีมมิ่งส่วนใหญ่และแพลตฟอร์มที่อ่อนไหวต่อข้อกำหนดด้านการปฏิบัติตามกฎระเบียบไม่สามารถบังคับใช้ข้อจำกัดทางภูมิศาสตร์ (geo-restrictions) ได้อย่างถูกต้องบน IP ที่อยู่อาศัย (residential IPs) ถึง 60-80% ตามผลการตรวจสอบภายในของ CDN รายใหญ่สามแห่ง สาเหตุหลักไม่ใช่ฐานข้อมูล IP ที่มีคุณภาพต่ำ แต่เป็นขั้นตอนการทดสอบที่ไม่เคยทดสอบกรณีขอบ (edge cases) ที่ทำให้การกั้นตามภูมิศาสตร์ (geo-fencing) ใช้งานไม่ได้จริง วิศวกรที่มองว่าการบล็อกตามภูมิศาสตร์เป็นเพียงการค้นหาประเทศจาก IP แบบง่าย ๆ กำลังสร้างตะแกรงที่มีรูพรุน ไม่ใช่กำแพงกั้น

เหตุใดการค้นหา IP แบบง่ายถึงล้มเหลวในระดับใหญ่

วิธีการมาตรฐาน — การสอบถาม MaxMind หรือฐานข้อมูล GeoIP ที่คล้ายกันสำหรับ country_code — ใช้ได้กับ IP ของดาต้าเซ็นเตอร์และบล็อก ISP ขนาดใหญ่ แต่มันล้มเหลวอย่างรุนแรงสำหรับ IP ของผู้ให้บริการมือถือที่เราเตอร์ผ่านเกตเวย์กลางในอีกประเทศหนึ่ง สำหรับ ISP ดาวเทียมที่มีสถานีภาคพื้นดินในหลายเขตอำนาจศาล และสำหรับ IP ใด ๆ ที่ถูกจัดสรรก่อนที่เขตแดนทางภูมิรัฐศาสตร์ในปัจจุบันจะถูกกำหนด RFC 8805 กำหนดรูปแบบฟีดข้อมูลตำแหน่งทางภูมิศาสตร์ แต่ผู้ให้บริการส่วนใหญ่ยังคงให้ข้อมูลที่ล้าสมัยหรือรวมกลุ่มกัน การศึกษาในปี 2023 พบว่า 34% ของ IP ในฐานข้อมูล RIPE NCC มีรหัสประเทศที่ไม่ตรงกับที่อยู่ที่ลงทะเบียนของผู้ถือ IP การทดสอบกับฐานข้อมูลเพียงแห่งเดียวไม่ใช่การทดสอบ — มันคือการคิดไปเอง

การตรวจจับ VPN และพร็อกซี: ช่องทางเลี่ยงที่คุณไม่ได้ทดสอบ

บริการสตรีมมิ่งลงทุนอย่างหนักในบล็อกลิสต์ VPN แต่บล็อกลิสต์เหล่านั้นจะดีเท่ากับชุดทดสอบที่ใช้ตรวจสอบเท่านั้น ข้อผิดพลาดทั่วไปคือการทดสอบจากจุดสิ้นสุด VPN ที่รู้จัก (เช่น โหนดทางออกของผู้ให้บริการเชิงพาณิชย์) แล้วถือว่าเสร็จสิ้น ผู้โจมตีจริงจะหมุน IP ทุก 60 วินาที ใช้เครือข่ายพร็อกซีที่อยู่อาศัย (residential proxy networks) หรือทำอุโมงค์ผ่าน IP ทางออกของผู้ให้บริการคลาวด์ที่ยังไม่ถูกแฟล็ก ขั้นตอนการตรวจสอบที่เหมาะสมต้องรวมสคริปต์ที่ดึงรายการพร็อกซีเปิด (open proxies) โหนดทางออก VPN และรีเลย์ Tor ที่รู้จักจากฟีดสาธารณะ (เช่น https://check.torproject.org/exit-addresses) จากนั้นส่งคำขอไปยังจุดสิ้นสุดที่มีข้อจำกัดทางภูมิศาสตร์ของบริการของคุณและตรวจสอบสถานะการตอบกลับ นี่คือลูปทดสอบขั้นต่ำที่ใช้ curl และ jq:

#!/bin/bash
# Test geo-restricted endpoint against a list of suspicious IPs
ENDPOINT="https://api.example.com/geo/check"
while IFS= read -r ip; do
  result=$(curl -s -o /dev/null -w "%{http_code}" --resolve "api.example.com:443:$ip" "$ENDPOINT")
  if [[ "$result" != "403" ]]; then
    echo "FAIL: $ip returned $result (expected 403)"
  fi
done < /tmp/suspicious_ips.txt

สคริปต์นี้ใช้ --resolve เพื่อบังคับการเชื่อมต่อผ่าน IP ที่ระบุในขณะที่คงส่วนหัวโฮสต์เดิมไว้ — เทคนิคที่หลีกเลี่ยงการตรวจสอบ geo ระดับ CDN ส่วนใหญ่ หากบริการของคุณส่งคืน 200 หรือ 302 สำหรับ IP เหล่านั้น แสดงว่า geo-fencing ของคุณเสีย

ช่องว่างของ Geolocation IPv6 และ IP ผู้ให้บริการมือถือที่ครอบคลุมหลายประเทศ

ความแม่นยำของ geolocation IPv6 ต่ำกว่า 50% สำหรับหลายภูมิภาค โดยเฉพาะในยุโรปและเอเชียที่ผู้ให้บริการใช้พรีฟิกซ์ /32 เดียวสำหรับหลายประเทศ โทรศัพท์มือถือในสตราสบูร์ก ประเทศฝรั่งเศส อาจดูเหมือนมีต้นทางจากเครือข่ายหลักของผู้ให้บริการเยอรมันหากผู้ให้บริการใช้จุดยึด (anchor point) เดียว ส่วนหัว X-Forwarded-For มักมีที่อยู่ IPv4 ของเกตเวย์ NAT ของผู้ให้บริการ ไม่ใช่ที่อยู่ IPv6 ของผู้ใช้ ในการทดสอบนี้ ให้ส่งคำขอจากอุปกรณ์ทดสอบที่เชื่อมต่อกับเครือข่ายมือถือในพื้นที่ชายแดน (เช่น บาเซิล สวิตเซอร์แลนด์; เอลพาโซ เท็กซัส) และเปรียบเทียบผล geolocation จากบริการของคุณกับพิกัด GPS จริงของอุปกรณ์ หากความคลาดเคลื่อนเกิน 100 กม. ทีมปฏิบัติตามกฎระเบียบของคุณมีปัญหา — GDPR กำหนดให้การประมวลผลข้อมูลต้องเชื่อมโยงกับตำแหน่งจริงของผู้ใช้ ไม่ใช่ตำแหน่งของผู้ให้บริการ

การทดสอบการปฏิบัติตามกฎระเบียบที่เหนือกว่าการตรวจสอบ IP

GDPR และ COPPA ไม่สนใจผู้จำหน่ายฐานข้อมูล IP ของคุณ พวกเขาสนใจว่าผู้ใช้ในสหภาพยุโรปได้รับเนื้อหาที่สอดคล้องกับ EU หรือไม่ และผู้ใช้ที่อายุต่ำกว่า 13 ปีในสหรัฐอเมริกาถูกบล็อกไม่ให้เก็บรวบรวมข้อมูลส่วนบุคคลหรือไม่ การทดสอบข้อจำกัดทางภูมิศาสตร์เพื่อการปฏิบัติตามกฎระเบียบหมายความว่าคุณต้องตรวจสอบว่าการตอบสนองของบริการของคุณ — ไม่ใช่แค่รหัสสถานะ HTTP — เปลี่ยนแปลงอย่างถูกต้องตามตำแหน่งที่ตรวจพบ ตัวอย่างเช่น บริการสตรีมมิ่งที่ให้แคตตาล็อกต่างกันในแต่ละประเทศต้องมั่นใจว่าผู้ใช้ในสหราชอาณาจักรเห็นแคตตาล็อกของสหราชอาณาจักร ผู้ใช้ในฝรั่งเศสเห็นแคตตาล็อกของฝรั่งเศส และผู้ใช้ในดินแดนที่ไม่มีใบอนุญาตเห็นหน้า "ไม่พร้อมให้บริการ" การทดสอบควรรวมการตรวจสอบเนื้อหาการตอบกลับสำหรับสตริงเฉพาะภูมิภาค คุกกี้ และเป้าหมายการเปลี่ยนเส้นทาง การใช้ curl เพียงครั้งเดียวกับ --header "CF-IPCountry: GB" (หากคุณใช้ Cloudflare) เป็นการทดสอบแบบคร่าว ๆ ที่รวดเร็ว แต่มันทดสอบเฉพาะเลเยอร์ CDN ไม่ใช่ตรรกะของแอปพลิเคชันของคุณ สร้างชุดทดสอบที่ปลอมแปลงส่วนหัว X-Forwarded-For ด้วย IP จากแต่ละประเทศเป้าหมาย จากนั้นแยกวิเคราะห์การตอบกลับเพื่อหาตัวระบุเฉพาะที่รู้จัก (เช่น ฟิลด์ JSON "catalog": "uk")

การสร้างไปป์ไลน์ QA ที่ทำซ้ำได้

หยุดรันการทดสอบข้อจำกัดทางภูมิศาสตร์ด้วยตนเอง รวมการตรวจสอบเข้ากับไปป์ไลน์ CI/CD ของคุณโดยใช้เครื่องมือเช่น geoiplookup จากแพ็คเกจ geoip-bin ร่วมกับรายการ IP ที่ทราบว่าถูกระบุตำแหน่งผิดในฐานข้อมูลหลักของคุณ รันการทดสอบทุกครั้งที่คุณปรับใช้กฎ geo-fencing ใหม่ ใช้แนวทางหลายแหล่ง: สอบถาม MaxMind, IP2Location และ API RIPE NCC ฟรีสำหรับ IP ทดสอบแต่ละรายการ และทำให้บิลด์ล้มเหลวหากแหล่งข้อมูลส่วนใหญ่ไม่ตรงกับการตอบสนองของบริการของคุณ คำสั่งด้านล่างเปรียบเทียบการตัดสินใจของบริการของคุณกับฐานข้อมูลสามแห่ง:

#!/bin/bash
IP="1.2.3.4"
RESPONSE=$(curl -s "https://api.example.com/geo/check?ip=$IP" | jq -r '.country')
MAXMIND=$(geoiplookup "$IP" | awk '{print $4}')
IP2LOC=$(curl -s "https://api.ip2location.com/?ip=$IP&key=test" | jq -r '.country_code')
if [[ "$RESPONSE" != "$MAXMIND" && "$RESPONSE" != "$IP2LOC" ]]; then
  echo "WARNING: Geo response differs from majority of databases"
fi

ไม่มีฐานข้อมูลใดที่เชื่อถือได้อย่างสมบูรณ์ วิธีเดียวที่จะจับอัตราความล้มเหลว 60-80% ได้คือการทดสอบกับกรณีขอบในโลกจริง: IP ผู้ให้บริการมือถือ, พรีฟิกซ์ IPv6 และพร็อกซีที่อยู่อาศัย สิ่งที่น้อยกว่านั้นคือเหตุการณ์ไม่ปฏิบัติตามกฎระเบียบที่รอให้เกิดขึ้น