カテゴリー: AWS

ec2のsquidでグローバルIPを分散するProxyを作る

これはAdventure Advent Calendar 2018の13日目の記事です。（後追い）

プロキシサーバーと言えばsquidと思い浮かべるように、どメジャーなミドルウェアですが、今回はsquidを使って「複数のグローバルIPでインターネットにアクセスするプロキシサーバー」を作ってみました。

複数人でプロキシサーバーを使ったアクセスを行うと、すぐに接続元IPアドレスによるアクセス拒否が行われてしまうサイトにアクセスする際にどうぞ。

ec2を立てる

インスタンスのサイズによって、インターフェイスあたりの IPv4 アドレスの最大数が異なりますので以下を参考にして下さい。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html

今回はt2.largeにし、
eth0の18080ポートで、外部からの通信を受け入れ、
eth1に9個のセカンダリプライベートIPをアサインして、それぞれにElasticIPを付け、計10個のIPアドレスからインターネットに出るようにしたいと思います。

インスタンスを作る上で注意する点は、最初からeth1を作成する事ぐらいです。
（後からでも追加出来ますが、インスタンスを停止してeth1をアタッチし、また起動するという手間があります）

なお、今回はAmazon Linux 2 AMI (HVM), SSD Volume Typeで作成しています。

インスタンスが起動したら、メニューからIPアドレスの管理を選択します。

eth1側に必要な数分、プライベートIPを割り当てます。
ここでは、DHCPでアドレスが割り当たりませんので、手動で入力していく必要があります。
（当たり前ですが、eth1が所属するサブネットの範囲で割り当てて下さい）

なお、eth1のeni-で始まる管理番号は、次で利用しますので控えておいて下さい。

忘れないように、セキュリティグループの穴あけもやっておきましょう。

ElasticIPを発行する

ElasticIPを発行します。
ここで注意する点は、
eth1のセカンダリIPアドレスに割り当てるElasticIPは、ネットワークインターフェイスでのみ検索、表示出来る。
という点です。
ラジオボタンがインスタンスのままだと表示されません。

複数のグローバルIPアドレス分、この割り当て作業を繰り返します。

squidを立てる

最後にsquidの設定です

sudo yum -y install squid

以下は/etc/squid/squid.confの抜粋です

 # proxyを使う接続元IP
acl mynetwork src xxx.xxx.xxx.xxx/32

 # 今回10個のIPをランダムで使う
acl balance random 1/10
balance_on_multiple_ip on

# LISTENポート
http_port 18080

# 帯域を潰されたくないので、特定の動画サイトのドメインは見せないようにする
acl blacklist dstdomain "/etc/squid/blacklist"
# 非読化
visible_hostname unkown
forwarded_for off
request_header_access X-FORWARDED-FOR deny all
request_header_access Via deny all
request_header_access Cache-Control deny all

# ファイルディスクリプタの上限変更
max_filedesc 65535

# ElasticIPに紐付けたセカンダリIP
tcp_outgoing_address 172.30.2.211 balance 
tcp_outgoing_address 172.30.2.212 balance 
tcp_outgoing_address 172.30.2.213 balance 
tcp_outgoing_address 172.30.2.214 balance 
tcp_outgoing_address 172.30.2.215 balance 
tcp_outgoing_address 172.30.2.216 balance 
tcp_outgoing_address 172.30.2.217 balance 
tcp_outgoing_address 172.30.2.218 balance 
tcp_outgoing_address 172.30.2.219 balance 
tcp_outgoing_address 172.30.2.220 balance

/etc/squid/blacklistには主要な動画サイトのドメインを書いておきます

www.youtube.com
www.nicovideo.jp
gyao.yahoo.co.jp
www.happyon.jp
www.netflix.com

squidの自動起動と開始

sudo systemctl enable squid
sudo systemctl start squid

エラーが無く起動が出来れば、eth0に割り当てたElasticIPの18080をブラウザのプロキシに設定し、IP確認くんなどで通信確認とeth1のセカンダリIPアドレスに割り当てたElasticIPで通信が行えているか確認をしてみて下さい。

wordpress をELB＋EC2でHTTPS通信させる

wordpressの移設に少し手間取ったのでメモ

wordpressやELB、EC2の動かし方は割愛するが、普通のやり方。

