Menggunakan internet tanpa koneksi IPv4

• Setelah pemadaman listrik, di sisi ISP hanya koneksi IPv4 yang terputus sementara IPv6 tetap hidup. Untuk memulihkan akses ke situs IPv4-only, digunakan Hetzner VPS yang memiliki IPv4/IPv6 serta tunnel WireGuard
• Gangguan tampaknya terjadi di lapisan CG-NAT, di mana paket IPv4 tidak diterjemahkan dengan benar lalu di-drop; layanan yang mendukung IPv6 seperti Google dan Meta tetap bisa diakses
• Dengan menaruh server WireGuard di VPS dan klien memakai alamat IPv6 VPS sebagai endpoint, trafik IPv4 dapat dikirim melalui VPS sehingga browsing web biasa pulih
• VPN kantor dan Docker perlu penanganan terpisah, sehingga dijalankan di dalam network namespace berbasis vopono dengan workaround seperti unshare dan bind mount /sys
• Gejala sebagian situs tidak mau dimuat ternyata disebabkan MTU WireGuard yang terlalu besar; setelah diturunkan ke 1280, MTU minimum IPv6, masalah langsung teratasi

---

Gangguan setelah pemadaman listrik: hanya IPv4 yang terputus

• Setelah pemadaman listrik, pemutus arus sudah dipulihkan, tetapi GitHub dan berbagai situs web tidak bisa diakses, sementara Google dan Meta berjalan normal
• Dari mesin lokal dan halaman diagnostik router, pemeriksaan ping -6 dan traceroute menunjukkan bahwa masalah hanya terjadi pada koneksi ke server IPv4
• ISP mengatakan mungkin perlu kunjungan teknisi dan bisa memakan beberapa hari setelah akhir pekan, sementara akses kerja dan pengerjaan paper membuat sulit untuk menunggu gangguan selesai
• Hetzner VPS yang sudah ada memiliki alamat IPv4 dan IPv6 statis, dan karena situs web Hetzner mendukung IPv6, konsol dapat diakses untuk melakukan konfigurasi

Ketergantungan IPv4 yang dibuat oleh NAT dan CG-NAT

• Alamat IPv4 berukuran 32-bit, dan jika blok cadangan dikecualikan, hanya ada sekitar 3,7 miliar alamat IPv4 publik, sehingga tidak mungkin memberi alamat langsung ke semua perangkat yang terhubung ke internet
• NAT membuat banyak perangkat berbagi satu IP publik
  • Router rumah mengubah IP lokal perangkat internal seperti 192.168.1.xxx menjadi IPv4 publik miliknya
  • conntrack di Linux menyimpan IP dan port asal asli serta port hasil translasi sebagai pemetaan
  • Saat paket respons datang ke port tersebut, conntrack mengembalikan tujuan ke IP dan port internal semula
  • Di Linux, pemetaan yang tersimpan dapat dilihat dengan conntrack -L dari conntrack-tools
• NAT bertindak seperti firewall implisit, sehingga layanan pada perangkat lokal di balik router sulit diakses dari luar tanpa port forwarding eksplisit
• Karena kekurangan IPv4, ISP dapat menerapkan NAT sekali lagi di jaringan internalnya, yang disebut Carrier Grade NAT(CG-NAT)
  • Seperti router rumah melakukan NAT untuk banyak perangkat lokal, router ISP melakukan NAT untuk banyak router rumah
  • Bergantung pada jumlah alamat IPv4 yang dimiliki ISP dan kebijakan alokasinya, hal ini dapat berulang dalam beberapa lapisan, misalnya per wilayah
• Gangguan kali ini tampak seperti kondisi di mana trafik IPv4 benar-benar terputus karena paket IPv4 tidak di-NAT dengan benar dan di-drop di suatu tempat pada lapisan CG-NAT
• Untuk cara mengatasi NAT traversal, tulisan Tailscale How NAT Traversal Works layak dijadikan rujukan

Mengapa IPv6 tetap berjalan

• Alamat IPv6 berukuran 128-bit dan, bahkan dengan memperhitungkan blok cadangan, menyediakan sekitar 3.4E38 alamat
• Router rumahan sering menerima subnet /64, yang berarti 1.84E19 alamat
• Dengan IPv6, setiap perangkat dapat memiliki alamat langsung di internet tanpa perlu NAT di router rumah
  • Masalah port forwarding berkurang
  • Sebagai gantinya, router atau tiap perangkat memerlukan aturan firewall yang tepat untuk memblokir koneksi baru dari luar yang tidak diminta
