会社情報
採用情報
お問い合わせ
Article

0円で実現するリモートアクセス環境

高田晃太郎
0円で実現するリモートアクセス環境

商用VPNの相場はユーザーあたり月額5〜12ドルで、50名規模なら年間約30万〜90万円の支出になる計算になる一方、プロトコルやクラウドの進化により、同等の用途を無料プランやオープンソースで満たす選択肢が現実解になりました。公開ベンチマークやベンダーブログでは、WireGuardのユーザースペース実装が1Gbps/コア級のスループットを示す報告があり、Cloudflare Tunnelはグローバルエッジ経由の追加レイテンシが数ms台に収まるケースが公開情報として確認できます¹²³⁴。コストと同時にセキュリティ・可用性の基準も満たせるのかという問いに対し、技術的背景と具体的数値、そして実装の作法を、運用現場を意識した視点で整理します。

0円で実現するアーキテクチャの全体像

無料で構築する方法は大きく三つの性格に分かれます。暗号トンネルを自前で立てるパターン、エッジネットワークを経由して内向きに接続させるパターン、そしてピア・ツー・ピアで直結を試みつつ到達不能時のみ中継するパターンです。前者はWireGuardなどの軽量VPNをVPSやオンプレに導入する設計で、トラフィックの経路と鍵管理をフルコントロールできるのが利点です。二つ目はCloudflare Tunnelのようにアウトバウンドのみで常時確立するトンネルを使い、インターネット側からの受け口をゼロにするゼロトラスト（信頼は常に検証するという考え方）的な扱いを可能にします。三つ目はTailscaleのようなWireGuardベースのオーバーレイで、NAT（アドレス変換）越えの直接通信を狙いながら、難しい場合のみDERP（Tailscaleの中継ノード）に切り替わるのが特徴です⁸。いずれも導入コストは0円で、用途や組織の規模、コンプライアンスの期待値に応じて選び分けるのが現実的です。

パターンA：WireGuardセルフホスト（動的DNS＋Let’s Encrypt）

WireGuardはNoiseIKを用いた1-RTT（1往復）ハンドシェイクを採用し、データパケットのプロトコルオーバーヘッドはIPv4の場合で約60バイト（WireGuard 32B＋UDP 8B＋IP 20B）という小ささが特長です。CPU効率が高く、1Gbps級のNICでもボトルネックになりにくい構造とされています²。運用面では鍵のローテーション、ピア許可、ファイアウォールのドロップデフォルト（明示許可以外は破棄）がポイントになります。

# /etc/wireguard/wg0.conf（サーバ）
[Interface]
Address = 10.66.0.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVATE_KEY>
PostUp = nft add rule inet filter input udp dport 51820 counter accept
PostDown = nft delete rule inet filter input udp dport 51820

[Peer]
# 開発者A
PublicKey = <CLIENT_A_PUBLIC_KEY>
AllowedIPs = 10.66.0.10/32

# /etc/wireguard/wg0.conf（クライアント）
[Interface]
Address = 10.66.0.10/32
PrivateKey = <CLIENT_A_PRIVATE_KEY>
DNS = 1.1.1.1

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.example.duckdns.org:51820
AllowedIPs = 10.66.0.0/24, 10.0.0.0/16
PersistentKeepalive = 25

動的DNSはDuckDNSのような無料サービスを使い、cronでAレコードを更新します。Let’s Encryptで管理UIにmTLS（クライアント証明書で相互認証）を加える場合はCaddyやNginxでACME（自動証明書発行）を使って自動更新すると保守の手間が最小化できます⁹。

# DuckDNSの無料APIでIPを更新（5分毎のcron）
curl -s "https://www.duckdns.org/update?domains=example&token=$DUCKDNS_TOKEN&ip="

パターンB：Cloudflare Tunnel（ゼロトラストの入り口）

cloudflaredはマシンからエッジへ常時アウトバウンド接続を張り、外部からのインバウンドを不要にします。追加レイテンシはローカルエッジまでの距離に依存しますが、都市圏では数ms台〜10ms前後に収まるケースが一般的と報告されています。Cloudflareは世界100カ国以上にエッジを展開しており、近傍エッジ終端によりこの遅延を小さく保ちやすいことが公開レポートからも示唆されます³⁴⁵。Cloudflare Accessを重ねるとIdP（アイデンティティプロバイダ）のSSOとデバイスポスチャ（端末の健全性条件）を組み合わせられ、公開サブネットを持たない内製ツールの保護に適します⁶⁷。

# トンネル作成とサービス公開の例
cloudflared tunnel create dev-admin
cloudflared tunnel route dns dev-admin admin.example.com
cloudflared access tcp-route --hostname ssh.example.com --port 22 --tunnel dev-admin

