量子プログラミング入門→量子コンピューティングサービス構築入門

量子コンピューター初心者の筆者が日々学びながら、量子コンピュータ上で量子プログラミングできるようなるまでの学習日記を記録していきます。 内容は量子コンピューター入門者向けで、専門家の方からするとおかしな内容があるかもしれません。その際はコメント等でお知らせください!

無料プロキシサーバ公開

自分の勉強もかねてプロキシサーバを立ち上げてみた。 自分の実験などいろいろ行いたいが、大半は使ってない状態で、ただずっと立ち上がってるので一般公開します。 それでも無差別にアクセスされるのは嫌なので、IDとPassword認証だけは入れておきます。 でも入力しやすいようにパスワードは簡単なのにします。

パスワードは定期的に更新するので、この記事で最新のパスワードを公開していきます。

プロキシサーバの性能

すごく小さなサーバーを使っていますが、自分一人で使っている状態だとそれなりの速度は出ています。80Mbpsなら動画視聴などにも十分性能がでるので悪くないと思います。ただシングルCPUのインスタンスなので、利用者が複数になってくると極端に性能が落ちるかもしれません。利用者がどれぐらい増えるかわかりませんが、無償なのでとりあえずベストエフォートということでご容赦ください。
proxy_speedtest






プロキシアクセス情報

情報更新日2020-11-22 13:33:24.542493 (JST)
アドレスhttp://proxy.northshorequantum.com
ポート番号3128
場所日本・東京
User IDuser
Passwordsy

不正利用防止のためパスワードは24時間に1回程度の頻度で更新しますので、定期的にこのページを見に来てください。

iOSでのプロキシ設定方法について

iPhoneでプロキシの設定を行う方法を説明しておきます。
1) 設定からWi-Fiを選択します IMG_4855

2) 接続しているWi-Fiの(i)マークをタップします。 IMG_4856

3) 一番下にプロキシ設定があるので、プロキシ設定を選択します。
IMG_4857
4) 下記の画像のように認証(Authentication)を有効にして、Server, Port, Username, Passwordを設定します。
IMG_4858






Proxyサーバを使っていろいろ実験をしたいと思ったのでAWSのEC2 Ubuntuのインスタンス上でSquidでProxyを立てた時のメモ

Docker環境構築

EC2のインスタンスを立ち上げるところは省略します。
Ubuntuのインスタンスを立ち上げた後にこちらを参考にDockerをインストールします。

一連のコマンドは下記
sudo apt update

sudo apt upgrade

sudo apt-get install -y\
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -


sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \                 
   $(lsb_release -cs) \                                                         
   stable"

sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io -y

sudo usermod -aG docker ubuntu

squidのdocker imageをとってくる

こちらのdocker imageを使います。下記のコマンドでdocker imageをとってきます。
sudo docker pull sameersbn/squid:3.5.27-2

squidの設定変更

アクセスコントロール

下記の部分は自分のアクセス元に合わせて設定してください。
acl mynet src 192.168.0.10

てっとり早く動かしたい方はhttp_access allow mynetを
http_access allow all

とすれば動きます。

匿名化設定

こちらのサイトを参考に設定変更を加えていくが、squidがversionアップされているので、ディレクティブ名が変更になっているので要注意。header_accessとなっているところは、request_header_accessに変更する。
匿名化設定として追加したのは下記5つ
visible_hostname none
forwarded_for off
request_header_access X-FORWARDED-FOR deny all request_header_access VIA deny all request_header_access CACHE-CONTROL deny all

最終版

squid.confはとてつもなく巨大なので、コメント以外の部分を抽出するとこんな感じです
acl SSL_ports port 443
acl Safe_ports port 80		# http
acl Safe_ports port 21		# ftp
acl Safe_ports port 443		# https
acl Safe_ports port 70		# gopher
acl Safe_ports port 210		# wais
acl Safe_ports port 1025-65535	# unregistered ports
acl Safe_ports port 280		# http-mgmt
acl Safe_ports port 488		# gss-http
acl Safe_ports port 591		# filemaker
acl Safe_ports port 777		# multiling http
acl CONNECT method CONNECT
http_access deny !Safe_ports
acl mynet src 192.168.0.10
http_access allow localhost
http_access allow mynet
visible_hostname none
forwarded_for off
http_port 3128
coredump_dir /var/spool/squid
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern .		0	20%	4320
request_header_access X-FORWARDED-FOR deny all
request_header_access VIA deny all
request_header_access CACHE-CONTROL deny all