• Karena CG-NAT tidak diterapkan pada IPv6, gangguan kali ini tidak memengaruhinya
• Masih ada web server seperti GitHub yang belum dapat diakses melalui IPv6, sehingga koneksi IPv6 saja tidak cukup untuk menggunakan seluruh internet secara langsung

Membuat tunnel IPv4 di atas IPv6 dengan WireGuard

• Solusinya adalah memasang WireGuard di VPS dan membuat tunnel dengan klien memakai alamat IPv6 VPS sebagai endpoint
• Setelah tunnel terbentuk, trafik IPv4 berjalan normal melalui VPS
  • Latensi bertambah karena lewat VPS
  • Cara kerjanya mirip Dual-Stack Lite yang dikonfigurasi sendiri
• Servernya adalah Hetzner VPS yang sebelumnya sudah dipasangi Arch Linux dengan vps2arch, menggunakan image Debian terbaru Hetzner sebagai basis
• Konfigurasi WireGuard didasarkan pada contoh kasus penggunaan khusus: server VPN WireGuard di ArchWiki, dengan tambahan trafik IPv6
• Konfigurasi server mencakup hal berikut
  • Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
  • IPv4 diteruskan dengan MASQUERADE dari iptables
  • IPv6 ULA di-NAT dengan SNAT --to-source dari ip6tables
  • Mengaktifkan forwarding IPv4/IPv6
  • peer dibagi menjadi contoh foo yang memakai IPv6 Global Unicast Address secara langsung dan bar yang memakai IPv6 ULA yang di-NAT
• Berbeda dari konfigurasi bergaya .ini, wg-quick dapat menentukan PostUp dan PostDown beberapa kali, lalu menjalankan tiap perintah secara berurutan
  • Implementasi terkait ada di wg-quick linux.bash

NAT IPv6, SNAT, dan konfigurasi klien

• IPv6 tidak selalu perlu di-NAT, dan jika VPS memiliki blok IPv6 /64 seperti Hetzner, peer dapat diberi Global Unicast Address(GUA) secara langsung
• Untuk memakai metode alamat langsung, ganti Unique Local Address(ULA) milik peer dan interface menjadi alamat IPv6 publik, lalu hapus aturan ip6tables MASQUERADE
  • Tiap peer dapat dialamatkan langsung dari internet melalui alamat IPv6 yang dialokasikan
  • Metode ini cocok jika ingin meneruskan layanan sendiri dari beberapa perangkat
  • Firewall VPS harus menangani trafik masuk dengan benar
• Jika yakin alamat IP VPS statis dan tidak berubah, SNAT dapat digunakan alih-alih MASQUERADE
  • MASQUERADE mencari IP interface saat runtime
  • SNAT sedikit lebih efisien karena alamat ditentukan langsung
• Pada konfigurasi klien, alamat IPv6 server harus diapit tanda kurung siku seperti Endpoint = [2001:db8:abcd:1234::1]:51820
• Dengan AllowedIPs = 0.0.0.0/0, ::/0, seluruh trafik IPv4/IPv6 dikirim ke tunnel
• Setelah dijalankan di kedua sisi, browsing biasa kembali normal, dan server juga bisa diakses langsung lewat SSH menggunakan alamat IPv4 dan IPv6 lokal tunnel
• Di Linux, klien WireGuard juga bisa dipasang dengan mudah di mesin istri

Memisahkan VPN kantor dengan network namespace

• Jika VPN kantor langsung disambungkan di atas koneksi WireGuard, terjadi konflik sehingga tidak bisa digunakan
• vopono digunakan untuk menjalankan VPN kantor dan aplikasi yang diperlukan di dalam network namespace
• Intinya adalah membuat aturan MASQUERADE meneruskan trafik ke interface WireGuard yang sedang berjalan (foo atau bar), bukan ke interface jaringan fisik
• Trafik di dalam namespace tidak secara langsung menyadari aturan nftables WireGuard pada host, tetapi pada praktiknya dirutekan melalui tunnel WireGuard
• wg-quick lebih memilih nftables daripada iptables saat tersedia, namun menghindari konflik dengan aturan iptables standar Docker
• Contoh menjalankan vopono adalah sebagai berikut

$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh

• /etc/netns/vo_none_none/ di-mount sebagai /etc oleh ip netns exec, sehingga resolv.conf khusus untuk namespace tersebut dapat ditempatkan di sana
• Jika ingin memprioritaskan resolusi DNS IPv4, gai.conf juga dapat disesuaikan dengan cara yang sama
  • Pengaturan ini digunakan saat men-debug masalah trafik tunnel IPv6
  • Contohnya didasarkan pada jawaban AskUbuntu
• Setelah VPN kantor tersambung, jika server DNS internal dimasukkan ke /etc/netns/vo_none_none/resolv.conf, aplikasi yang kemudian dijalankan di namespace tersebut akan berjalan normal
• Aplikasi seperti Chrome dapat dijalankan di dalam namespace dengan hak pengguna biasa

$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

Menjalankan Docker di namespace yang sama

• Docker tidak berjalan hanya dengan dijalankan di network namespace seperti aplikasi lain
  • Karena socket Docker yang diaktifkan oleh systemd dibuat di luar namespace
  • Konektivitas internal tidak tersedia
• Menghentikan Docker eksternal lalu mencoba membuat dockerd dan socket baru di dalam namespace juga tidak langsung menyelesaikan masalah
  • ip netns exec membuat mount namespace dan me-mount ulang /sys
  • Karena itu, /sys/fs/cgroup milik host tidak terlihat
• Dalam kondisi ini, kesalahan berikut dapat terjadi

Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo

• Workaround-nya adalah membuat /sys sebagai bind mount dengan unshare, lalu melepas mount /sys internal yang dibuat oleh ip netns exec
  • Cara ini didasarkan pada post Unix StackExchange
  • Setelah itu, /sys di dalam mount namespace menjadi bind mount dari /sys host
• Contoh perintahnya adalah sebagai berikut

$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...

• Jika dockerd dan perintah Docker dijalankan dalam sesi yang sama, keduanya berbagi network namespace dan mount namespace yang sama
• Pengaturan DNS Docker juga dapat ditempatkan di /etc/netns/vo_none_none/docker/daemon.json
• Cara ini cukup untuk pekerjaan yang membutuhkan container pendamping dan container yang terhubung melalui jaringan Docker, tetapi mungkin tidak langsung berjalan pada konfigurasi Docker yang lebih kompleks yang memerlukan bridge dan sebagainya

Men-debug masalah MTU WireGuard

• Setelah reboot, koneksi WireGuard tampak tetap hidup, tetapi hanya sebagian halaman yang dimuat dan situs seperti GitHub tidak terbuka
• ping, ping -6, dan wg show normal, sehingga penyebabnya sulit ditemukan
• Pemeriksaan dengan ping berukuran berbeda menunjukkan bahwa paket besar gagal

$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1

• Ukuran 1400 gagal sementara 1200 dan 800 berhasil, sehingga dipastikan penyebabnya adalah pengaturan MTU
• Jika MTU interface WireGuard lokal diturunkan, stack IP kernel tidak akan membuat paket yang lebih besar dari nilai tersebut
  • Paket UDP akhir yang sudah ditambah overhead enkapsulasi WireGuard juga tidak akan di-drop pada link dengan MTU kecil di sepanjang jalur
• Setiap router di jalur memiliki MTU sendiri, dan paket yang lebih besar dari MTU terkecil dapat di-drop
• Trafik tunnel mendapat tambahan sekitar 32 byte overhead dari enkapsulasi WireGuard, sehingga masalah MTU bisa makin besar
• Pesan Path MTU Discovery dapat dikirim melalui ICMP oleh router perantara, tetapi firewall sering menjatuhkan ICMP sehingga penyesuaian otomatis bisa tidak terjadi
• MTU minimum dalam spesifikasi IPv6 adalah 1280, sehingga pada tunnel WireGuard di atas IPv6, nilai ini seharusnya selalu bekerja

Opsi operasional yang tersisa setelah pemulihan

• Hasil konfigurasi mencakup hal berikut
  • Menyiapkan server VPN WireGuard pada VPS yang memiliki IPv4 dan IPv6
  • Mendukung IPv6 langsung dan trafik IPv6 yang di-NAT
  • Menjalankan VPN kantor di network namespace
  • Menjalankan Docker di dalam network namespace yang sama dengan workaround unshare
  • Men-debug masalah MTU WireGuard
