ใช้อินเทอร์เน็ตโดยไม่ต้องมีการเชื่อมต่อ IPv4

 (jamesmcm.github.io)
3 คะแนน โดย GN⁺ 2025-06-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้ในสถานการณ์ที่ การเชื่อมต่อ IPv4 ใช้งานไม่ได้ ก็ยังสามารถใช้อินเทอร์เน็ตทั้งหมดได้ผ่าน IPv6, WireGuard และ Hetzner VPS
  • เนื่องจาก Carrier Grade NAT (NAT ระดับผู้ให้บริการ) ทำให้เกิดปัญหาเฉพาะกับ IPv4 ขณะที่ IPv6 ไม่ได้รับผลกระทบ
  • ด้วยการตั้งค่า อุโมงค์ WireGuard และทำ tunneling ทราฟฟิก IPv4 ผ่าน VPS จึงสามารถกู้คืนสภาพแวดล้อมการใช้งานเว็บไซต์ได้ตามปกติ
  • มีการอธิบายวิธีใช้ network namespace และ Docker รวมถึงวิธีแก้ปัญหา MTU
  • เน้นประสบการณ์การแก้ปัญหาเครือข่ายที่ซับซ้อนด้วยตนเองด้วย สภาพแวดล้อม Linux และเครื่องมือโอเพนซอร์ส

ภาพรวม

เมื่อไม่กี่วันก่อน ผู้เขียนประสบปัญหา การเชื่อมต่อ IPv4 หลุด จากเราเตอร์ที่บ้านหลังไฟดับ โชคดีที่ การเชื่อมต่อ IPv6 ยังใช้งานได้ปกติ จึงยังเข้าเว็บไซต์บางส่วนได้ (เช่น Google, Meta) แต่เว็บไซต์ส่วนใหญ่ (เช่น GitHub) ยังเข้าไม่ได้ ผู้เขียนจึงสรุปขั้นตอนการใช้ Linux, WireGuard และ Hetzner VPS เพื่อ กู้คืนสภาพแวดล้อมการใช้อินเทอร์เน็ตทั้งหมดด้วย IPv6 เพียงอย่างเดียว

สาเหตุของปัญหาและพื้นหลัง

พบความผิดปกติของสภาพแวดล้อมเครือข่าย

  • ระหว่างกระบวนการกู้คืนหลังไฟดับ พบว่า เซิร์ฟเวอร์ IPv6 ยังเข้าถึงได้ตามปกติ แต่ เซิร์ฟเวอร์ IPv4 ไม่สามารถเข้าถึงได้
  • ผลจากการรันคำสั่งวินิจฉัย (ping -6, traceroute) ก็แสดงให้เห็นเพียงความแตกต่างตามเวอร์ชันของ IP
  • หลังสอบถาม จึงพบว่ามีปัญหาในการแปลง IPv4 ที่ชั้น CG-NAT (Carrier Grade NAT) ของฝั่งผู้ให้บริการอินเทอร์เน็ต
  • คาดว่าต้องใช้เวลาหลายวันกว่าฝั่ง ISP จะซ่อมเสร็จ จึงจำเป็นต้องแก้ปัญหาเอง

คำอธิบาย NAT และ CG-NAT

  • NAT (Network Address Translation) : วิธีที่ทำให้อุปกรณ์หลายเครื่องแชร์ public IPv4 address เดียวกันได้
    • เราเตอร์จะแปลง IP ภายในเป็น public IP พร้อมพอร์ตเฉพาะเพื่อจัดการทราฟฟิก และเมื่อส่งกลับก็ใช้ข้อมูล mapping เพื่อคืนปลายทางภายใน
    • โครงสร้างนี้ทำให้เกิดบทบาทเป็น ไฟร์วอลล์โดยปริยาย และทำให้ต้องมีการทำ port forwarding
  • CG-NAT (Carrier Grade NAT) : โครงสร้างแบบหลายชั้นที่ ISP นำ NAT มาใช้อีกชั้นหนึ่ง กับเราเตอร์ของแต่ละครัวเรือน
    • ISP ใช้ NAT ซ้อนภายในเพื่อรับมือกับปัญหาการขาดแคลน IPv4 address
    • ในสภาพแวดล้อม CG-NAT การให้บริการอย่าง port forwarding จะยิ่งถูกจำกัดมากขึ้น
    • สาเหตุที่มีปัญหาเฉพาะทราฟฟิก IPv4 ก็เพราะการประมวลผลแพ็กเก็ต IPv4 มีปัญหาในชั้นนี้

