y2blog » コンテンツプロバイダのアクセス制限を回避する方法

10

11

2020

コンテンツプロバイダのアクセス制限を回避する方法

海外(国内)にトンネルサーバを立ててみる


Apple TV
日本では見られないコンテンツも沢山視聴可能

NASA TV
NASA TV

NASA TV  Tracking the I.S.S.
現在のI.S.S.の軌道を確認することもできる

ABC News
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アドレス詐称だけでは、アクセス制限を回避できないパターンも増えているようなので、クライアント側の偽装テクニックもそれに合わせて向上させて行く必要があるようだ.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のユーザ制限(一人あたりの同時利用ポート数:1024、動的IPv4アドレスの割り当て)が問題になる場合や、サーバ管理などで特定(固定)のIPv4アドレスを使用したい場合などでも有効だろう.


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の性能は殆ど関係ないので、単純に通信量でプランを選択する.


サーバを構築可能なリージョンはアメリカ本国だけではなく、日本やヨーロッパ、アジアなどにもあるのでアクセスしたいコンテンツプロバイダに合わせてリージョンを選べば良い.


VULTRの期間限定(30日間)お友達紹介クーポン(https://www.vultr.com/?ref=7193145)を使うと、$100の無料利用枠が貰えるという、この手のサービスによく有るアフィリエートプログラムの模様.


Vultr VPS
今回は西海岸(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を設定するのを忘れずに.



Vultr FW
基盤側の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
#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
  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
  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)# 


My Private IPv4 over IPv6 Tunnel
IPv4アドレスがアメリカ合衆国の物として認識されていることを確認

今回の西海岸に設置したVPS経由で Appleのホームページにアクセスしてみると、HTTPレスポンスの差は想像以上に大きかった.ストリーミングコンテンツの垂れ流しなので、遅延そのものはコンテンツの再生品質にあまり影響を与えていないだろう.


US Apple HTTP Respons
アメリカ国内のApple(U.S.)サイトへのアクセス

JPN Apple HTTP Respons
日本のApple(JPN)サイトへのアクセスは太平洋を往復するので流石に遅い

Calendar

November 2020
S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930  
  • Blogroll

  • Meta