# ~/.cloudflared/config.yml
Tunnel: dev-admin
Credentials-file: /home/ubuntu/.cloudflared/<tunnel-id>.json
ingress:
  - hostname: admin.example.com
    service: http://localhost:3000
  - hostname: ssh.example.com
    service: ssh://localhost:22
  - service: http_status:404

systemd（Linuxのサービス管理）での常駐は次の通りです。

# /etc/systemd/system/cloudflared.service
[Unit]
Description=cloudflared tunnel
After=network-online.target

[Service]
ExecStart=/usr/bin/cloudflared tunnel run dev-admin
Restart=always
User=cloudflared

[Install]
WantedBy=multi-user.target

パターンC：Tailscale/Headscale（P2Pでの到達性を最大化）

TailscaleはWireGuardを基盤にNATトラバーサル（STUN等での経路確立）を試み、直結できない場合のみDERP中継に自動で切り替わります。直結時はローカルと同等に近いスループットを狙える一方、DERP経由時は回線品質と中継混雑の影響を受けやすく、上限が下がる傾向があります⁸。組織で無料を維持したい場合はオープンソースのHeadscaleをセルフホストすることで、コントロールプレーン（登録・鍵配布）を自前運用できます。

{
  "ACLs": [
    { "Action": "accept", "Users": ["group:dev"], "Ports": ["10.66.0.0/24:22,3000-3010"] }
  ],
  "Groups": { "group:dev": ["alice@example.com", "bob@example.com"] }
}

# headscaleの最小起動例（PostgreSQLと組み合わせ）
headscale serve --listen 0.0.0.0:8080 --tls_letsencrypt_listen :443 \
  --db-type postgres --db-host 127.0.0.1 --db-name headscale \
  --db-user headscale --db-pass $DB_PASS

性能とセキュリティの具体的数値

プロトコルオーバーヘッドは計画段階で意識しておくとボトルネック推定に役立ちます。WireGuardはデータプレーンで32バイトの独自ヘッダーを持ち、IPv6ではIPヘッダーが40バイトになるため合計80バイト前後のオーバーヘッドとなります。CPU効率が高い実装では1Gbpsクラスでも高い実効転送が報告されており²、Cloudflare TunnelはTCP/QUICの多重化とエッジ広域網を活かし、アプリケーションごとの接続確立が短縮されることが多く、地理的に近いエッジで追加5〜10ms前後の例が見られます³。P2P型のオーバーレイは直結時に物理経路の最短性を活かせる反面、企業ネットワークでUPnPが無効の時はSTUN失敗によりDERPに頼る比率が高まり、上り回線が弱い拠点では100〜300Mbps帯に収束しやすいという報告が一般的です⁸。

待ち時間、ハンドシェイク、鍵管理

WireGuardのハンドシェイクは1-RTTで、再接続時の再鍵交換も迅速です。セッション鍵は短命で自動ローテーションされる設計であり、エンドポイント変更やNAT越えの安定性に備えてPersistentKeepaliveを20〜30秒に設定するのが実践的です。SSHでは短命鍵＋FIDO2のハードウェアトークンにより秘密鍵のローミングを抑制できます。Cloudflare AccessのようなIdP連携は認証をSAML/OIDC（標準的なシングルサインオン）に寄せ、IPアドレスに依存しない制御を可能にします⁶。

ファイアウォールと平常時の観測

入口の最小化は0円構成においても守るべき原則です。WireGuardはUDP 51820のみ、SSHはクラウド側のセキュリティグループでソースIPを自社の出口アドレスに限定し、常時露出を避けるのが良い設計です。nftables（Linuxのパケットフィルタ）でのドロップデフォルトは次の通りです。

# nftables（IPv4/IPv6混在の基本ポリシー）
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0; policy drop; }
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input iif lo accept
nft add rule inet filter input udp dport 51820 counter accept  # WireGuard
nft add rule inet filter input ip protocol icmp accept
nft add rule inet filter input ip6 nexthdr ipv6-icmp accept

実装と運用の現実解（コード付き）

導入は短時間で進められます。VPS一台にWireGuardを入れる場合、OS更新と時刻同期を整え、鍵を生成し、クライアントのピア設定を書き込み、疎通試験を行います。疎通はサーバからクライアントのトンネルIPへpingし、次にアプリケーション層での接続試験としてSSHやHTTPを流します。永続化はsystemdに任せ、再起動やカーネル更新後も自動復旧する構造を必須にします。

# WireGuardの鍵生成と有効化
umask 077; wg genkey | tee server.key | wg pubkey > server.pub
umask 077; wg genkey | tee client.key | wg pubkey > client.pub
systemctl enable --now wg-quick@wg0

SSHを踏み台なしで安全に扱いたい場合は、Cloudflare TunnelでTCPをプロキシし、クライアント側はアクセストークンを使って接続します。これによりサーバの22番ポートは外向きに公開されません。