ข้อดีของ IPv6

  • พื้นที่ address ของ IPv6 มีขนาดใหญ่มากจนสามารถแจก address ให้แต่ละอุปกรณ์ได้โดยตรงโดยไม่ต้องพึ่ง NAT
    • เราเตอร์ตามบ้านส่วนใหญ่มักได้รับ subnet แบบ /64 ซึ่งรองรับ address ได้มหาศาล
  • จึงสามารถสื่อสารกันได้โดยตรงโดยไม่ต้องมี NAT แยกต่างหาก แต่การตั้งค่าไฟร์วอลล์ยิ่งมีความสำคัญมากขึ้น
  • CG-NAT ใช้กับ IPv4 เท่านั้น ดังนั้นในเหตุการณ์นี้จึงมีเพียง IPv6 ที่ยังทำงานได้ตามปกติ
  • อย่างไรก็ตาม เซิร์ฟเวอร์จำนวนมาก (เช่น GitHub) ก็ยังไม่สามารถเข้าถึงได้ด้วย IPv6 เพียงอย่างเดียว

กู้คืน IPv4 ด้วยอุโมงค์ WireGuard

ภาพรวมของการติดตั้งใช้งาน

  • ใช้ Hetzner VPS (รองรับทั้ง IPv4/IPv6 stack) และ WireGuard เพื่อสร้างสภาพแวดล้อมที่ยังเข้าถึงอินเทอร์เน็ตทั้งหมดได้แม้จะเชื่อมต่ออินเทอร์เน็ตด้วย IPv6 เท่านั้น
    • รัน WireGuard server บน VPS และสร้างอุโมงค์กับอุปกรณ์ไคลเอนต์
    • ทราฟฟิกจะวิ่งอ้อมไปยัง VPS ผ่าน IPv6 ทำให้สามารถเข้าถึงทุกเว็บไซต์ (รวมถึง IPv4) ผ่าน VPS ได้
    • หลักการคล้ายกับ Dual-Stack Lite

ตัวอย่างการตั้งค่าเซิร์ฟเวอร์และไคลเอนต์

  • การตั้งค่า WireGuard server รองรับทั้งทราฟฟิก IPv4 และ IPv6
    • มีตัวอย่างกฎ MASQUERADE (แปลง IP แบบไดนามิก) และ SNAT (แปลง IP แบบคงที่)
    • ใช้ global IPv6 ที่ได้รับการจัดสรรโดยตรงเพื่อเชื่อมต่อกับ WireGuard peer ได้ทันทีโดยไม่ต้องมี NAT
    • สามารถระบุรายการ PostUp/PostDown หลายครั้งเพื่อรันคำสั่งแต่ละตัวตามลำดับได้
  • ตัวอย่างการตั้งค่าไคลเอนต์
    • อธิบายตัวอย่างการใช้ direct IPv6 address หรือการใช้ ULA ที่ถูก NAT
    • กำหนด AllowedIPs เป็น 0.0.0.0/0, ::/0 เพื่อทำ tunneling ทราฟฟิกทั้งหมดได้
    • มีวิธีตั้งค่า Google DNS (IPv4, IPv6) และ MTU

อุโมงค์ทำงานได้ตามปกติ

  • หลังตั้งค่า WireGuard ทั้งสองฝั่งเสร็จ ก็สามารถทำ tunneling ได้ตามปกติทั้ง IPv4 และ IPv6
  • ผู้เขียนยังนำวิธีเดียวกันไปใช้กับพีซีของภรรยา และติดตั้ง Linux WireGuard client ได้อย่างสะดวก
  • อย่างไรก็ตาม โดยทั่วไปแล้ว ไม่สามารถเชื่อมต่อพร้อมกับ VPN ของบริษัทได้ จึงจำเป็นต้องใช้ network namespace เพิ่มเติม

Network namespace และ Docker

ความสามารถและวิธีใช้งาน

  • ใช้เครื่องมืออย่าง vopono เพื่อสร้าง network namespace แยกตามแอปพลิเคชัน และระบุ VPN หรืออินเทอร์เฟซ WireGuard ให้กับ namespace นั้นโดยตรง
    • จำเป็นต้องกำหนดกฎ MASQUERADE แยกต่างหาก เพื่อบังคับให้ทราฟฟิกภายในวิ่งผ่านอุโมงค์ WireGuard
    • มีเคล็ดลับการตั้งค่า DNS แบบแยกจากภายนอก และ gai.conf (การตั้งค่า DNS ให้เลือก IPv4 ก่อน) รวมอยู่ด้วย
  • มีตัวอย่างการใช้งานแบบ เชื่อมต่อ VPN และรันแอปพลิเคชันภายใน namespace
    • การรันหลายบริการใน namespace เดียวกันช่วยป้องกันปัญหาความขัดแย้งด้านเครือข่ายล่วงหน้าได้

การใช้งานร่วมกับ Docker container

  • Docker daemon ใช้ host network socket เป็นค่าปริยาย ดังนั้น เพียงแค่รันใน namespace ปกติจะไม่สามารถเข้าถึงได้
    • มีการเสนอ workaround ด้วยเทคนิค virtualization ของ Unix เช่น mount namespace และ bind mount ของ /sys
    • รัน dockerd ภายใน namespace พร้อมกำหนด socket และ data root แยกต่างหาก เพื่อกู้คืนการเชื่อมต่ออินเทอร์เน็ตภายใน container
    • มีการกล่าวด้วยว่าในสภาพแวดล้อม network bridge ที่ซับซ้อนอาจต้องมีการตั้งค่าเพิ่มเติม