• Dalam kerja jarak jauh, masalah koneksi internet selalu menjadi faktor risiko, dan dalam kasus ini alat-alat Linux memungkinkan bypass tanpa menunggu pemulihan konfigurasi ISP
• Hetzner VPS mendukung tunnel WireGuard dan penggunaan umum yang legal, sementara port scanning, traffic spoofing, dan penambangan cryptocurrency tidak diizinkan
• VPN yang mendukung port forwarding seperti AirVPN, ProtonVPN, dan AzireVPN juga bisa menjadi alternatif untuk meneruskan port home server tanpa bergantung pada ISP
• Jika memakai router OpenWRT, debugging di sisi router bisa dilakukan lebih banyak, dan konfigurasi bypass seperti ini dapat ditangani langsung dengan WireGuard di router tanpa perlu mengaturnya terpisah di tiap perangkat

[GN⁺]

Komentar Hacker News

• Judulnya agak menyesatkan. Lebih tepatnya ini adalah mengakses internet IPv4 lewat tunnel IPv6 melalui VPS, yang biasanya juga disebut 4in6.
  Meski begitu tetap menarik. Dari sudut pandang ISP, sifat masalah dukungan saat IPv4 rusak dan saat IPv6 rusak cukup berbeda. Gangguan IPv4 umumnya berupa kondisi “down” yang jelas, sehingga pengguna sangat kesal tetapi kasusnya sederhana. Sebaliknya, gangguan IPv6 muncul dalam bentuk-bentuk aneh seperti gangguan parsial, start yang lambat karena fallback, atau gateway yang mengira IPv6 tersedia.

  • Terakhir kali IPv4 mati, saya terutama menyadarinya karena Github tidak bisa diakses. Sekarang sebagian besar situs web konsumen berfungsi hanya dengan IPv6.
    Namun orang yang routernya hanya dikonfigurasi dengan server DNS IPv4 mengalami gangguan total. Kalau Microsoft sudah membersihkan aset-asetnya yang tidak becus, kekhawatiran terbesar mungkin sekadar mengingat hostname mDNS yang ditempelkan ke router untuk login dan memastikan apakah IPv4 sudah kembali.
  • Long tail IPv4 jelas masih ada, tetapi terakhir kali IPv4 di rumah saya terputus, istri saya sama sekali tidak menyadarinya. Itu karena Google, Facebook, Apple/iCloud, dan sebagian besar hosting CloudFlare tetap berjalan lewat IPv6.
  • Ini juga sesuai dengan pengalaman saya. Masalah IPv6 sangat membuat frustrasi untuk diklasifikasikan dan direproduksi, dan sering muncul situasi seperti “di komputer saya bisa”.
  • Sebagian besar ISP masih memblokir IPv6 sama sekali. Banyak operator kecil mencoba IPv6 sekali lalu lupa hal-hal seperti memperbarui record AAAA, sehingga bagi pengguna terlihat seolah layanan niche favoritnya bisa diakses di jaringan lain, tetapi tidak bisa diakses melalui ISP yang mereka bayar.
    Ini masalah yang aneh, dan saya tidak tahu apakah ada solusi yang bagus selain berharap IPv4 suatu hari menghilang. Happy Eyeballs seharusnya menyelesaikan masalah ini, tetapi masalahnya sering muncul jauh di atas lapisan aplikasi, dan karena aplikasi bisa melakukan apa saja, sulit menyelesaikannya dengan protokol umum tanpa abstraksi yang bocor. Secara pribadi saya berkompromi dengan menyalakan IPv6 di jaringan tetapi mematikan DNS IPv6 di semua browser, dan itu cukup tidak memuaskan.