# cloudflared経由のSSHクライアント接続例
cloudflared access ssh --hostname ssh.example.com --id <app-aud-tag>
ssh -o ProxyCommand='cloudflared access ssh --hostname %h' ubuntu@ssh.example.com

HTTP系の社内ツールはmTLSを付与すると権限昇格の危険を局所化できます。Caddyの自動証明書発行を使うと、無料のLet’s Encryptでゼロ運用に近づきます⁹。

# Caddyfile（mTLSで内製ツールを保護）
admin.example.com {
  tls {
    client_auth {
      mode require_and_verify
      trusted_ca_cert_file /etc/caddy/ca.pem
    }
  }
  reverse_proxy localhost:3000
}

監査の観点では、最低限の接続ログと設定差分をGitで管理するだけでも可視性が向上します。wg showの出力を定期的に保存し、ピアのエンドポイント変更やハンドシェイク時刻のずれを検知します。

# 簡易ヘルスチェック（直近ハンドシェイクの経過秒）
wg show wg0 latest-handshakes | awk '{print $1, systime()-$2}'

障害時の切り分けは、名前解決、UDP疎通、鍵の整合、ルーティングの順に進めます。名前解決では動的DNSの記録が最新かを確認し、UDPはtracerouteやmtrでエッジまでの経路品質を観測します。鍵の整合は公開鍵の貼り間違いが定番の事故として多く、AllowedIPsの重複があるとカーネルルーティングで想定外の経路が選ばれる点にも注意が必要です。

コストとROI、そして有料化の判断基準

0円構成の最大の価値は、意思決定のスピードにあります。チーム10名規模までの開発環境や、小規模の運用者向けバックプレーンであれば、無料のWireGuardやCloudflare Tunnel、Tailscale/Headscaleのいずれかで、目安として30〜90分程度で安全な入口を用意できる場合があります。マネージドのSLAや24/7サポート、コンプライアンス監査証跡、デバイスポスチャの厳格化、きめ細かなRBAC（ロールベースのアクセス制御）が必要になった段階で有料プランへ移行すれば、支出は実利用に追随します。判断のしきい値としては、月間アクティブユーザーが50名を超える、複数拠点の帯域合計が1Gbpsを超える、外部委託を含むIDプロバイダ統合が必須になる、のいずれかが見えてきた時点が一つの目安です。監視・運用面の内部工数も見逃せません。鍵ローテーションや端末入れ替えの儀式化に毎月4〜8時間以上を要するようになれば、商用製品のポリシー自動化による時間短縮が投資に見合いやすくなります。

まとめ：小さく始めて、確信を持って拡張する

無料の技術だけで、堅牢で実用的なリモートアクセスを構築することは十分に可能です。WireGuardの軽さ、Cloudflare Tunnelの入口削減、Tailscale/Headscaleの到達性という特性が補完関係にあり、チームの規模や要件に合わせて組み合わせる柔軟性があります。最初は単一用途から小さく着手し、ハンドシェイクの時刻やレイテンシの具体的数値を日々の観測で握り、運用の確信を積み上げてください。やがて要件が増した時、有料プランや商用製品に切り替える判断も、測定値に裏打ちされた穏当な投資としてチームに受け入れられるはずです。今日、ゼロコストで最初のトンネルを立ち上げ、来週のデプロイと障害訓練に間に合わせてみませんか。

参考文献

  1. Entrepreneur. Making Small Business VPN Security a Breeze for as Low as $5 a Month. https://www.entrepreneur.com/science-technology/making-small-business-vpn-security-a-breeze-for-as-low-as/436382
  2. WireGuard mailing list. Performance notes and Wintun improvements (2021-08). https://lists.zx2c4.com/pipermail/wireguard/2021-August/006887.html
  3. Cloudflare Blog. ネットワークパフォーマンスの最新情報（Developer Week）. https://blog.cloudflare.com/cloudflare-network-performance-update-developer-week-jp/
  4. Cloudflare Blog. Cloudflare network expands to more than 100 countries. https://blog.cloudflare.com/cloudflare-network-expands-to-more-than-100-countries/
  5. INTERNET Watch. Cloudflare「WARP」速度検証記事. https://internet.watch.impress.co.jp/docs/column/hot/20191021_1451790.html
  6. Cloudflare Developers. Generic SAML IdP integration. https://developers.cloudflare.com/cloudflare-one/identity/idp-integration/generic-saml/
  7. Cloudflare Developers. Device posture integrations. https://developers.cloudflare.com/cloudflare-one/identity/devices/access-integrations/
  8. Tailscale Blog. Throughput improvements and DERP behavior. https://tailscale.com/blog/throughput-improvements
  9. Caddy Documentation. Automatic HTTPS. https://caddyserver.com/docs/automatic-https