Docker立ち上げ

Dockerを立ち上げる時に下記のコマンドのように自分の作成したsquid.confを指定して立ち上げます。ローカルのsquid.confの置き場所は自分の環境に合わせて変更してください。
sudo docker run --name squid -d --rm --publish 3128:3128 -v /srv/docker/squid/cache:/var/spool/squid -v $(pwd)/etc/squid.conf:/etc/squid/squid.conf sameersbn/squid:3.5.27-2

Proxy匿名度診断

診断君で診断した結果はAまたは生IP、CACHE-CONTROLまで設定しましたが、20%の確率でプロキシかもとのこと。

ちなみに、このプロキシを使ってDAZNにアクセスすると下記のようにDAZN IS NOT AVAILABLE IN THIS COUNTRYとなります。つまりDAZNにはProxy認定(?)されています(笑) 
(日本国内から日本国内に立てたProxyを経由してアクセスしています)
DAZNなどのコンテンツサイトはIPアドレスでNGとしている場合が多いので、AWSのIPアドレスでNGを食らってるのかもしれません。

dazn_deny


ちなみに、先日紹介したAblenetのVPS経由だとDAZNはきちんと表示されました。(2020年10月時点)
一方で、AWSに立てたインスタンスからだとDAZNは上記のProxy経由と同じように、NOT AVAILBLEになります。DAZNはProxyかどうかの判断もしているのと、アクセス元がAWSのIPアドレスの場合などに対してもガードしているようです。





こちらの記事で WindowsのVPSを使ってリモートデスクトップ接続する記事を書いたが、AWSのUbuntu Desktopでリモートデスクトップ接続できないか実験してみた。

PuTTYのインストール

PuTTYは検索すればすぐに出てくるが、ダウンロード先のリンクはこちら

AWSでインスタンス立ち上げ

イメージの種類はUbuntu20.04を選択
AWS_Instance_Ubuntu


インスタンスの種類はt2.mediumにする。(t2.microだとChromeがほとんど動かないくらい重い)
AWS_Instance_Type


基本的にはデフォルトの設定で問題ないが、気を付けるのはセキュリティ設定でSSHの22番ポートがきちんと開いていることを確認しておく。(デフォルトから変更しなければ問題ない)

インスタンス生成時にSSHの鍵ファイルをダウンロードする。(あらかじめ生成しておいたものでもよい)
AWSの鍵ファイルはpem形式だが、PuTTYが受け付けるのはppk形式なので変換が必要だこちらの情報を参考にpemファイルを ppkに変換する。自分の場合はWSLからputtygenを使って変換した。(WSLのインストールの仕方はこちら)

PuTTYの設定

Ubuntu側のリモートデスクトップ設定が終わったら、PuTTY側でクライアントからのSSH接続の設定を行う。
  1. Host NameにインスタンスのパブリックIPアドレスを入力する
  2. 設定を保存しておいたほうが便利なので、Saved Sessionsに名前を入力しSaveを押す
  3. SSHメニューの中のAuthを開き、先ほど生成したppkファイルを設定する
PuTTY Configuration 2020_10_18 19_02_52

PuTTY Configuration 2020_10_18 19_03_01

Ubuntuのリモートデスクトップのインストールおよび設定

以下のコマンドを実行し、Ubuntuのリモートデスクトップのインストールおよび設定を行う
sudo apt update && sudo apt upgrade
sudo sed -i 's/^PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo /etc/init.d/ssh restart
sudo passwd ubuntu
sudo apt install xrdp xfce4 xfce4-goodies tightvncserver
echo xfce4-session> /home/ubuntu/.xsession
sudo cp /home/ubuntu/.xsession /etc/skel
sudo sed -i '0,/-1/s//ask-1/' /etc/xrdp/xrdp.ini