• Jika ingin mencoba IPv6 tetapi ISP tidak menyediakannya, Hurricane Electric sudah bertahun-tahun menyediakan layanan tunnel.
  https://tunnelbroker.net
  https://ipv6.he.net
  Ada juga skrip untuk menyalakan perangkat tun di sistem atau router dan merutekan traffic: https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...

  • Catatan menjengkelkan tentang tunnel seperti ini adalah layanan streaming memblokirnya seperti VPN untuk melewati pembatasan wilayah, jadi jika perlu Anda harus mencari cara untuk mematikan tunnel tersebut.
    Meski begitu, ini berfungsi dengan baik. Walaupun router tidak mendukung tunnel HE, dengan kekuatan RA Anda bisa memberi alamat IPv6 ke semua perangkat di dalam jaringan. Perangkat apa pun yang mengiklankan /64 akan menjadi router IPv6. Tentu saja dengan asumsi router tidak memfilter RA demi keamanan. Ini sangat berguna saat meng-host layanan di dalam jaringan rumah tanpa menyentuh aturan port forwarding.
  • Hurricane Electric bagus, tetapi seiring makin banyak orang memakai IPv6 yang disediakan ISP, pengguna “normal” meninggalkan tunnel, dan layanan-layanan jaringan mulai menandai tunnel he.net sebagai penyalahgunaan.
    Terlalu banyak situs memasang penghalang atau bahkan menolak berfungsi, sehingga saya harus berhenti memakai IPv6 di sebagian besar jaringan saya.
  • Perlu diketahui bahwa sejauh yang saya tahu, tunnel HE hanya berfungsi jika ISP memberi Anda IPv4 publik. Kalau Anda berada di belakang NAT kelas operator, sayangnya Anda perlu solusi lain untuk membawa IPv6 ke rumah.
  • Saya adalah “pelanggan” yang puas. Saya memakai tunnel 6in4 gratis dengan OpenBSD selama sekitar 5 tahun, dan tidak ada masalah yang layak disebut.
    Konfigurasinya hanya dengan file antarmuka jaringan OpenBSD seperti /etc/hostname.gif0: tunnel, inet6 128 alias, !route -n add -inet6 default. Koneksi ini saya pakai untuk mengakses klaster VPS di AWS yang sengaja dikonfigurasi tanpa alamat IPv4 publik. Karena orang-orang seperti Jeff Bezos aktif memonetisasi ruang alamat IPv4, jika tidak begitu itu akan menjadi bagian besar dari biaya bulanan.

• Jika benar-benar membutuhkan koneksi IPv4 dengan cepat di lingkungan khusus IPv6 murni, Anda bisa memakai gateway DNS64+NAT64 publik. Daftarnya ada di https://nat64.net/public-providers
  Untuk penggunaan umum, cukup ganti server DNS saja. DNS64 menyintesis record DNS AAAA yang mengarah ke kotak NAT64 untuk target yang tidak memiliki record AAAA: $ dig +short @2a00:1098:2c::1 AAAA github.com → 2a01:4f8:c2c:123f:64:5:141a:9cd7. NAT64 melakukan konversi protokol dan NAT pada trafik yang datang ke sisinya karena DNS64: $ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)

  • Saya datang untuk mengatakan ini. Di Eropa, setidaknya https://nat64.net/ sendiri cukup bagus. Pengalaman saya hanya baik-baik saja
  • Kalau memakai Cloudflare WARP, seharusnya jauh lebih cepat. Melalui WARP, Anda juga bisa terhubung langsung ke alamat IPv4

• Ternyata pengguna internet khusus IPv6 yang seperti mitos itu benar-benar ada :) Rekayasa jaringan yang hebat
  Dulu saya pernah membutuhkan hal serupa untuk tujuan kebalikannya yang lebih umum, yaitu mengerjakan hal-hal terkait IPv6 dari koneksi khusus IPv4. Jika punya kendali penuh atas server, solusi yang lebih terbatas tetapi cepat adalah membuat proxy SOCKS5 dengan ssh -D 1080 -N myserver lalu mengaturnya di browser. Sepertinya bisa juga diatur untuk seluruh sistem, tetapi saya penasaran apakah koneksi ssh aslinya akan putus dan semuanya runtuh karenanya

