10
11
2020
コンテンツプロバイダのアクセス制限を回避する方法
海外（国内）にトンネルサーバを立ててみる
日本では見られないコンテンツも沢山視聴可能
NASA TV
現在のI.S.S.の軌道を確認することもできる
ABC News
日本でもインターネットベースのコンテンツ配信サービスが普及したことにより、これらのサービスに加入してビデオコンテンツや音楽ストリーミングサービスを利用する機会が増えている．
これまではTidalなどの高音質配信サービスは日本からは利用できないようにアクセス制限が掛けられていて、悔しい思いでサービスの利用を諦めて居た人たちが多かったが、Amazon Music HD が日本でもサービスを開始したので、高音質音楽配信に関してはようやく世界の流れに追いついたといったところだろうか．
音楽配信に限らず、映像系のコンテンツサービスなども権利関係の制約から有料のコンテンツサービスに関しては国を跨いでのサービスは殆ど実施されていない．インターネットの世界では、この地域（国）限定のサービスをシステム的に行うのは結構厄介で、コンテンツプロバイダー側はIPアドレスDBを使ってアクセスを許可する地域や国を限定しようとするのだが、これがトラブルの元となっている．
現在はIPv4アドレス自体が完全に枯渇した状態で、IPv4アドレスの新規割り当て（払い出し）は完全にできない状態で、現在末端のユーザに割り振られているIPv4アドレスは、I.S.P. などが既に所有している範囲をユーザに切り出しているだけだ．
このような状況なので、I.S.P.ではそれぞれが所有しているIPv4アドレスの小ブロック（断片）を、相手先に譲渡したり、相手側から譲り受けたりしてIPv4アドレスの不足に対処している．IPv4アドレスの所有者はめまぐるしく変わっているので、何ヶ月も前の情報に基づいて構築されたIPv4アドレス情報データベースなど、全く信用できない物となっている．
NURO光がなりふり構わず加入者を増やしているので、世界中からSo-netコミュニケーションズがIPv4アドレスを買い漁っており、入手してから塩漬けもせずに直ぐにエンドユーザにIPv4アドレスを割り当ててしまうので、コンテンツプロバイダー側のIPv4アドレスデータベースに反映されずに、海外からのアクセスと判定されてサービスから閉め出されるというパターンが増えている．
もし、自分の使っているプロバイダから割り当てられたIPアドレスについての詳細を知りたければ、日本のIPアドレス管理の元締めのJPNICやAPNICの検索サービスを使って調べて見ることをお薦めする．
・JPNIC WHOIS Gateway
前置きが長くなってしまったが、今回は地域（国）制限の掛けられているサービスに対して、小細工を施してアクセス制限を回避する方法について紹介する．但し、対象とするのはLinuxなどの環境を自分で構築したり、ルータなどのネットワーク機器をコマンドレベルで取り扱うことのできる、所謂エキスパートと呼ばれている人たちなので、一般レベルのユーザは、Interlinkの『世界VPN』などの商用VPNサービスを利用するのが無難だろう．
IPアドレスを偽装する方法
『偽装』などと書くと何かとても後ろめたいことをしているような気になるが、要は海外（国内）に籍を置く正当なサーバのIPアドレスを使って（借りて）、目的のコンテンツサービスにアクセスすることで、コンテンツプロバイダの地域（国）制限を回避するだけのことだ．
一番簡単な方法は、海外（国内）のクラウドサーバやVPSサーバ上に “Squid” などのWEBプロキシサーバを立てて、PCなどのWEBブラウザをこのプロキシサーバを介してアクセスすることで、アクセス制限を回避することが可能だ．但し、コンテンツプロバイダ側ではHTTPヘッダなどの情報を分析して、プロキシサーバ経由のアクセスを弾く仕組みを導入している場合もあるようなので、試行錯誤が必要だろう．
最近のコンテンツプロバイダ側のアクセス地域判定の仕組みもインテリジェント化されているようで、単純なIPアドレス詐称だけでは、アクセス制限を回避できないパターンも増えているようなので、クライアント側の偽装テクニックもそれに合わせて向上させて行く必要があるようだ．
“Disney Channel”, “National Geo TV” などは、今回の方法では米国内ではないのでアクセスできない旨のエラーメッセージが表示されてアクセスできなかった．AWSやVultrなどのメジャーなクラウドサービスに関するIPアドレスの情報を持っていて、これらのサービスからのアクセスを弾いているのかもしれない．
DS-Lite方式ではIPv6アドレスは日本のVNEプロバイダのアドレスでアクセスしてしまうので、IPv6アドレスも現地のサーバのIPv6アドレスで出て行くように設定を変更する必要がありそうだね．エンドユーザとコンテンツプロバイダとの間のイタチごっこが延々と続くということだろうか．
PCのWEBブラウザの場合はWEBプロキシの設定は簡単だが、Apple TVでは “Apple Configurator 2” で WEB Proxyを設定しなければならないので、セットトップBOX型のデバイスでは事前にWEBプロキシの利用が可能かどうか確認が必要だ．
今回は、クライアントデバイス側が制限されるWEBプロキシ方式ではなく、全てのクライアントデバイスが透過的に利用可能なネットワーク型のプロキシを立てることとする．ネットワーク型のプロキシと言っても、DS-Lite方式のAFTRのような専用のアプリケーションを動かすのではなく、単にLinuxサーバ上で、IPv4 over IPv6トンネルを作成し、サーバ上のグローバルIPアドレスによるNAPT（IPマスカレード）を経て、相手先（コンテンツプロバイダ）のサーバに接続するだけだ．簡単に言うと、超簡略化版『なんちゃってDS-Lite』ということだろうか．
TransixサービスでのAFTRの実装方法は不明だが、DS-LiteやAFTRの実装に参考になりそうなリンクを幾つか載せておく.
・DS-Lite Host Profile for MAEMO (OS2008 version)
http://ds-lite.garage.maemo.org
・DS-Lite: Implementation experience and views
https://www.prolixium.com/share/DSLite_Implementation_Experiences.pdf
・IPv6 Transition Technologies Yasuo Kashimura(Japan, APAC IPCC) Alcatel-lucent
https://meetings.apnic.net/31/pdf/Apricot_IPv6_transition_kashimura_rev3.pdf
・Using DS-Lite with CGNAT ”Ask F5″
https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-cgnat-implementations/using-ds-lite-with-cgnat.html
今回は映像コンテンツを取り扱う関係で、転送スピードの低下や遅延を防ぐため通信路（トンネル）の暗号化は行わないこととする．映像コンテンツを垂れ流しするだけなので、あまり神経質になる必要はないだろう．心配で有れば、IPSecなどを使った暗号化されたVPN経路を構築すれば良い．
今回の元ネタ
IPoE方式によるサービスの黎明期（まだ市販のルータにも実装されていないような時代）に、一部の先進的な人たち（多分この業界の関係者？）が、試行錯誤的にIPoEに取り組み始めたときの勉強会のプレゼン資料？『さくらのVPSでIP4 over IPv6 ルータを作ってみた』by Tomocha が SlideShare で公開されている．
このプレゼン資料で公開されている情報を参考に、海外のVPSサーバで同じ事を実装してみたので、エキスパートの方々であれば簡単に試すことができそうなので、簡単に紹介することにする．勿論、以前紹介した、I.S.C.のAFTRプログラムを自分でコンパイル＆実装して本格的AFTRを構築することも可能なので、頑張って Private AFTR を運用するという選択肢も有る．但し、AFTRプロジェクト自体は2010年12月の最終リリースを持って終了しており、とうの昔にEOSとなっているので、セキュリティー面での不安要員を抱えているので実運用には向かないだろう．
海外にサーバを立てる
海外にサーバを立てるのはさくらインターネットやConoHaなどの国内ベンダーを利用したことがあれば、構築の作業などは殆ど直感的にできる筈だ．今回利用したのは VULTR というアメリカに本拠を置く会社で、定額ベース（但し、通信料は制限を超えると従量制）で使えるクラウドライクなVPSサービスを展開している．
今回はテストなので、とりあえず [ 1 VCPU, 1GB Mem, 25GB SSD, 1 TB/monnth : $5/month ] というプランを利用する．私の場合、Apple TV 2台で、一日数時間程度（主に Bloomberg TV）を見ている事が多いが、1日あたり 30GB程度の通信量なので、通信総量はギリギリ1TB以内に収まる見通しだ．超過した場合は、1GBあたり$0.01 なので、大幅に通信量が増えそうな場合は、その一つ上のクラスのVPS[ 1 VCPU, 2GB Mem, 55GB SSD, 2 TB/monnth : $10/month ] を選んだ方が安くつくかもしれない．今回は CPUの性能は殆ど関係ないので、単純に通信量でプランを選択する．
サーバを構築可能なリージョンはアメリカ本国だけではなく、日本やヨーロッパ、アジアなどにもあるのでアクセスしたいコンテンツプロバイダに合わせてリージョンを選べば良い．
今回は西海岸（Silicon Valley）に CentOS7 で構築
VULTRのVPSサービスのWEB GUIは直感的に操作可能なので、設定に苦労することはないだろう．ConoHaのVPSサービスと同じように各種APIが公開されている．また、OS側でFirewalldのような機能を設定しなくても、VPS基盤側でFirewallを設定する事ができ、簡単なWEB GUIベースで色々設定できるので、ConoHaのVPSのような面倒で複雑な手続きは必要ない．
今回は、この基盤側のFirewallをVPSに設定し、自宅などの特定の環境からしか接続できないように構成する．このVPS自体は IPv4 over IPv6 トンネル側から外部側へNAPT（IPマスカレード）で出て行くだけなので、外部からのinboundアクセスは閉じておく．第3者に勝手にこのトンネルサーバを悪用されないようにきちんとFirewallを設定するのを忘れずに．
基盤側のFirewallはGUIベースで簡単に設定可能
IPv4 over IPv6 Tunnel 作成
IPv4 over IPv6 Tunnel 作成に関しては先の『さくらのVPSでIP4 over IPv6 ルータを作ってみた』に記されているので、設定例だけを簡単に示す．
先ずは、IPv4パケットがインタフェースを跨がって通信ができるようにカーネルパラメータを設定する．OS起動時に自動的に設定させる場合はコマンドレベルでなく、 カーネルパラメータ設定ファイル “/etc/sysctl.conf” に下記のパラメータを記載しておく．今回は必要ないが、最後の行は将来の拡張(AFTRプログラムの導入など）を行うかもしれないので、ipv6での転送設定も入れてある．
[ カーネルパラメータの設定 ]
#sysctl -w net.ipv4.conf.all.forwarding=1
#sysctl -w net.ipv4.conf.eth0.rp_filter=0
#sysctl -w net.ipv4.conf.tun0.rp_filter=0 <=== "tun0" 作成後に実行する
#sysctl -w net.nf_conntrack_max=65535
#sysctl -w net.ipv6.conf.all.forwarding=1
[ipv6 tunnel 機能の有効化 ]
#modprobe ip6_tunnel
[ ipv4 over ipv6 Tunnelインタフェースの作成 ]
#ip -6 tunnel add tun0 mode ip4ip6 remote 2409:zzzz:zzzz:zz6:zzz:zzzz:fee2:4624 local 2001:yyyy:yyyy:yyy:yyyy:yyy:fe01:e8f3 dev eth0
remote : 自宅ルータ側のトンネルインタフェースのIPv6アドレス
local : VPS側の eth0 インタフェース（公開）のIPv6アドレス
[ TunnelインタフェースのMTUサイズ調整（※必要に応じて） ]
#ifconfig tun0 mtu xxxx
[ ipv4 over ipv6 Tunnelインタフェースのアクティベート ]
#ip link set tun0 up
[ ipv4 over ipv6 Tunnelインタフェース "tun0" へのIPv4アドレス割り当て ]
#ip addr add 192.0.0.1/30 dev tun0
[ 自宅ルータ側のトンネルインタフェースを置く側のネットワークへのルーティング情報追加 ]
#route add -net 192.168.102.0/24 dev tun0
[ NAPT（IPマスカレード）の設定 ]
#iptables -t nat -F
#iptables -t nat -A POSTROUTING -j MASQUERADE
上記の設定で、ipv4 over ipv6 Tunnelインタフェースの中で使われるIPv4アドレスとして、192.0.0.1/30（AFTR側）、192.0.0.2/30（B4：自宅ルータ側）という正体不明なアドレスが定義されているが、DS-Lite方式では、この一対のIPV4アドレスが予約アドレスとして一般的に使われている．必ずしもこのアドレスを使う必要はないようだが、この予約アドレスを設定する方が無難だろう．尚、下記に示すIX2215の実装例では、メーカーの実装例に倣ってTuunelインタフェースでのIPv4アドレスを "unnumbered" で設定しているが、 "ip address 192.0.0.2/30" と明示的に設定しても同じように動作する．
NAPT（IPマスカレード）の設定は Firewalld を稼働させる場合は、"public zone" 側と "trusted zone" などを設定すれば自動で設定されるが、今回はFirewalldは使用していないので、手動で設定している．
[root@usgw102 ~]# ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 56:00:03:01:e8:f3 brd ff:ff:ff:ff:ff:ff
inet 144.xxx.xxx.178/23 brd 144.xxx.xx1.255 scope global dynamic eth0
valid_lft 85971sec preferred_lft 85971sec
inet6 2001:yyyy:yyyy:yyy:yyyy:yyy:fe01:e8f3/64 scope global mngtmpaddr dynamic
valid_lft 2591801sec preferred_lft 604601sec
inet6 fe80::yyyy:yyy:fe01:e8f3/64 scope link
valid_lft forever preferred_lft forever
3: ip6tnl0@NONE: mtu 1452 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd ::
4: tun0@eth0: mtu 1452 qdisc noqueue state UNKNOWN group default qlen 1000
link/tunnel6 2001:yyyy:yyyy:yyy:yyyy:yyy:fe01:e8f3 peer 2409:zzzz:zzzz:zz6:zzz:zzzz:fee2:4624
inet 192.0.0.1/30 scope global tun0
valid_lft forever preferred_lft forever
inet6 fe80::d03f:42ff:fe9d:1165/64 scope link
valid_lft forever preferred_lft forever
[root@usgw102 ~]# ip route
default via 144.xxx.xxx.1 dev eth0
144.xxx.xxx.0/23 dev eth0 proto kernel scope link src 144.xxx.xxx.178
169.254.169.254 via 144.xxx.xxx.1 dev eth0 proto static
192.0.0.0/30 dev tun0 proto kernel scope link src 192.0.0.1
192.168.102.0/24 dev tun0 scope link
[root@usgw102 ~]#
自宅用ルータ側の設定
自宅用ルータ側の設定は、個々の環境に依存するので具体的な設定方法は示すことができないが、私の環境では NECのIX2215を用いているので、その環境での設定例を示す．先の記事『Transixサービスで固定IPとDS-Liteによるマルチホーム化を試みる』で、TransixのDS-Lite環境(Tunnel0.0) と固定IP環境(Tunnel1.0）とをVLANで分け、ポリシールーティングを用いてVLAN毎にDS-Lite側と固定IP側とに宛先を振り分けた．
今回も同じように、VLAN100 ⇒ DS-Lite、VLAN102 ⇒ 『なんちゃってDS-Lite』 側へポリシーベースルーティングで振り分けてみる．
Tunnel1.0インタフェースのMTUとMSSの値の調整が厄介で、このサイズが大きすぎると相手先によってはパケット分割が上手く機能せずに、パケットが消失してしまう可能性がある．IPSecやGRE Tunnelなどのトンネリング方式の通信では、このMSSとMTUのサイズの調整に失敗して、原因不明の通信不能に陥るケースが多々ある．
IX2215ではデフォルトのMTUは1500となっているが、今回はTunnel1.0のMTUを小さめに設定してある．MSSはこのMTUサイズに合わせて自動調整するように設定してある．MTUを小さくすると転送スピードが遅くなるので、パケット消失を起こさない範囲でMTUサイズを最大化するのは難しい．
MTUサイズの問題かどうかはハッキリしないが、AppeTV4Kでは正常にアクセスできても何故かAppleTV 3では同じサイトにアクセスできない現象が発生するなど、原因不明な現象が起きていた．IP-SEC方式でもこのMTUサイズの調整が肝で、不適切なMTUを設定すると通信ができないという症状が発生する．
ip ufs-cache max-entries 20000
ip ufs-cache enable
ip route default Tunnel0.0
ip route 10.9.8.0/24 192.168.100.1
ip route 192.168.99.0/24 192.168.100.1
ip dhcp enable
ip dhcp-relay enable
ip access-list icmp-all permit icmp src any dest any
ip access-list nuro-acl permit ip src 192.168.200.0/24 dest any
ip access-list pppoe104 permit ip src 192.168.104.0/24 dest any
ip access-list vpn102 permit ip src 192.168.102.0/24 dest any
!
...
ipv6 ufs-cache max-entries 10000
ipv6 ufs-cache enable
ipv6 dhcp enable
ipv6 access-list allow-outboud permit ip src any dest any
ipv6 access-list dhcpv6-list permit udp src any sport any dest any dport eq 546
ipv6 access-list dhcpv6-list permit udp src any sport any dest any dport eq 547
ipv6 access-list icmp6-all permit icmp src any dest any
ipv6 access-list icmp6-nd permit icmp neighbor-solicitation src any dest any
ipv6 access-list icmp6-nd permit icmp neighbor-advertisement src any dest any
ipv6 access-list icmp6-nd permit icmp redirect src any dest any
ipv6 access-list icmp6-nd permit icmp echo-reply src any dest any
ipv6 access-list icmp6-nd permit icmp echo src any dest any
ipv6 access-list ip-tunnel-allow permit 4 src any dest any
ipv6 access-list nurov6-acl permit ip src 240d:xxxx:xxx:xx00::/56 dest any
ipv6 access-list reject-all deny ip src any dest any
ipv6 access-list transix-acl permit ip src 2409:zzzz:zzzz:zz0::/56 dest any
ipv6 access-list dynamic cache 65535
ipv6 access-list dynamic dyn-outbound access allow-outboud
...
route-map routemap-us2 permit 10
match ip address access-list vpn102
set interface Tunnel1.0
!
...
ipv6 dhcp client-profile dhcpv6pd-client
client-identifier duid-ll-ge0
option-request dns-servers
option-request ntp-servers
ia-pd subscriber GigaEthernet2:1.1 0:0:0:64::/64 eui-64
ia-pd subscriber GigaEthernet2:1.2 0:0:0:66::/64 eui-64
ia-pd subscriber GigaEthernet2:1.4 0:0:0:6a::/64 eui-64
ia-pd subscriber GigaEthernet2:1.5 0:0:0:96::/64 eui-64
ia-pd subscriber GigaEthernet2:4.0 0:0:0:fa::/64 eui-64
!
ipv6 dhcp server-profile dhcpv6pdsv100
dns-server dhcp
!
ipv6 dhcp server-profile dhcpv6pdsv150
dns-server dhcp
!
ipv6 dhcp server-profile dhcpv6pdsv250
dns-server dhcp
!
ipv6 dhcp server-profile dhcpv6pdsv102
dns-server dhcp
!
ipv6 dhcp server-profile dhcpv6pdsv106
dns-server dhcp
!
...
interface GigaEthernet0.0
no ip address
ipv6 enable
ipv6 dhcp client dhcpv6pd-client
ipv6 filter dhcpv6-list 1 in
ipv6 filter icmp6-all 2 in
ipv6 filter icmp6-nd 4 in
ipv6 filter ip-tunnel-allow 5 in
ipv6 filter reject-all 100 in
ipv6 filter dhcpv6-list 1 out
ipv6 filter icmp6-all 2 out
ipv6 filter ip-tunnel-allow 5 out
ipv6 filter dyn-outbound 100 out
no shutdown
!
...
interface GigaEthernet2:1.1
description VLAN100-IPoE-Dual
encapsulation dot1q 100 tpid 8100
auto-connect
ip address 192.168.100.254/24
ip dhcp binding vlan100profile
ipv6 enable
ipv6 dhcp server dhcpv6pdsv100
ipv6 nd ra enable
ipv6 nd ra other-config-flag
no shutdown
!
interface GigaEthernet2:1.2
description VLAN102-IPoE-Fixed-Dual
encapsulation dot1q 102 tpid 8100
auto-connect
ip address 192.168.102.254/24
ip dhcp binding vlan102profile
ip policy route-map routemap-us2
ipv6 enable
ipv6 dhcp server dhcpv6pdsv102
ipv6 nd ra enable.
ipv6 nd ra other-config-flag
no shutdown
!
interface GigaEthernet2:1.3
...
!
interface Tunnel0.0
description Transix-DSLite
tunnel mode 4-over-6
tunnel destination 2404:8e00::feed:101 <=== Transix DS-Lite
tunnel source GigaEthernet2:1.1
ip unnumbered GigaEthernet2:1.1
ip tcp adjust-mss auto
ip napt enable
no shutdown
!
interface Tunnel1.0
description VPN-Gateway-2
tunnel mode 4-over-6
tunnel adjust-mtu 1400
tunnel destination 2001:yyyy:yyyy:yyy:yyyy:yyy:fe01:e8f3 <=== 何ちゃって My DS-Lite
tunnel source GigaEthernet2:1.2
ip unnumbered GigaEthernet2:1.2
ip tcp adjust-mss auto
ip napt enable
no shutdown
ix2215-01(config)#
ix2215-01(config)# show int Tunnel1.0
Interface Tunnel1.0 is up
Description: VPN-Gateway-2
Fundamental MTU is 1400 octets
Current bandwidth 1G b/s, QoS is disabled
Datalink header cache type is ipv6-tunnel: 0/0 (standby/dynamic)
IPv4 subsystem connected, physical layer is up, 0:02:36
Dialer auto-connect is enabled
Inbound call is enabled
Outbound call is enabled
Dial on demand restraint is disabled, 0 disconnect
SNMP MIB-2:
ifIndex is 1201
Logical INTERFACE:
Elapsed time after clear counters 0:02:51
633 packets input, 656839 bytes, 0 errors
633 unicasts, 0 non-unicasts, 0 unknown protos
0 drops, 0 misc errors
641 output requests, 78561 bytes, 0 errors
641 unicasts, 0 non-unicasts
0 overflows, 0 neighbor unreachable, 0 misc errors
1 link-up detected, 0 link-down detected
Encapsulation TUNNEL:
Tunnel mode is 4-over-6
Tunnel is ready
Destination address is 2001:yyyy:yyyy:yyy:yyyy:yyy:fe01:e8f3
Source address is 2409:zzzz:zzzz:zzz:zzz:zzzz:fee2:4624
Source interface GigaEthernet2:1.2
Nexthop address is fe80::212:e2ff:fe70:123c
Outgoing interface is GigaEthernet0.0
Interface MTU is 1400
Path MTU is 1500
Statistics:
633 packets input, 656839 bytes, 0 errors
641 packets output, 78561 bytes, 0 errors
Received ICMP messages:
0 errors
ix2215-01(config)#
IPv4アドレスがアメリカ合衆国の物として認識されていることを確認
今回の西海岸に設置したVPS経由で Appleのホームページにアクセスしてみると、HTTPレスポンスの差は想像以上に大きかった．ストリーミングコンテンツの垂れ流しなので、遅延そのものはコンテンツの再生品質にあまり影響を与えていないだろう．
アメリカ国内のApple(U.S.)サイトへのアクセス
日本のApple(JPN)サイトへのアクセスは太平洋を往復するので流石に遅い
補足： IPv4のみの通信に限定したい場合の設定
上記の設定例では、VLAN102セグメント（GigaEthernet2:1.2）配下のクライアントはIPv4とIPv6のデュアルスタックでのアクセスが可能となる．この場合、IPv4は US gateway 経由のアクセスとなるが、IPv6に関しては自分のローカルIPv6セグメントのアドレスによるダイレクト通信となってしまう．
PCなどのクライアントの場合はOS側の設定でIPv6を無効にすることができるが、Apple TV などでは IPv6をユーザ側で無効にすることは簡単にできそうもない．YouTubeなどをApple TVで見ているとIPv6側の通信が優先されてしまい、勝手に日本のYouTubeサイトにアクセスしてしまい残念な結果になってしまう．
日本のYouTubeサイトはコンテンツ再生中でも無理やりCMを挿入されてしまい、とても腹立たしいので何としても日本のYouTubeサイトへの接続は避けたい．CDNの関係でApple TVの場所設定をUSにしていても、日本のIPアドレスからアクセスすると、日本のYouTubeサイトへリダイレクトされてしまうので、IPv6でのアクセスはできないようにしておく方が良いだろう．
クライアント側へIPv6関連の "RA" 通知を行わないように設定すれば、クライアント側に自動でIPv6アドレスが設定されてしまうことを防ぐことができる．
ポリシーベースルーティングを用いて、2つのVLANで別々のTunnelへ振り向ける場合はこんな感じの設定になる．
...
ip access-list vpn102 permit ip src 192.168.102.0/24 dest any
ip access-list vpn104 permit ip src 192.168.104.0/24 dest any
...
route-map routemap-us1 permit 10
match ip address access-list vpn102
set interface Tunnel0.0
!
route-map routemap-jp1 permit 10
match ip address access-list vpn104
set interface Tunnel1.0
!
...
interface GigaEthernet2:1.2
description VLAN102-IPoE-Fixed-Dual
encapsulation dot1q 102 tpid 8100
auto-connect
ip address 192.168.102.254/24
ip dhcp binding vlan102profile
ip policy route-map routemap-us1
ipv6 enable
ipv6 address 2409:zzzz:zzzz:zzz:zzz:zzzz:fee2:4624
no shutdown
!
interface GigaEthernet2:1.3
description VLAN104-JPGW
encapsulation dot1q 104 tpid 8100
auto-connect
ip address 192.168.104.254/24
ip dhcp binding vlan104profile
ip policy route-map routemap-jp1
ipv6 enable
ipv6 interface-identifier 00:00:00:00:00:00:68:fe
ipv6 address 2409:zzzz:zzzz:zzzz:::68fe/64
ipv6 nd ra enable
ipv6 nd ra other-config-flag
no shutdown
!
...
interface Tunnel0.0
description VPN-Gateway-US
tunnel mode 4-over-6
tunnel adjust-mtu 1400
tunnel destination 2001:abcd:ef01:2345:6789:abcd:ef01:2345 <=== US VPS
tunnel source GigaEthernet2:1.2
ip address 192.0.0.2/30 <=== TunnelにIPv4アドレスを設定した例（ <-> 192.0.0.1/30 )
ip tcp adjust-mss auto
ip napt enable
no shutdown
!
interface Tunnel1.0
description VPN-Gateway-JP
tunnel mode 4-over-6
tunnel adjust-mtu 1400
tunnel destination 2400:xxxx:yyyy:zzzz:1111:2222:3333:4444 <=== 日本のVPS
tunnel source GigaEthernet2:1.3
ip address 192.0.0.6/30 <=== TunnelにIPv4アドレスを設定した例（ <-> 192.0.0.5/30 )
ip tcp adjust-mss auto
ip napt enable
no shutdown
ix2215-01(config)#
