nginxでhttps://example.comを受けて、https非対応のApache2にリバプロし、Apache2側でもhttps://example.comでアクセスされているように振舞わせる方法。取り敢えず最低限こんだけあると無難だろうという内容。
80や443を開けるとnginxと衝突するため、適当にずらしておく。
Listen 8080
ServerNameは外側と同じものにする。
<VirtualHost *:8080>
ServerName example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/example-error.log
CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>
httpセクションにupstream apacheを追記することで、conf.d/配下の設定ファイルから共通的に参照できるようにする。同じことを複数の設定ファイルに書くと構文エラーで起動しなくなる。
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log notice;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
upstream apache {
server [::1]:8080;
}
include /etc/nginx/conf.d/*.conf;
}
ここでは/etc/nginx/nginx.confで設定したupstreamにプロキシする設定を作っている。
proxy_set_header Host $host;はnginxが受けたホストヘッダをそのままApacheに飛ばすことで、Apache側がバーチャルホストでルーティングできるようにしている。Apacheとnginxで別々のホスト名にすることもできるが、そうした場合、Apache側はApache側で定義したホスト名で動作するため、CGIなどのスクリプトを動かすときに支障があるうえ、Apache側のホスト名をhostsに書かないと疎通できないこともあり、手間なので基本的に前段のドメインに合わせておくのが無難だ。
proxy_set_header X-Real-IP $remote_addr;はnginxにアクセスしてきたクライアントのIPをApacheに渡すための設定。そのままだとnginxのIPが渡ってしまう。
proxy_set_header X-Forwarded-Proto $scheme;もホストヘッダの転送と似ていて、nginxが受けたプロトコルスキーマをApacheに飛ばすための設定。こうしておくとApache側はhttpで受けているのに、httpsでアクセスされたものとして認識させることが出来るため、プロトコルスキーマ付きでURLを生成するCGIがいるときに都合がいい。単にスキーマを誤魔化しているだけなので実際は暗号化されていない。
server {
listen [::]:443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
access_log /var/log/nginx/example.access.log;
error_log /var/log/nginx/example.error.log;
location / {
proxy_pass http://apache/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
HTTP通信で利用されるドメインは単にHOSTヘッダーにドメインを書いているだけなので、以下のようなことをするとhostsを書かなくとも疎通できる。
curl -H "HOST: lycolia.info" http://"[2403:3a00:101:13:133:167:8:98]"
これは一般的なHTTPクライアントの仕組みとして、まずドメインをDNSに問い合わせ、IPを取得したのち、ドメインをホストヘッダーに載せてIPアドレス宛にHTTP要求を出しているからだと思われる。
hostsの書き換えができない環境で、任意のドメインに対してHTTP要求を出したい時にも重宝するので、覚えておくと何かと役に立つ。
どういう条件の時にCookieがサブドメインに送信される状態になるかについてのメモ。
レスポンスヘッダにdomainディレクティブがあると送信される。なければされない。
Set-Cookie: hoge=piyo; domain: example.com
EdgeやChromeのDevTools上ではApplicationタブのCookieのDomainが.example.comならサブドメインに送信される状態、example.comならされない状態で区別できる。
以下のようにdomainディレクティブがなければ、そのドメインでしか使えない。
Set-Cookie: hoge=piyo
WSL上のUbuntuで動作するnginxでHTTPSに対応したサーバーを作る方法。実機でも同様の手順でいける
| Env | Ver |
|---|---|
| nginx | nginx/1.18.0 (Ubuntu) |
| mkcert | v1.4.4 |
| Ubuntu | 20.04.6 LTS |
| Windows 11 | 22621.3880 |
mkcert sandbox.testsandbox.test.pemsandbox.test-key.pem/etc/nginx/conf.d/ssl/に移動する/etc/nginx/conf.d/sandbox.test.confを作成し、以下のような記述をする
server {
listen 443 ssl;
client_max_body_size 100m;
server_name sandbox.test;
ssl_certificate conf.d/ssl/sandbox.test+1.pem;
ssl_certificate_key conf.d/ssl/sandbox.test+1-key.pem;
access_log /var/log/nginx/sandbox.access.log;
error_log /var/log/nginx/sandbox.error.log;
# ファイルホスト用
# location / {
# root /usr/share/nginx/html/sandbox;
# index index.html;
# try_files $uri /index.html =404;
# }
# APサーバーへのリバプロ用
location ~ ^/.*$ {
rewrite ^/.*$ / break;
proxy_set_header X-Request-Path $request_uri;
proxy_set_header X-Host $host;
proxy_pass http://127.0.0.1:9999;
}
# fastcgi用
location ~ \.php$ {
root /usr/share/nginx/html/sandbox;
fastcgi_pass unix:/run/php/php8.0-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
sudo service nginx restartmkcertのRoot CAをエクスポートして他の端末に突っ込めば、他の端末でもpemが流用できる
日頃仕事で開発をしていたり、そこら辺のWebサービスの振る舞いを眺めていると不思議というか、奇妙というか、端的に言うとありえないリクエストを投げているものを見かける。
一例としては次のようなものを見たことがある。
これの問題点はまずクライアントのIPを幾らでも捏造できることだ。
クライアントからバックエンドに投げている値など幾らでも偽装できるため、その中にクライアントのIPアドレスを含めるのは何の価値もない。
他にも第三者のサービスを利用しているので、そこが落ちてたり、仕様変更があったりすると使えなくなる。
具体的にはSSRを利用しているNext.jsのサーバーサイドレンダリング側で、クライアントのIPを取得し、後ろにいるAPサーバーにHTTPで投げるときにREMOTE_ADDRヘッダーに入れて送っていたケースだ。curlで表すと次のような形式だ。
curl -H 'REMOTE_ADDR: <ここにIP>' http://example.com
サーバー側はクライアント側のIPをサーバー側が設定するので、このリクエストには意味がない。トラフィックと実装コードの無駄といえる。
サーバー側が何を基にして設定しているかは実装依存だと思うが、恐らく一般的にはトランスポート層より下ではないだろうか？
いわゆるフロントエンドエンジニアや、プログラミングスクール卒などの意識が低いエンジニアらが書いたコードを見ているとこのようなものが散見される印象だが、もう少しちゃんと考えて実装して欲しいと思う。
なんというか、最低限常識とされている部分は理解しておいてほしいなというのはすごく思う。
動機としてはcurlだと見えない部分があるので、自分でHTTPメッセージを手組みして送ってみたかった。
Node.jsとPHPのサーバーでリクエストが期待通り取得できたので、メッセージの実装としては問題ないと思われる。
以下のコードをNode.js v20.11.1を用いて検証
import http from 'node:http';
http
.createServer((req, res) => {
console.log(req.headers);
req.on('data', (chunk) => {
// body
console.log(Buffer.from(chunk).toString());
});
res.statusCode = 200;
res.end();
})
.listen(9999);
echo -e 'GET / HTTP/1.1\r\nHost: localhost:9999\r\n\r\n' | nc localhost 9999
echo -e 'POST / HTTP/1.1\r\nHost: localhost:9999\r\nContent-Length: 4\r\n\r\nhoge' | nc localhost 9999
実際にAPサーバーでリクエストの中身をパース出来るかどうかの観点で見た場合にNode.jsよりPHPのが楽なので、PHPで作ってみた結果、軽くハマったので残しておく。
以下のコードを用いてPHP 8.0.29で検証サーバーを作る場合に、php -S 0.0.0.0:9999としてサーバーを起動すると、Content-Typeヘッダがない場合に正常な動作をしなかった。
<?php
var_dump($_SERVER);
var_dump($_REQUEST);
デバッグ用。生のメッセージが見れるのでダンプしてdiffを取るなどでcurlとecho + ncの差分を見るのに使える。
nc -l 9999
前述のNode.jsサーバーでは400 Bad Request、PHPサーバーでは501 Not Implementedが応答された。