• Saya juga berada dalam situasi yang sama. Sudah 2 minggu saya hanya mendengar bahwa “tiket sudah dibuka dan teknisi akan segera memeriksanya”, jadi cukup membuat frustrasi
  Entah apakah prioritasnya rendah karena IPv6 berfungsi sehingga tidak dianggap gangguan total. Di Jerman ada undang-undang yang menjamin kompensasi konsumen untuk kasus seperti ini, dan saya akan segera memeriksa apakah kasus ini juga termasuk. Solusi di tulisan blog ini punya masalah bahwa beberapa endpoint memblokir seluruh rentang IP data center atau meminta banyak CAPTCHA, dan penyedia VPN umum juga sama. Karena saya ingin memperbaiki seluruh jaringan rumah, ini harus ditangani di router, dan adanya perangkat nonstandar seperti Ubiquiti EdgeRouter membantu untuk pengaturan routing Wireguard dan aturan NAT. Saya tidak tahu bagaimana melakukannya pada perangkat seperti FritzBox. Kekurangannya adalah performa router tidak cukup untuk menangani banyak koneksi, jadi saya harus beralih ke IPSec yang mendukung hardware offloading

  • FritzBox sebenarnya juga punya GUI untuk menyiapkan koneksi VPN yang cukup baik. Fitur ini ditujukan untuk koneksi antar-FritzBox, tetapi VPN yang kompatibel juga bisa. Route IPv4/IPv6 statis juga bisa diatur
    Masalah terbesarnya kemungkinan adalah mencari tahu konfigurasi enkripsi IPsec seperti apa yang diharapkan di sisi lawan. Wireguard bisa jauh lebih mudah, tetapi saat itu masalah akselerasi hardware bisa muncul. Jika perlu, Anda juga bisa mencadangkan file konfigurasi FritzBox, mengedit dump untuk mengatur endpoint VPN secara manual, lalu menghitung ulang checksum dan mengimpornya kembali. Di AVM ada banyak pengaturan yang tidak dapat diakses pengguna dan bisa disesuaikan dengan cara ini, tetapi mereka membuat aksesnya agak sulit agar router tidak tidak sengaja menjadi brick
  • Saya tidak tahu situasi di Jerman, tetapi di Belanda, jika memakai koneksi kabel dan seluler dari ISP yang sama lalu koneksi kabel bermasalah, Anda bisa meminta data seluler gratis sampai gangguannya diperbaiki
    Ini mungkin opsi yang layak ditanyakan ke ISP

• Salah satu hal yang saya sukai dari aturan App Store Apple adalah kewajiban bahwa semua app harus berfungsi di jaringan khusus IPv6. Aturan ini sudah ada sejak bertahun-tahun lalu
  Sebagai developer, ini agak mengejutkan saat pertama kali menghadapinya, tetapi sebagai pengguna, saya senang aturan itu ada

  • Kalau memakai app, apakah Github juga bisa diakses lewat IPv6?
  • Namun itu bukan berarti server harus memiliki alamat IPv6

• Jika mengalami hal yang sama, Anda bisa dengan sangat mudah membuat proxy ssh dengan ssh -D 8080 user@hostname
  Setelah koneksi dibuat, cukup atur browser agar memakai localhost:8080 sebagai proxy SOCKS

  • Saya juga hendak memberi saran yang sama. Untuk masalah sementara, ini solusi yang jauh lebih sederhana, dan saat membutuhkan proxy, ini juga bisa dipakai sebagai alat permanen
    Untuk memakai fitur ini, AllowTcpForwarding harus diaktifkan di sshd_config
  • Saya selalu melakukan ini saat memakai Wi-Fi publik. Tanpa perlu membayar VPN atau memercayai VPN, saya mem-forward semuanya lewat SOCKS ke server infomaniak saya