AWSのUbuntuのインスタンスはデフォルト設定ではパスワード認証でログインできないようになっているが、途中で認証の設定を変更し、パスワード認証でログインできるようにするとともにパスワード設定を行っている。
新しいパスワードを入力するように聞かれるので、新しいパスワードを設定する。

Puttyでトンネリング設定

今回はUbuntu側でリモートデスクトップのポートを開いて接続するのではなく、すでに開いているSSHの22番のポートを利用してSSHの中にRDPのプロトコルをトンネリングさせる。少しわかりにくいが下記の図のように、SSH接続が土管(トンネル)となってその中をリモートデスクトップのプロトコルが流れるイメージだ。
ubuntu_tunneling
PuTTYの設定は
  • Source Portに8888
  • Destinationに (Local IP Adressを172.31.3.223とした場合) 172.31.3.223:3389
と入力しAddボタンを押す。
PuTTY Configuration 2020_10_18 20_07_28

この設定をした後に再度PuTTYでUbuntuのインスタンスにSSH接続する。

リモートデスクトップ接続

次にWindowsの端末からリモートデスクトップ接続する。この際に先ほどPuTTYで設定したように接続先を「loclahost:8888」とする。
rdp_client


下記のような画面が現れここでUbuntuで設定したパスワードを入力しログインする。
localhost_8888 - リモート デスクトップ接続 2020_10_18 16_43_48

Google Chromeのインストール

Ubuntuにログインできたらブラウザをインストールする。ここではGoogle Chromeのインストール方法を紹介しておく。Ubuntu上でのGoogle Chromeのインストールは下記のコマンド2つで実行
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb

インストール出来たら左上のメニューからGoogle Chromeが起動できるようになっている。
localhost_8888 - リモート デスクトップ接続 2020_10_18 17_39_44

所感

UbuntuなのでWindowsと比べてサクサク動くことを期待していたが、Ubuntuのリモートデスクトップ環境はかなり重たく、4GBメモリではGoogle Chromeを動かすのでさえもカクカクして実用レベルになかった。AWS上のUbuntuはデスクトップ用途には向いていないので、デスクトップを使いたいのであればおとなしくWindowsのインスタンスを使うほうが良いと思う。
EC2でインスタンスを立ち上げるのも久しぶりにやるとけっこう複雑で、こちらで紹介したAblenetのWindows VPSのほうが楽ちんで初心者にも使いやすいと思いました。


Windows Server 2012をリモートデスクトップで使ってみる

コロナの影響でテレワークがより普及されてきて、いろいろな場所から作業する機会が増えてきた。ノートパソコン1つで作業できるならよいが、データがたくさん詰まったラップトップを持ち歩くのに気が引ける場合もあるので、常にリモートで同じ環境にアクセスできるようにWindowsのVPSを試してみた。
今回試してみたのはAblenet(エイブルネット)のWindows Desktop環境を使ってみた。一番安いプランだと月々1981円で今ならキャンペーン価格でさらに安く、メモリも1.5GBに増量されておりお得になっている。
OSはWindows Serverの2012になっており、通常のデスクトップOSと異なる部分もあるので、最初に実施した設定をまとめてみた。

接続

通常のリモートデスクトップアクセスと変わりません。リモートデスクトップのアプリを起動します。この際に念のため音声の設定を確認しておきます。
login2

リモートデスクトップで音声が再生できるようになっているのと、テレワークなどでマイクも使用したい場合は、リモートオーディオ録音も「このコンピュータから録音」にしておきます。

login3

IEのセキュリティ設定の解除

「Internet Explorerセキュリティ強化の構成」でほぼほぼすべてのアドレスにアクセスするたびに警告メッセージが出ます。
IE_Warning
「Internet Explorerセキュリティ強化の構成」を解除するにはサーバーマネージャーを開き、ローカルサーバーを選択します。サーバーマネージャーはWindowsメニューの中から選択できます。
IE_Security_Disable
左メニューから「ローカルサーバー」を選択し、右側から「IEセキュリティ強化の構成」の「有効」をクリックすると設定変更画面がでるので、ここで設定を「無効」にします。