ただ、以前に借りていたVPSでLets EncryptでHTTPS化していたブログを移設した。

ハマった所1： wp-adminのリダイレクトループ
管理画面での SSL 通信

リンク先に書いているけど、wp-includes/default-constants.phpの、

[code]
if ( !defined( ‘FORCE_SSL_ADMIN’ ) ) {
if ( ‘https’ === parse_url( get_option( ‘siteurl’ ), PHP_URL_SCHEME ) ) {
define( ‘FORCE_SSL_ADMIN’, true );
} else {
define( ‘FORCE_SSL_ADMIN’, false );
}
}
[/code]

を

[code]
if ( !defined( ‘FORCE_SSL_ADMIN’ ) ) {
if ( ‘https’ === parse_url( get_option( ‘siteurl’ ), PHP_URL_SCHEME ) ) {
define( ‘FORCE_SSL_ADMIN’, true );
if ( ! empty( $_SERVER[‘HTTP_X_FORWARDED_PROTO’] ) && $_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’ ) {
$_SERVER[‘HTTPS’]=’on’;
}
} else {
define( ‘FORCE_SSL_ADMIN’, false );
}
}
[/code]

に変更する。

ハマった所2： WPやプラグイン更新のFTP設定
config.phpの末尾に、

[code]
define(‘FS_METHOD’,’direct’);
[/code]

を記載する。

SQL Server から AWS Auroraにマイグレーションする時の注意事項

オンプレ環境のSQL Server開発機からAWS Auroraにマイグレーションした際、DMS（Database Migration Service）を使って見たので、ハマった処をメモ。
https://aws.amazon.com/jp/dms/

eyecatch_dms-200x200
※仕様をよく読んだら書いてあるのかもしれない。

【移設方法】
オンプレのSQLServerは、DMSからアクセスが出来ないネットワークにある為、セキュリティを弄らずに移設をする方法を考えました。
結果的に、[開発機] – [RDS for SQL Server] – [DMS] – [RDS for Aurora]
と余計なSQLServerを挟んでいます。

20161108_1

【移行時の注意点】
・DMSはスキーマ単位になりますが、Auroraはスキーマの概念がありません。
　SQLServerで
　[db_name1].[dbo].[table_name]
　[db_name2].[dbo].[table_name]
　は別テーブルとして扱われますが、Auroraでは[dbo].[table_name]と単一になります。

　その為、事前にスキーマを[ALTER SCHEMA db_name1 TRANSFER dbo.table_name]等のコマンドで変更しておく必要があります。
　対象は、一般テーブル、システムテーブルです

　また、ストアドもスキーマを変更する必要があります。
　こちらは変更のコマンドが解らなかったので、SSMSでストアドのCreate文作成　→　dboの部分をdb_nameに変更して新規作成を行いました。

・LOBサイズ
　DMSのLOBサイズの上限は、デフォルトで24KBになっています。
　大きめのデータが格納されている場合、この上限に引っかかる場合がありますので、適時変更を行ってください。
　分からなくても、1024KBぐらいあれば十分かと。

・移行元がSQLServerの場合、継続的なレプリケートが出来ない。
　DMSの強みである継続的レプリケート。
　これにより、大容量のデータベースでもダウンタイムを低減させる事が出来ます。
　が、現時点でSQLServerからAuroraへは、レプリケートが行いません。

・IDENTITIYはAutoIncrimentにならない
・datetimeoffset(7)　→　varchar(34)
この辺はエンジンの違いが出てきます。

追加のデータが入らないうちに、Alter Tableで変更しておきましょう。

Elastic CacheにAWS外からアクセスする

基本的にはAWS 外部からの ElastiCache リソースへのアクセスの通り。

Elastic CacheにはAWS以外からのアクセスが出来ないので、
インターネット-[Elastic IP]–[EC2]–[Elastic Cache]
みたいに、中間にEC2インスタンスを噛ます必要がある。

EC2は、PREROUTINGしかt1.microインスタンスでも十分じゃないかな

[code]
#中間のEC2上で

iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 6379 -j DNAT –to ElasticCacheのIP:6379
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables-save

#/etc/sysctl.conf
net.ipv4.ip_forward = 1

sysctl -a
[/code]