ปัญหา WireGuard MTU (MTU: Maximum Transmission Unit)

  • หลังเชื่อมต่อ WireGuard แล้วพบว่าเข้าได้เพียงบางเว็บไซต์เท่านั้น (เช่นปัญหา SSL) แม้ ping จะตอบกลับได้ตามปกติ
  • จากการทดสอบ ping หลายขนาด จึงระบุสาเหตุได้ว่า MTU สูงเกินไปจนทำให้แพ็กเก็ตขนาดใหญ่ถูกทิ้งระหว่างทาง
    • เมื่อลด MTU ลงเป็น 1280 ปัญหาก็ได้รับการแก้ไขทันที
  • MTU คือขนาดสูงสุดของแพ็กเก็ตที่สามารถส่งได้ในครั้งเดียว
    • ต้องตั้งค่า MTU ให้เหมาะสมโดยคำนึงถึง overhead ของ tunnel/encapsulation ไม่เช่นนั้นอาจเกิดปัญหาการเชื่อมต่อเมื่อส่งแพ็กเก็ตขนาดใหญ่
    • ตามสเปก IPv6 กำหนด MTU ขั้นต่ำไว้ที่ 1280

บทสรุปและคำแนะนำการนำไปใช้

  • เน้นย้ำประสบการณ์ การวินิจฉัยและแก้ปัญหาเครือข่ายด้วยตนเอง โดยใช้ Linux และเครื่องมือโอเพนซอร์ส เช่น การสร้าง WireGuard VPN server, การจัดการ network namespace, การตั้งค่าพิเศษสำหรับ Docker และการไล่ปัญหา MTU
  • บริการอย่าง Hetzner VPS มีความเสถียรคุ้มราคา และเหมาะกับการรันบริการเครือข่ายที่ถูกต้องตามกฎหมายอย่าง WireGuard
  • มีการประเมินคุณค่าของเฟิร์มแวร์เราเตอร์โอเพนซอร์ส (OpenWRT) และเทคนิคเครือข่ายบน Linux ใหม่อีกครั้ง
    • ความยืดหยุ่นในการจัดการและปรับแต่งเครือข่ายได้ด้วยตนเอง เป็นข้อได้เปรียบสำคัญมากในสภาพแวดล้อมการทำงานระยะไกล
    • หากมีความเข้าใจและการฝึกฝนเพียงพอ ก็สามารถแก้ปัญหาเครือข่ายที่ซับซ้อนได้ด้วยตนเอง

เอกสารอ้างอิง

  • Tailscale – How NAT Traversal Works
  • ArchWiki – ตัวอย่าง use case ของ WireGuard
  • Unix StackExchange – Docker tricks ภายใน namespace
  • AskUbuntu – การตั้งค่าลำดับความสำคัญของ DNS