• Ada beberapa titik penghambat saat mematikan IPv4: sebagian besar mesin pencari alternatif tampaknya tidak menyediakan koneksi IPv6, dan saat terakhir diperiksa, Github sama sekali tidak punya IPv6
  Karena ini Microsoft, jangan berharap hal baik; justru bersiaplah untuk yang terburuk. Baru-baru ini mereka juga merusak noscript/basic (x)html di issues. Saya juga tidak tahu apakah masih bisa membuat akun dengan browser noscript/basic (x)html, email yang dihosting sendiri, dan literal IP(v6) seperti mailbox@[ipv6:...]. Steam atau game juga belum saya cek akhir-akhir ini, tetapi banyak CDN/server game, atau setidaknya sebagian besar, sepertinya masih hanya IPv4. Banyak server email juga memblokir server email yang dihosting sendiri, dan sering memakai daftar blokir yang ceroboh dan tidak tepat dari perusahaan mencurigakan di Swiss/Andorra seperti Spamhaus. Selain itu, banyak aplikasi jaringan tidak memanfaatkan keunggulan IPv6. Misalnya, aplikasi client-server seperti web semestinya memakai alamat IPv6 yang dibuat acak untuk setiap sesi, asalkan ISP tidak memberikan prefiks yang terlalu kecil. ISP IPv6 seluler tampaknya memberikan alamat IPv6/128 acak di dalam prefiks, tetapi seharusnya menyediakan prefiks yang stabil, mungkin sekitar 96 bit, agar aplikasi di perangkat bisa memilih alamat IPv6 “tetap” untuk panggilan suara/video langsung tanpa resolusi nama online terpusat. Diperlukan juga layanan OS tingkat pengguna baru untuk mengoordinasikan alamat IPv6 antar-aplikasi pengguna. Namun, perlu berhati-hati terhadap kompleksitas bodoh yang mungkin dipaksakan sebagian vendor dan developer untuk mengunci pengguna dan developer aplikasi

  • Di mini homelab saya, IPv6-only berjalan baik, tetapi rusak ketika karena suatu hal saya membutuhkan GitHub. Jadi saya memasang NAT64+NAT64
    Sangat disayangkan harus melakukan itu hanya karena GitHub. Karena server email, suatu saat mungkin memang akan perlu, tetapi sebagai alasan kenapa saya butuh NAT64 secepat ini, itu buruk sekali. Saya melihatnya sebagai salah satu dari banyak kelemahan orang memakai GitHub sebagai sarana distribusi software
  • Beberapa bulan lalu saya harus bergulat dengan Spamhaus. Entah kenapa, alamat IPv6 VPS saya masuk daftar blokir Spamhaus
    Saya sama sekali tidak tahu penyebabnya. Mesin itu tidak menjalankan apa pun yang bisa mengirim email, dan setahu saya Digital Ocean juga memblokir SMTP, jadi secara harfiah mustahil mesin ini mengirim email. Spamhaus sama sekali tidak membantu penyelesaiannya, begitu juga DO
  • Karena masalah banyak CDN/server game yang masih hanya IPv4, saya membuat proxy DNS. Ini menambahkan record AAAA yang benar untuk domain-domain seperti itu
    https://gitlab.com/miyurusankalpa/IPv6-dns-server
  • Bisa dipastikan Steam membutuhkan IPv4. Begitu juga beberapa game yang membutuhkan autentikasi untuk dimainkan
  • Kecuali ada diskon jika dijalankan IPv6-only seperti pada layanan VPS, tampaknya belum ada yang benar-benar mempertimbangkan untuk beralih dari IPv4
    Dalam praktiknya, kemungkinan besar kita akan tetap memiliki konektivitas IPv4 dalam bentuk tertentu, hanya saja makin besar kemungkinan koneksi itu lewat CGNAT. Github sangat menyebalkan. Mereka menguji selama beberapa minggu dan semuanya tampak berjalan baik, lalu kembali lagi menjadi IPv4-only. Server email memang masih hidup di dunia 10–20 tahun lalu. Menonaktifkan dukungan SSL 3.0 atau TLS 1.0 di server email pun sulit dilakukan tanpa menanggung masalah deliverability. Dukungan dan filter spam Microsoft Outlook tampaknya bahkan tidak mengenali server email yang mendukung IPv6. Padahal kalau melihat header, secara internal mereka tampaknya sudah lama memakai IPv6. Saya ingin IPv6 lebih banyak dimanfaatkan, tetapi ketakutan bahwa itu mungkin bekerja sedikit lebih buruk untuk segelintir pelanggan tampaknya membekukan semua upaya untuk benar-benar memakai teknologinya. Alasan kita melihat perilaku IP yang aneh di operator seluler kemungkinan besar karena cara IP bekerja di jaringan seluler. Saat Anda menelepon sambil melaju di jalan tol atau duduk di kereta cepat, ponsel terus melakukan handover, dan alamat IP membutuhkan tingkat stabilitas tertentu. Bahkan saat melintasi perbatasan dan berpindah ke jaringan asing, seluruh stack harus mempertahankan koneksi tanpa putus. Di dalam jaringan seluler ada sistem routing khusus, dan sebagian di antaranya memanfaatkan fitur IPv6 dengan sangat baik, tetapi itu membuat penyediaan alamat unicast global statis yang “biasa” untuk ponsel menjadi sulit. Mereka membuatnya terlihat seumum mungkin, tetapi mencapai stabilitas seperti internet rumah kabel tidaklah mudah