Chromeのインストール

さすがにIEだけでは、いろいろ不自由があるのでGoogle Chromeなどの新しい目のブラウザをインストールしておきます。

VPS側のサウンドの設定

端末側のサウンド設定は接続時に設定してありますが、VPS(Windows Server 2012)側はデフォルトでオーディオデバイスが無効になっています。このままでは音声を再生できないのでオーディオデバイスを有効にします。
まずコントロールパネルを開き、ハードウェアを選択します。

audio

次にサウンドを選択するとオーディオサービスを有効にするか聞かれますので、「はい」を押して有効にします。

audio2


これで接続元の端末からも音声が使えるようになり、テレワークでのリモート会議や動画視聴が可能になります。


使用した感想

一番下の最低構成(2 core, 1.5GBメモリ)の詳細は下記 (あくまで自分に割り当てられた構成で、Ablenet側が保証している仕様ではないのでご注意を)


CPUXeon E5 2667 v3 (2仮想CPU)
メモリ1.5GB
*カタログ上は2coreだが、システム上は2仮想CPUとのこと、2コアなのか2threadなのかはわからなかった

性能的には動画視聴などブラウジング程度ならサクサク動き十分に使える。メールやブラウザ、簡単な資料作成といった軽い作業しかしないのであれば外出先かアクセスできる個人環境として十分である。
(真っ黒な画面だがyoutube視聴中)

spec


気になるのは立ち上げただけで0.6GBのメモリを使用し、Chromeを開いてyoutubeを視聴した時点で1.1GBのメモリを使用となり、たくさんアプリを立ち上げる場合はメモリが不足しそうなので、ライトユーザーには一番下の構成で十分だが、メインの環境として使うには少し物足りないかもしれない。

使い方により構成を適切に選択する必要はあるが、月々2000円以下でリモートのWindows環境を使えるのは非常に便利だと思う。


Google DriveのRate Limit



 ここ最近Google Driveを使ってシステム構築できないかいろいろ試してきたが使っていてなんだか不安定だなと思っていたのだが、プログラムの問題ではなくGoogle Driveのアクセス制限(Rate Limit)であることに気が付いた。

事前にあまり情報がなかったので帯域や通信制限がどのようになっているのか気にはなっていたが、特に制限はないと勘違いしていたが、明確にアクセス回数制限に上限があるようだ。


Google DriveのRate Limitの確認方法


まずGoogle APIのダッシュボード画面に行くDashboard
Google Driveを使っている場合、画像のようにGoogle Drive APIへのリンクが出ている。
ここをクリックしGoogle Drive APIのダッシュボードに移動する。

gd_dashboard

ここで左のメニューから"割り当て"をクリックする。

gd_rate_limit
そうすると、Google Drive APIのRate Limitが表示される。
無料会員の場合、下記のような制限になってると思います。

Queries per day: 1,000,000,000
Queries per 100 seconds per user:  1,000
Queries per 100 seconds: 10,000

100秒間に1000リクエストの制限があるので短時間で大量にファイルをアップロードするような処理をpyDriveで実装しても、Rate Limitに引っかかってしまいプロセスがkillされてしまう。google-drive-ocamlfuseが不安定だったのもこのせいだと思われたが、100秒当たりのコール数を確認しても1000コールにほど遠い状況。1日のコール数も全然少ないので問題ない。


gd_api_rate


何か他にもありそう。
pythonのプログラムが"Killed"のメッセージだけ残して落ちるのでほぼほぼ手掛かりがないが、exceptionに引っかかってるわけではないので、外部(OS)からKillされているっぽい。
topコマンドでメモリ使用量を見てると、流してくとメモリ使用量が徐々に増えているのがわかる。
プログラムはほぼほぼここで公開しているものと同じだが果たしてどこでリークしているのか...






↑このページのトップヘ