(สคริปต์, config, เคล็ดลับ และลิงก์อ้างอิงที่เกี่ยวข้อง ดูได้จากต้นฉบับ)

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

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

 
GN⁺ 2025-06-30
ความเห็นบน Hacker News

  • ชื่อเรื่องอาจทำให้เข้าใจผิดไปนิด เพราะจริง ๆ แล้วบทความนี้ใกล้เคียงกับ “เชื่อมต่อไปยัง VPS ผ่าน IPv6 tunnel แล้วใช้เข้าถึงอินเทอร์เน็ต IPv4” มากกว่า ซึ่งโดยทั่วไปเรียกว่า 4in6
    อย่างไรก็นับว่าเป็นแนวทางที่น่าสนใจ
    จากประสบการณ์ของผม ถ้า IPv4 ของ ISP มีปัญหา ระบบจะล่มทั้งก้อนทันที เลยกลายเป็นเคสซัพพอร์ตที่ค่อนข้างตรงไปตรงมา แต่ถ้า IPv6 มีปัญหา อาการจะออกมาแบบบางส่วนเสีย ทำงานผิดปกติแปลก ๆ เช่น ต่อช้า หรือใช้ได้บ้างไม่ได้บ้าง
    โดยเฉพาะถ้าเกตเวย์เข้าใจผิดว่ามี IPv6 ปัญหาจะยิ่งน่าปวดหัวสำหรับผู้ใช้ เพราะจะออกมาในรูปแบบที่มีแค่บางฟังก์ชันใช้ไม่ได้

    • ไม่นานมานี้ตอน IPv4 ล่มไปชั่วคราว ผมเพิ่งมารู้ตัวก็เพราะ Github ใช้งานไม่ได้
      เดี๋ยวนี้เว็บไซต์ผู้บริโภคส่วนใหญ่ใช้งานผ่าน IPv6 ได้ตามปกติ
      แต่คนที่เราเตอร์ให้แค่ DNS แบบ IPv4 อย่างเดียวจะเจอปัญหาอินเทอร์เน็ตดับทั้งชุด
      รู้สึกว่า Microsoft น่าจะใส่ใจเรื่องนี้มากกว่านี้หน่อย
      ตอนจะเช็กว่า IPv4 กลับมาหรือยัง ผมยังต้องจำ mDNS hostname ที่กำหนดไว้ในเราเตอร์ด้วย

    • พูดตรง ๆ คือที่บ้านผมเคยมีช่วงที่ IPv4 หลุด แต่ภรรยาผมไม่รู้ตัวเลย
      Google, Facebook, Apple/iCloud และบริการส่วนใหญ่ที่อยู่บน CloudFlare ใช้งานผ่าน IPv6 ได้ดีมาก

    • ประสบการณ์ของผมก็คล้ายกัน
      ปัญหา IPv6 นี่หาสาเหตุและทำซ้ำได้ยากจริง ๆ และจะวนอยู่กับคำว่า “แต่เครื่องผมใช้ได้นะ?” ตลอด

    • ISP ส่วนใหญ่ยังคงบล็อก IPv6 อยู่ และแม้แต่ธุรกิจขนาดเล็กก็มีหลายแห่งที่ลองทำ IPv6 แต่ลืมตั้งค่าอย่าง AAAA record
      สุดท้ายผู้ใช้ก็จะเจอสถานการณ์แปลก ๆ ว่าที่บ้านเพื่อนหรือคาเฟ่ซึ่งใช้ ISP ราคาประหยัดกลับใช้ได้ แต่ที่บ้านตัวเองใช้ไม่ได้
      ฟังดูแปลกแต่เหมือนไม่มีทางแก้ที่ดีเป็นพิเศษ นอกจากหวังให้ IPv4 หายไปเอง
      มีเทคนิคอย่าง Happy Eyeballs อยู่เหมือนกัน คือพยายามเชื่อมต่อทั้ง IPv4/IPv6 พร้อมกันแล้วเลือกฝั่งที่เร็วกว่า แต่ในทางปฏิบัติปัญหากลับเกิดที่ชั้นแอปพลิเคชันมากกว่า และยังขาดวิธีทั่วไปในการแก้
      สำหรับผมจึงใช้ทางประนีประนอมคือเปิด IPv6 ไว้ในเครือข่าย แต่ปิด IPv6 DNS ในเบราว์เซอร์ ซึ่งก็ไม่ได้รู้สึกว่าดีนัก

  • ถ้าอยากลองใช้ IPv6 แต่ ISP ไม่รองรับ Hurricane Electric (HE) มีบริการ tunnel ฟรีมานานมากแล้ว
    ลิงก์ข้อมูลที่เกี่ยวข้องมี tunnelbroker.net, ipv6.he.net, วิธีตั้งค่าบน Fedora, บล็อกของ Brandon Rozek, วิธีตั้งค่าบน DD-WRT, สคริปต์อัปเดตอัตโนมัติในฟอรัม Mikrotik, คู่มือ RockyLinux และยังมีวิธีเซ็ตอัปอีกหลายแบบ

    • มีข้อควรระวังอย่างหนึ่งคือ เวลาจะใช้บริการสตรีมมิง มักมีหลายเจ้าที่บล็อก tunnel นี้ โดยมองคล้ายการอ้อมผ่าน VPN จึงติดการบล็อกคอนเทนต์ตามภูมิภาค
      ถึงอย่างนั้น ด้วยความสามารถของ RA (router advertisement) อุปกรณ์เครือข่ายใด ๆ ก็สามารถ broadcast เครือข่าย IPv6 เป็นหน่วย /64 ได้ ทำให้อุปกรณ์หลายตัวในเครือข่ายใช้ที่อยู่ IPv6 ได้ แม้เราเตอร์จะไม่รองรับ HE tunnel โดยตรงก็ตาม (ตราบใดที่เราเตอร์ไม่ได้กรอง RA เพื่อความปลอดภัย)
      เวลาจะโฮสต์อะไรเองที่บ้าน มันสะดวกมากเพราะทำได้ผ่าน IPv6 อย่างเดียวโดยไม่ต้อง port forwarding

    • บริการของ Hurricane Electric นั้นดี แต่ตอนนี้ ISP เริ่มให้ IPv6 เป็นค่าปริยายกันมากขึ้น ผู้ใช้ทั่วไปเลยทยอยเลิกใช้บริการ tunnel
      อีกทั้งบริการเครือข่ายบางเจ้าก็มอง he.net tunnel ว่าเป็นการใช้งานในทางที่ผิดหรือเป็นการโจมตีแล้วบล็อก ทำให้สุดท้ายผมต้องปิดการใช้งาน IPv6 ในเครือข่ายตัวเองเกือบทั้งหมด

    • ข้อควรรู้อีกอย่างคือ Hurricane Electric tunnel จะใช้ได้ก็ต่อเมื่อได้รับ public IPv4 จาก ISP เท่านั้น
      ถ้าคุณอยู่หลัง NAT อย่าง carrier-grade NAT วิธีนี้ใช้ไม่ได้ และต้องหาทางอื่นหากต้องการนำ IPv6 เข้าบ้าน

    • ผมเป็น “ลูกค้า” ที่ใช้ free 6in4 tunnel ของ HE บน OpenBSD มา 5 ปีแล้ว
      มันทำงานได้ดีสม่ำเสมอด้วยการตั้งค่าเครือข่ายล้วน ๆ เช่นไฟล์ /etc/hostname.gif0
      ผมยังใช้มันสื่อสารกับ VPS cluster ที่ตั้งใจทำให้ไม่มี IPv4 บน AWS ด้วย
      เนื่องจาก AWS คิดค่า IPv4 อย่างจริงจัง วิธีนี้ช่วยลดต้นทุนได้มากทีเดียว

  • ถ้าคุณอยู่ในสภาพแวดล้อม v6 only จริง ๆ แล้วต้องการเข้าถึง v4 วิธีที่ง่ายคือใช้ public DNS64+NAT64 Gateway
    ดูรายชื่อผู้ให้บริการสาธารณะได้ที่ public Provider list ของ nat64.net
    โดยปกติแค่เปลี่ยน DNS server ก็พอ
    DNS64 จะสร้าง AAAA record แบบสังเคราะห์ให้กับเว็บไซต์ที่ไม่มี AAAA record เพื่อให้เชื่อมต่อไปยังกล่อง NAT64 ได้
    จากนั้น NAT64 จะรับทราฟฟิกแล้วทำ protocol translation + NAT ให้
    ในตัวอย่างทดลองใช้งาน สามารถใช้คำสั่งอย่าง dig หรือ curl เพื่อเข้าถึง github ได้ทันที

    • ในยุโรปใช้ nat64.net ตรง ๆ ก็ใช้งานได้ลื่นพอสมควร
      โดยส่วนตัวมีแต่ประสบการณ์ที่ดี

    • ถ้าใช้ Cloudflare WARP จะรู้สึกได้เลยว่าเร็วกว่าเยอะ
      และยังสามารถเข้าถึง IPv4 address ได้โดยตรงผ่าน WARP

  • บางครั้งผมก็แปลกใจที่มีผู้ใช้แบบ IPv6-only อยู่จริง
    สมัยก่อนในสถานการณ์ตรงข้ามกันคืออยู่ในสภาพแวดล้อม IPv4-only แต่ต้องเข้าถึง IPv6 ถ้าคุณควบคุมเซิร์ฟเวอร์ปลายทางได้เต็มที่ ทางแก้ที่เร็วและใช้ได้ดีมากคือ SOCKS5 proxy ผ่าน ssh -D
    แค่ตั้งค่าเบราว์เซอร์ให้ใช้ socks proxy ก็ใช้งานได้ทันที
    ถ้าตั้งทั้งระบบกลับน่ากังวลเพราะอาจทำให้การเชื่อมต่อ ssh หลุดได้

  • ผมก็อยู่ในสถานการณ์คล้ายกัน
    ตอนนี้มี ticket เรื่องปัญหา IPv4 เปิดค้างมา 2 สัปดาห์แล้ว แต่ได้รับแต่คำตอบว่า “ช่างจะเข้ามาดูเร็ว ๆ นี้”
    IPv6 ยังใช้ได้ปกติ เลยดูเหมือนเขาไม่มองว่าเป็น outage ทั้งระบบ
    ในเยอรมนีมีกฎหมายเรื่องการชดเชยผู้บริโภคในกรณีแบบนี้ แต่ผมกำลังจะเช็กว่ากรณีนี้เข้าข่ายไหม
    ปัญหาของวิธีที่บทความบล็อกเสนอคือ ช่วง IP ของดาต้าเซ็นเตอร์มักถูกหลายบริการบล็อก หรือบังคับให้ทำ CAPTCHA/ขั้นตอนหลบเลี่ยง และถูกปฏิบัติเหมือน IP ของผู้ให้บริการ VPN ซึ่งแทบหลีกเลี่ยงไม่ได้
    สำหรับผมมันต้องแก้ทั้งบ้าน เลยตั้งค่า routing และกฎ NAT ด้วย Wireguard บนเราเตอร์ ซึ่งโชคดีที่ใช้อุปกรณ์เปิดอย่าง Ubiquiti EdgeRouter
    ถ้าเป็น FritzBox น่าจะทำยากกว่านี้มาก
    อย่างไรก็ตาม ข้อเสียคือประสิทธิภาพเราเตอร์ไม่พอ ถ้าปริมาณการเชื่อมต่อเยอะก็จะช้าลง เลยกำลังคิดว่าจะเปลี่ยนไปใช้ IPSec ที่รองรับ hardware offloading ดีไหม

    • FritzBox เองก็มีขั้นตอนตั้งค่า GUI สำหรับ VPN ที่ดีมาก
      แม้จะสมมติฐานหลักว่าเป็น FritzBox to FritzBox แต่ถ้าเป็น VPN ที่เข้ากันได้ก็ใช้ได้
      มันยังรองรับการตั้งค่า static IPv4/IPv6 route ด้วย
      ปัญหาใหญ่ที่สุดคือการหาว่าฝั่งตรงข้ามต้องการการตั้งค่าเข้ารหัส IPSec แบบไหน ส่วน Wireguard ตั้งค่าง่ายกว่า แต่กลับมีปัญหาเรื่อง hardware acceleration แทน
      ถ้าจำเป็นก็มีเทคนิคสำรองค่าตั้งค่าทั้งหมดของ FritzBox ออกมา แก้ไฟล์เอง แล้วคำนวณ checksum ใหม่ก่อนใส่กลับเข้าไป
      AVM ซ่อนค่าตั้งรายละเอียดมหาศาลที่ไม่เปิดให้ผู้ใช้เห็นไว้ ซึ่งตั้งใจทำแบบนั้น
      ส่วนหนึ่งก็เพื่อไม่ให้ผู้ใช้ทำเราเตอร์พังโดยไม่ตั้งใจ เลยทำให้มันยากไว้หน่อย

    • ผมไม่แน่ใจสถานการณ์ในเยอรมนี แต่ในเนเธอร์แลนด์ ถ้าใช้อินเทอร์เน็ตบ้านและมือถือจาก ISP เจ้าเดียวกัน เวลาเครือข่ายบ้านล่มสามารถขอ mobile data ฟรีได้
      ถ้าเป็นไปได้แนะนำให้ลองถาม ISP ว่ามีตัวเลือกนี้หรือไม่

  • แม้เวลาจะผ่านไปนาน ผมก็ยังหาเหตุผลชัด ๆ ไม่เจอว่าทำไมต้องเปลี่ยนอุปกรณ์ทั้งหมดและ homelab ไปเป็น IPv6
    port forwarding กับการตั้งค่า firewall ยังดูตรงไปตรงมามากกว่า และถ้าจะย้ายไป IPv6 ก็คาดว่าจะต้องเสียเวลาหลายสัปดาห์กับการแก้ปัญหา firewall และการตั้งค่า address ใหม่
    เลยสงสัยว่าผมพลาดอะไรไปรึเปล่า

    • ถ้ามองตามความเป็นจริง ตอนนี้คุณแทบไม่ได้พลาดอะไรเลย
      ต่อไปถ้าบริษัทใหญ่อย่าง Google หรือ Cloudflare แบกรับต้นทุน IPv4 address ที่สูงขึ้นเรื่อย ๆ ไม่ไหว ก็อาจเริ่มให้แรงจูงใจฝั่ง IPv6 เช่น จำกัดความเร็วการเชื่อมต่อผ่าน IPv4
      AWS เองแต่ก่อนคิดเงินเฉพาะ IPv4 Elastic IP ที่ไม่ได้ใช้งาน แต่ตอนนี้แม้ใช้อยู่ก็คิดเงินทั้งหมด
      เวลาคุณอัปเกรด gateway หรือ router ในอนาคต น่าจะดีถ้าเปิด IPv6 ทิ้งไว้เลย และตอนนี้ถ้าใช้แบบ dual-stack ทั้ง IPv4/IPv6 ก็ยังทำงานร่วมกับอุปกรณ์และบริการเดิมได้ไม่มีปัญหา
      เรื่องการกำหนดที่อยู่ IPv6 อัตโนมัติ ในอดีตเคยสับสนอยู่พักใหญ่ แต่ตอนนี้ดูเหมือนจะไปลงตัวที่ SLAAC ส่วนฝั่ง ISP ก็น่าจะใช้ DHCPv6 ต่อไปอีกนานพอสมควร

    • จริง ๆ แล้วมันไม่ได้ยากขนาดนั้น
      ถ้า home network ไม่ได้ซับซ้อนเป็นพิเศษ แค่ใช้เวลาช่วงเย็นนิดหน่อยก็ตั้งค่า IPv6 ได้แล้ว
      สำหรับ Comcast แค่เปิดตัวเลือก IPv6 บนเราเตอร์ ก็จะรับ prefix จาก ISP มา แล้วระบบก็จะ advertise ไปในเครือข่ายอัตโนมัติ จากนั้นแค่เปิด firewall เฉพาะพอร์ตที่ต้องการก็จบ

    • คุณไม่ได้พลาดอะไร
      ในสภาพแวดล้อมแบบองค์กร ข้อเสียและความซับซ้อนของ IPv6 มีมากกว่าข้อดี
      ผมดูแลอุปกรณ์ราว 3500 เครื่อง อาคาร 7 หลัง WAN 10Gbps จำนวน 2 เส้น และ WAN 4Gbps อีก 1 เส้น รวมถึง public IPv4 address 26 รายการ
      จนถึงตอนนี้ยังไม่มีเหตุผลอะไรเลยที่บังคับให้ต้องใช้ IPv6
      ถ้ารันแบบ dual-stack ก็ยิ่งเพิ่มภาระและความซับซ้อนโดยไม่จำเป็นให้เครือข่าย
      แถมช่วงหลังผมยื่นขอ static IPv6 block ไป 2 ครั้งก็ยังโดนปฏิเสธตลอด
      ในทางปฏิบัติแทบไม่มีประโยชน์อะไร และต่อให้จะขอก็ยังยากอีก
      จาก คู่มือคำขอ IPv6 ครั้งแรกของ ARIN
      → มีการจัดสรร IPv4 อยู่แล้ว
      → มีแผนทำ IPv6 multihoming ทันที
      → ภายใน 1 ปีมี 13 end-site (เช่น สำนักงาน)
      → ภายใน 1 ปีมี IPv6 address 2000 รายการ
      → ภายใน 1 ปีมี /64 subnet 200 ชุด
      ต้องเข้าเงื่อนไขอย่างน้อยหนึ่งข้อจึงจะมีสิทธิ์ยื่นขอ

  • ผมชื่นชมมากกับนโยบายของ Apple App Store ที่กำหนดให้ทุกแอปต้องทำงานได้บนเครือข่าย IPv6-only
    ในมุมของนักพัฒนาอาจรู้สึกช็อกในครั้งแรก แต่ในมุมผู้บริโภคถือว่าน่ายินดีมากที่มีข้อกำหนดแบบนี้

    • แต่นโยบายนี้ไม่ได้บังคับว่าฝั่งเซิร์ฟเวอร์ต้องมี IPv6 address

    • ถ้าอย่างนั้นก็สงสัยว่าแอปจะเข้าถึง github ผ่าน v6 ได้หรือเปล่า

  • ในงานบริษัท ผมดูแล VPN แบบ IPv6 only หลายตัวเพื่อใช้เข้าถึง infrastructure ภายใน
    ปัญหาใหญ่ที่สุดคือไคลเอนต์ Windows และ macOS ต้องมี v6 DNS server เสมอ
    เพราะไคลเอนต์อาจอยู่บนเครือข่ายที่รองรับ v6 หรือไม่รองรับก็ได้ ผมเลยรัน DNS server ไว้ภายใน VPN เองแล้วส่งค่าไปให้ไคลเอนต์อัตโนมัติ
    แต่พอ VPN หลุด แอป Wireguard กลับคืนค่า DNS เดิมไม่ได้ ทำให้เกิดปัญหาหลากหลายตามมา

    • ผมเคยใช้ IPv6-only ได้ดีบนทั้งเครือข่าย IPv4 only ของ ISP และบน macOS โดยไม่ต้องมี DNS แยกต่างหาก
      จำวิธีที่แน่ชัดไม่ได้แล้ว แต่ macOS ทำงานได้ไม่มีปัญหาแม้จะได้รับแค่ v6 address
      แค่กำหนด ULA address ให้กับ host ซึ่งถ้าผู้ใช้รู้วิธีก็ทำได้ไม่ยาก
      สามารถใช้สคริปต์ให้แอป VPN เพิ่ม ULA เข้าไปในเครือข่าย IPv6-only ได้โดยตรง
      แต่ถ้าปล่อย ULA ที่สร้างขึ้นทิ้งไว้ ผู้ใช้อาจมีปัญหาเมื่อย้ายไปใช้เครือข่าย v6 อื่น

  • ถ้าเจอสถานการณ์เดียวกัน สามารถสร้างสภาพแวดล้อม socks proxy ได้ง่าย ๆ ด้วย ssh proxy (ssh -D 8080 user@hostname)
    จากนั้นตั้งค่า proxy ในเบราว์เซอร์เป็น localhost:8080 ก็ใช้งานได้แล้ว

    • ผมก็กำลังจะให้คำแนะนำแบบเดียวกันเลย
      สำหรับการแก้ปัญหาชั่วคราว มันง่ายมาก และถ้าจำเป็นจะใช้เป็นเครื่องมือประจำก็ยังดีเยี่ยม
      แต่ใน sshd_config ต้องเปิด AllowTcpForwarding ไว้ด้วย

    • ผมใช้วิธีนี้ตลอดเวลาใช้งาน public Wi‑Fi
      ไม่ต้องจ่ายเงินให้บริการ VPN และไม่ต้องไว้ใจใคร แค่ส่งผ่าน socks proxy ไปยังเซิร์ฟเวอร์ infomaniak ของตัวเองก็พอ

  • โดยส่วนตัวผมหงุดหงิดกับ IPv4 มาก โดยเฉพาะ ISP ของผมที่บังคับให้ใช้ IPv4 อย่างเดียว ยิ่งน่าหงุดหงิดเข้าไปอีก
    ผมมองว่าการที่ IPv6 ถูกนำมาใช้ช้าขนาดนี้เป็นความล้มเหลวครั้งใหญ่ของอุตสาหกรรมเทคโนโลยี
    เลยสงสัยว่าใครควรเป็นคนรับผิดชอบ
    จะเป็นผู้ผลิตเราเตอร์ที่ทำเฟิร์มแวร์ห่วย ๆ, การขาดผู้นำจากฝั่ง ISP ในการผลักดัน IPv4, พวกเก็งกำไร IPv4 address หรือการขาดการฝึกอบรมของวิศวกรเครือข่ายและทีมซัพพอร์ตก็ตาม ผมคิดว่าควรมีการถกกันเชิงรากฐานเรื่องสาเหตุมากกว่านี้
    เหมือนที่อินเทอร์เน็ตเปลี่ยนผ่านจาก TLS 1.0 ได้ค่อนข้างดี ผมก็รู้สึกว่า IPv4 ก็น่าจะข้ามผ่านได้เหมือนกัน
    บางทีในอนาคต AI proxy สำหรับ legacy code อาจกลายเป็นทางออกก็ได้

    • เหตุผลที่การย้ายออกจาก TLS 1.0 ทำได้ง่ายกว่ามาก เป็นเพราะ end-to-end principle
      แค่เซิร์ฟเวอร์กับไคลเอนต์รองรับโปรโตคอลใหม่ก็พอ ส่วนอุปกรณ์กลางทางอย่างเราเตอร์หรือสวิตช์มองแค่ชั้นเครือข่าย (IP) และไม่เกี่ยวกับ TLS เวอร์ชันใหม่
      แต่ถ้าจะเปลี่ยนถึงโปรโตคอลชั้นเครือข่าย (IP) อุปกรณ์เครือข่ายตรงกลางทั้งหมดก็ได้รับผลกระทบ
      อนึ่ง ตอน rollout TLS 1.3 ก็ยังมีปัญหาเพราะ middlebox ทำลาย end-to-end principle ด้วยการตรวจและแก้ไขทราฟฟิก จน TLS 1.3 ต้องใช้ลูกเล่นปลอมตัวเหมือนการเชื่อมต่อใหม่ของ TLS 1.2 เพื่อความเข้ากันได้ เป็นเรื่องที่น่าปวดหัวมาก

    • ความต่างคือ TLS ต้องให้แค่เซิร์ฟเวอร์/ไคลเอนต์รองรับ ขณะที่อุปกรณ์กลางทางแค่ดู TCP packet ก็พอ
      แต่ IPv6 ต้องให้อุปกรณ์ตรงกลางทั้งหมดระหว่างเซิร์ฟเวอร์กับไคลเอนต์รองรับด้วย จึงเป็นเทคโนโลยีที่ขึ้นอยู่กับ “ตัวหารร่วมต่ำสุด”
      การอัปเกรด TLS แทบไม่มีส่วนไหนเปลี่ยนใหญ่โต ในขณะที่ IPv6 เปลี่ยนหลายอย่างพร้อมกันเกินไป
      มองย้อนกลับไปแล้วก็อดเสียดายไม่ได้ว่า ถ้า IPv6 แค่เพิ่ม address เป็น 64 บิตอย่างเดียว บางทีอาจแพร่หลายได้ง่ายกว่านี้

    • ในทางปฏิบัติ หลายคนไม่ได้รีบใช้เพราะประโยชน์ที่ได้จากการเปลี่ยนมีน้อยมากหรือแทบไม่มีเลย
      ไม่ได้มีทฤษฎีสมคบคิด IPv4 ใหญ่โตอะไร แค่ผลตอบแทนต่อความเสี่ยงและงานที่ต้องทำมันต่ำ

    • ในวงการเครือข่ายมีมุกว่า “IPv6 คือคำตอบเชิงวิชาการที่ยัดใส่ปัญหาทางวิศวกรรม”
      ถ้าคิดถึงการนำไปใช้จริงในวงกว้าง พร้อมทั้งต้องรักษาความเข้ากันได้กับ IPv4 รวมถึงงานปฏิบัติการและบำรุงรักษา IPv6 มันซับซ้อนเกินไป
      และเพราะ IPv4 ก็แทบไม่มีปัญหาอื่นที่เป็นรูปธรรม นอกจากเรื่อง address หมด จึงยากที่จะหายไปจริง
      ผลคือในภาคสนาม IPv6 จึงยังไม่กลายเป็นโซลูชันที่ใช้ได้จริงมากพอ