• Di tempat kerja, kami mengoperasikan beberapa VPN IPv6-only untuk akses infrastruktur internal
  Sejauh ini masalah terbesarnya adalah klien Windows dan macOS membutuhkan server DNS IPv6. Jika tidak, mereka bahkan tidak mencoba me-resolve v6onlyhost.vpn.example.com. Karena klien bisa saja berada di jaringan yang mendukung IPv6 atau tidak, kami harus menjalankan server DNS di dalam VPN dan mendorongnya ke klien; tetapi jika setelah VPN terputus aplikasi Wireguard karena suatu alasan gagal mengembalikan DNS seperti semula, berbagai macam masalah bisa muncul

  • Meski memakai jaringan ISP yang hanya IPv4, macOS bisa melakukan koneksi IPv6-only tanpa server DNS semacam itu
    Saya sudah tidak ingat detailnya, tetapi saat saya menelusurinya beberapa tahun lalu, macOS bekerja baik seperti itu selama hanya memiliki alamat IPv6. Cukup tambahkan alamat ULA ke host. Tentu saja, ini mengandaikan pengguna tahu caranya. Tergantung aplikasi VPN, bisa juga memasukkan skrip yang menambahkan ULA saat masuk ke jaringan IPv6-only. Namun, jika ULA palsu terus tertinggal, itu bisa menimbulkan masalah saat pengguna berpindah ke jaringan yang mendukung IPv6
  • Ini bukan masalah Windows. Saya juga pernah mengalami masalah serupa di hotspot acak, tetapi tidak semuanya. Saya rasa penyebabnya adalah hotspot bodoh yang tidak mengembalikan record AAAA saat IPv6 dimatikan

• Meski sudah selama ini berlalu, aku masih belum melihat alasan yang cukup meyakinkan untuk menghabiskan beberapa hari memusingkan diri mengubah semua mesin dan homelab-ku ke IPv6
  Port forwarding dan aturan firewall terasa lebih intuitif daripada menghabiskan berminggu-minggu memecahkan masalah semuanya, mengonfigurasi ulang firewall, dan menomori ulang alamat jaringan. Apa yang kulewatkan?

  • Yang terlewat adalah bahwa ini tidak sesulit yang dibayangkan. Kalau jaringan rumahmu tidak sangat rumit, konfigurasi IPv6 paling lama selesai dalam satu malam
    Untuk jaringan dan ISP-ku, Comcast, cukup menyalakan IPv6 di router, lalu router akan menerima prefix dari ISP dan mengiklankannya secara lokal; setelah itu tinggal menambahkan satu aturan firewall untuk target yang ingin dibuat bisa diakses dari luar
  • Tidak ada yang terlewat. Di lingkungan perusahaan, manfaat adopsi IPv6 tidak lebih besar daripada kekurangannya
    Aku mengelola sekitar 3.500 perangkat, 7 gedung, dua WAN 10 giga dan satu WAN 4 giga, serta menggunakan sekitar 26 alamat IPv4 publik dan NAT. Sampai sekarang pun tidak ada alasan kuat untuk mengadopsi IPv6. Konfigurasi dual stack hanya menambah trafik dan kompleksitas yang tidak perlu tanpa manfaat berarti. Sampai sekarang masih sulit mendapatkan blok alamat IPv6 statis, dan aku sudah mengajukan dua kali tetapi ditolak. Bukan hanya ruang peningkatannya kecil, mendapatkan bloknya sendiri pun masih sulit. Persyaratan kelayakan di https://www.arin.net/resources/guide/ipv6/first_request/ juga seperti memiliki alokasi IPv4, berencana segera melakukan multihoming IPv6, memiliki 13 end site dalam 1 tahun, menggunakan 2.000 alamat IPv6 dalam 1 tahun, dan menggunakan 200 subnet /64 dalam 1 tahun
  • Untuk saat ini, tidak ada hal besar yang terlewat. Suatu saat perusahaan besar seperti Google dan Cloudflare mungkin akan lelah dengan biaya alamat IPv4 yang makin mahal dan memberi insentif untuk IPv6. Misalnya, mereka bisa mulai membatasi IPv4
    Tanda-tanda awalnya sudah ada. AWS dulu hanya mengenakan biaya untuk alamat IPv4 Elastic IP yang tidak digunakan, tetapi sekarang mengenakan biaya terlepas dari digunakan atau tidak. Sejujurnya, cukup siapkan saat nanti meng-upgrade gateway atau router berikutnya; saat ini tidak ada yang benar-benar terlewat. IPv4 dan IPv6 juga bisa digunakan bersamaan. Perangkat yang hanya mendukung IPv4 tetap berjalan baik meski IPv6 dinyalakan di router. Satu hal yang perlu diperhatikan adalah auto-discovery IPv6 dulu sempat cukup berantakan. Ada SLAAC, konfigurasi alamat otomatis IPv6, dan DHCPv6, sementara konfigurasi alamat otomatis awalnya bahkan tidak mendukung penerimaan server DNS. Sekarang ini mulai terkonsolidasi ke arah SLAAC, tetapi ISP akan tetap memakai DHCPv6 untuk waktu yang sangat lama