著者:takahashi
[nginx小ネタ]failed (24: Too many open files)が出た時にまず確認したいこと
今回は、先日のちょっとしたやらかし談をご紹介します。
先日新しくサーバーを構築していて、nginxでバックエンドのApacheへのリバースプロキシを構築していたのですが、途中でこんなエラーに遭遇し、サイトが表示されなくなってしまいました。
logを確認するとこんなメッセージが。
accept4() failed (24: Too many open files)
いろいろ調べたところ、OSファイルディスクリプタ数上限の設定やnginxの制限の設定などを変えると解決するという情報を発見て、sysctl.confやらnginxのコンフィグやらを色々変えたのですが、何度試しても同じエラーが出続けて動作せず。
おかしいなーと思いながらもう一度設定ファイルを見返したところ、あることに気づきました。
バックエンドのApacheでは3003番ポートでListenしていて、nginxの3001番ポート経由でバックエンドのサーバーにつなげさせたかったのですが、設定ファイルには
server {
listen 3001;
server_name node.example.com;
client_max_body_size 1g;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
location / {
proxy_pass http://localhost:3001; #←!?
}
}
となっていました。
そう、つまりlocalhostの3003番ポートで動作しているApacheへリバースプロキシさせるはずが、あろうことかnginxが待ち受ける3001番ポート自身をまたリバースプロキシするような設定になってしまっていました。
当然、nginxの待ち受けポートをnginx自身がリバースプロキシしてしまっているので接続が無限にループしてしまい、それが原因でOSの上限を超えてしまっていたというのが今回の原因でした。
すぐに
proxy_pass http://localhost:3003;
に修正したところ、正常にページが表示されるようになりました。
見慣れないエラーが出ると慌ててついいろいろ試してしまいますが、まずは自分の凡ミスを疑ってみることも大事なんだなと思いました(;´∀｀)
著者:takahashi
普通のメールサーバーでもキャリアメールのようなプッシュ通知を可能にするIMAP IDLEとは
携帯電話やスマートフォンでキャリアメールを使用していると、何もしなくてもリアルタイムでメールを受信することができます。
一方、通常のメールサーバーからメールを受信する際、元々リアルタイム受信は一般的ではなく、ユーザーがメールサーバーに定期的に確認しに行くしかありませんでした。
ところがIMAPというメール受信のプロトコルができてから、こういった従来のメールシステムでも定期的にサーバーに確認することなくメールをリアルタイムで受信することが可能になりました。
具体的には、メールソフトがIMAPサーバーへ接続した際、特定のコマンドをクライアントが発行することで受信操作完了後もIMAPサーバーとの接続を維持し続け、新着メールがあるたびにメールサーバーからクライアントにリアルタイムで通知する仕組みになっています。
この仕組み、およびコマンドををIMAP IDLEといいます。
IMAP IDLEコマンドを使用するには、使用しているメールサーバーがIMAPに対応しており、かつIMAP IDLEコマンドにも対応している必要があります。
自分でフルコントロールできるメールサーバーがあれば、受信サーバーにdovecotなどのIMAP IDLE対応IMAPサーバーを使用することで、自分のメールサーバーに到着したメールをリアルタイムにプッシュ通知させることができます。
DovecotでIMAP IDLE を使った Pushメールを体験してみる – レンタルサーバー・自宅サーバー設定・構築のヒント
しかし、使用しているメールサーバーの管理権限を持っていない場合(通常はこの場合が多いと思います。)、IMAP IDLEに対応していないとこのプッシュ通知を利用することができません。
有名どころでは、現時点で下記のメールサービスはIMAP IDLEに対応しているようです。
・Gmail
・Yahoo!メール
そのほかのメールサービスでもIMAP IDLEが利用できるものがあるようです。各メールサービスのFAQやドキュメントを確認したり、サポートに問い合わせたり等して確認してみてください。
また、IMAP IDLEが利用できないサーバーを利用されていて、それでもIMAP IDLEをつかってプッシュ受信を実現したいということであれば、一旦他のメールサービスを受信させて、そこからIMAP IDLEを使ってプッシュさせる方法があります。
例えば、自分の場合は会社のメールサーバーはPOP3にしか対応していないため、直接IMAP接続することができません。
そこで、フリーのメールサービスであるGmailを使い、一度会社のメールサーバーのメールをPOPでGmailへ受信させ、GmailがPOPで受信した時点でIMAP IDLE経由で各端末へ通知させるような使い方をしています。
Gmailサーバーと会社のメールサーバーはPOPでやり取りしているため、実際には完全なリアルタイムではありませんが、Gmailは比較的リアルタイムに近い時間間隔でPOP受信をかけてくれるため、ほぼ数分程度の誤差でメールを受信することができます。
GmailでPOP受信設定する方法 – heteml BLOG
ただし、Gmailの場合は受信容量に上限(Google Dirveなどのサービスと共用で、1無料アカウントにつき15GB)があるので、無限にメールをため続けることができない点には注意してください。
著者:takahashi
nginxやAmazon ALBなどのロードバランサー経由でLaravelにアクセスさせたときにHTTP/HTTPSを振り分ける方法
nginxやロードバランサーなどを使ってWebサーバーにアクセスさせた際に困るのが、一部の情報が本体のWebサーバーまで到達しない点。
特に、クライアントがHTTPでアクセスしているのか、HTTPSでアクセスしているのか、などの情報はそのままの状態で取得するのは困難です。
こういった環境と、HTTPかHTTPSどちらで接続されているのかを判定したうえでDOMのURLを書き換えるタイプの機能を持つフレームワークやプログラムとの相性は特に最悪で、Webサーバーに対してHTTPでアクセスされた時点で”クライアントからHTTPでアクセスされている”と判定して、すべてのアセットのアドレスをhttp://から始まるURLに置き換えて返してしまい、結果jsやcssが読み込めずに表示崩れや不具合になってしまうことがあります。
最近人気のLaravelもこの機構を持っており、そのままの状態でnginxやLBを間に置いてしまうと、httpsでアクセスしたときにページが正常に表示されない問題が発生してしまいます。
幸いにも、HTTPSかどうかの部分についてnginxやロードバランサーが代わりに取得し、その情報をヘッダーに含めて投げてくれる場合が多いので、今回はLaravel上でこのヘッダ情報を使って簡単にHTTP/HTTPSを判定できるようにしてみました。
Laravelプロジェクトフォルダ内の
routes/web.php
の最初あたりに、次のコードを追加します。
<?php
// 2018/10/26追記: 一部修正しました。
/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/
//ここから
//リバースプロキシ経由のHTTP/HTTPS判定
if(array_key_exists('HTTP_X_FOWARDED_PROTO',$_SERVER) === true){ //"HTTP_X_FOWARDED_PROTO"ヘッダーが存在していたら
if(strtoupper($_SERVER["HTTP_X_FOWARDED_PROTO"]) == "HTTP"){ //strtoupper("HTTP_X_FOWARDED_PROTO")の中身が"HTTP"だったら
URL::forceScheme('http'); //すべてのURLをhttpに書き換える
} else {
URL::forceScheme('https'); //すべてのURLをhttpsに書き換える
}
}
//ここまで
$_SERVERはPHPにおいて、サーバー情報および実行時の環境情報がすべて格納されるスーパーグローバル変数です。
この中に、リクエストヘッダの中身もすべて格納されるので、その中からnginxやAmazon ALBやClassic Load BalancerがHTTP/HTTPSの情報を格納する”X_FOWARDED_PROTO”ヘッダーを参照して、どちらでアクセスされたかを判定しています。
ifを敢えてHTTPかどうかで判定している理由は万が一、”$_SERVER[“HTTP_X_FOWARDED_PROTO”]”にhttpでもhttpsでもない不正な値が入っていた場合も、とりあえずhttps://で吐き出すようにするためです。
こんな形で処理を加えてやれば、Laravelでもnginxやロードバランサーを使用していても正常にHTTPとHTTPSの切り替えが行えるようになると思います。
少しでも参考になりましたらしたら幸いです。
著者:takahashi
Certbotでnginxプラグインを使用した際に”UnicodeDecodeError”が出てしまった場合の対処法
CentOS 6.10でCertbotのインストールとSSL証明書の取得をnginxプラグインで行った際に、下記のようなエラーが発生。
2018-10-08 15:34:01,329:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 11, in <module>
load_entry_point('letsencrypt==0.7.0', 'console_scripts', 'letsencrypt')()
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py", line 1364, in main
return config.func(config, plugins)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py", line 1233, in certonly
installer, auth = plug_sel.choose_configurator_plugins(config, plugins, "certonly")
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 228, in choose_configurator_plugins
installer = pick_installer(config, req_inst, plugins, installer_question)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 32, in pick_installer
config, default, plugins, question, (interfaces.IInstaller,))
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/selection.py", line 106, in pick_plugin
verified.prepare()
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 251, in prepare
return [plugin_ep.prepare() for plugin_ep in six.itervalues(self._plugins)]
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 251, in <listcomp>
return [plugin_ep.prepare() for plugin_ep in six.itervalues(self._plugins)]
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/plugins/disco.py", line 132, in prepare
self._initialized.prepare()
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/configurator.py", line 145, in prepare
self.parser = parser.NginxParser(self.conf('server-root'))
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 38, in __init__
self.load()
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 45, in load
self._parse_recursively(self.config_root)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 66, in _parse_recursively
self._parse_recursively(subentry[1])
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 56, in _parse_recursively
trees = self._parse_files(filepath)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/parser.py", line 207, in _parse_files
parsed = nginxparser.load(_file)
File "/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_nginx/nginxparser.py", line 123, in load
return loads(_file.read())
File "/usr/lib64/python3.4/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1345: ordinal not in range(128)
2018-10-08 15:34:01,331:ERROR:certbot.log:An unexpected error occurred:
どうやら、Certbot内のpythonスクリプトで何かエラーが発生しており、そのせいでSSL証明書の取得ができなくなってしまっているようです。
エラー内容をよく見ていくと
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 1345: ordinal not in range(128)
とあり、どうやら文字コードの問題が発生していることは分かりました。
とりあえず調べていくと、こちらの記事を発見。
どうやら、nginxの設定ファイルにコメントなどで日本語が入っていると、Let’sEncryptのnginxプラグインがその日本語部分を解釈できない(asciiコードとして解釈しようとしてしまう)のが原因のようです。
とりあえずの対策として、nginxの全設定ファイルから日本語やその他のマルチバイト文字をすべて取り除けば解決するようです。
自分の環境でもnginxからすべての日本語を取り除いたところ、正常に動作し、SSL証明書取得まで行うことができました。
ただ、Let’sEncryptを使用するから、という理由だけでnginx内のコンフィグで日本語が一切使用できないのはちょっと辛いものがあるので、改良されてほしいですね。
著者:takahashi
Let’s Encrypt + MyDNS でワイルドカードSSL証明書を自動更新する方法
昨日の記事で、無料DDNSサービスであるMyDNSで、手動でDNSの編集をしなくてもワイルドカード証明書を取得・更新できるようになったことをお伝えしました。
今回は実際に自動的にワイルドカード証明書を取得・更新為の設定方法をご紹介したいと思います。
まず前提として、まだMyDNSに登録をしていない方は、先に登録しておく必要があります。
また、MyDNSはDDNSサービスであり、IPアドレスを定期的に書き換えることが前提の仕組みになっています。
そのため、たとえ固定のIPアドレスを取得していたとしても、定期的に向き先のIPアドレスをMyDNSに通知する必要があります。
1週間通知しないと、ドメインIPの正引きが停止し、1か月間通知しないと、アカウントが削除されてしまいますが、IPアドレスの通知はプログラムを使って通知することができるようになっていますので、通知スクリプトをcronなどで定期的に実行することで、手動のメンテナンスなしで利用の継続が可能です。
https://www.mydns.jp/?MENU=030のSTEP4にある要件さえ満たしていればどんな言語やプログラムを使ってもOKなのですが、一から作るのはちょっと面倒なので、インターネット上で有志の方が作成したサンプルコードを利用した方が確実かつ手軽なので、活用することをお勧めします。
アカウントの作成方法とIPの自動更新設定についてはネット上に参考資料が沢山出ているため今回は割愛します。
上記の手順まで完了したら、自動更新スクリプトをサーバーに入れ込んでいきます。
ターミナルを開き、次のコマンドをroot権限で実行します
cd ~ #ホームフォルダなどの作業スペースへ移動 wget 'https://github.com/disco-v8/DirectEdit/archive/master.zip' -O DirectEdit-master.zip #MyDNSの自動更新スクリプトをダウンロード unzip DirectEdit-master.zip #ダウンロードしたZipを解凍 mv DirectEdit-master /opt/ #解凍したフォルダを/opt/に移動
次に、自動DNS書き換えの設定をしていきます。
vi /opt/DirectEdit-master/txtedit.conf
内容を下記のように書き換えます。
$MYDNSJP_URL = 'https://www.mydns.jp/directedit.html'; //そのまま
$MYDNSJP_MASTERID = 'mydnsXXXXXX'; //MyDNSユーザーID
$MYDNSJP_MASTERPWD = 'yourmydnspasswd'; //MyDNSパスワード
$MYDNSJP_DOMAIN = 'example.com'; //MyDNSに登録したドメイン名
権限を変更します。
cd /opt/DirectEdit-master chown root:root ./ chmod 700 ./*.php //DNS自動更新プログラム chmod 600 ./*.conf //設定ファイル
これで下準備はOKです。
それではMyDNS自動更新スクリプトを使ってdns-01認証でワイルドカード証明書を取得してみます。
certbot-auto certonly --manual \ #certbot-autoコマンドは環境によって名前が異なる場合があります。 --preferred-challenges=dns \ --manual-auth-hook /opt/DirectEdit-master/txtregist.php \ --manual-cleanup-hook /opt/DirectEdit-master/txtdelete.php \ -d example.com -d *.example.com \ #※左記以外のサブドメイン(たとえばa.example.com)はMyDNSのスクリプトではエラーになるため指定できません。サブドメインのSSLを取得する場合は別途従来のhttp-01認証で取得してください。 --server https://acme-v02.api.letsencrypt.org/directory \ --agree-tos -m hoge@example.com \ #Let'sEncryptからの通知を受け取るアドレスを指定します。 --manual-public-ip-logging-ok
これでおそらくワイルドカード証明書を取得できたかと思います。
一度上記のコマンドを実行してしまえば、次回以降の更新では
certbot-auto renew #環境によってコマンドが異なります。
コマンドのみを実行すれば更新することができますのでcronなどで定期実行させればサーバーが自動でSSL証明書を更新するようになります。
ワイルドカード証明書を手軽に使ってみたい、という方は是非試してみてください。
著者:takahashi
無料DDNSサービスのMyDNSがLet’s Encryptのワイルドカード証明書取得の自動化をサポート。
個人的にもいろいろなところでお世話になっている無料のDDNS(Dynamic Domain Name Server)、MyDNSがLet’sEncryptのdns-01認証の自動化に対応したようです。
2018.07 Let’s Encrypt用API提供開始
Let’s Encryptで、DNS-01方式でサーバー証明書を取得する場合の、–manual-auth-hookならびに–manual-cleanup-hook用のスクリプトをGitHubに公開しました。
詳しくはREADMEをお読みいただければわかるかと思いますが、これによりワイルドカードのサーバー証明書の取得および更新が非常にしやすくなったかと思います。
どうぞご活用ください。
MyDNSとは、自宅サーバ勢御用達の無料DDNSホスティングサービス。
DNSホスティングとの違いは、定期的にサービスに対してIPアドレスを通知することにより、IP固定契約をしていなくても自分の回線とドメイン名を継続的に紐づけることを可能にしている点です。
管理画面からの変更もできますが、プログラムからも通知できるような仕組みを供えているので、cronなどを利用すれば特に操作しなくてもサーバーからMyDNSに対して継続的にIPアドレスを通知し続けることもできます。
一方Let’s Encyptは一定の条件を満たせば無料でSSL証明書を発行してもらうことができるサービス。
以前にも何度か取り上げていますし、ご存知の方も多いかと思いますが、最近はワイルドカード証明書の取り扱いも開始し、ドメインごとにSSL証明書を取得する必要がなくなりました。
ただし、このワイルドカード証明書をLet’s Encryptで取得するためには、DNSサーバの設定を操作して指定された値を登録することでドメインの所有権を確認する”dns-01″方式で認証する必要があります。
また、DNSサーバーに設定する値はドメインの更新時も変化するため、更新のたびにDNSサーバーの値を書き換える必要があり、Let’s Encryptの証明書期限も3か月しかないため、かなり大変でした。
今回、MyDNSが自動更新に対応したことにより、スクリプト一つで自動的にLet’sEncryptから指示された値を自動的にMyDNS側に登録することができるようになったため、一度成功させてしまえば以降はユーザーの操作が一切なくても継続的にワイルドカード証明書の取得、更新が可能となりました。
次回の記事で、実際の設定方法をご紹介したいと思います。
もし待てない、という方はMyDNSさんのGitHubリポジトリに方法が記載されていますので、そちらをご参照いただければと思います。
著者:takahashi
nginxでnet::ERR_CONTENT_LENGTH_MISMATCHが出た時の対処法
今まで普通に動いていたサイトが、ある日突然正常に表示されなくなるという問題に遭遇。
Chromeの開発者ツールで調べると
net::ERR_CONTENT_LENGTH_MISMATCH
上記のメッセージが大量に発生しており、サイトのアセットの読み込みに失敗していたようでした。
ERR_CONTENT_LENGTH_MISMATCHはヘッダーのContentLengthと実際に受け取ったバイト数が違うと発生するようです。
nginxでのERR_CONTENT_LENGTH_MISMATCHの解決法 – Qiita
いろいろなサイトを見てみると、サーバーにNginxを使っている場合、サイトのキャッシュの保存が失敗したときに先程のエラーが出現するようで、その場合は指定パスに書き込み可能なディレクトリを用意すれば解消するようです。
しかし、今回問題が発生した環境では、該当のログが見当たらなかったため、問題が発生していたサイトのキャッシュを禁止する方法で対策してみました。
変更としてはnginxの設定ファイルを下記のように修正します。
server {
server_name .example.com;
listen 443;
ssl on;
ssl_certificate /path/to/hoge.crt;
ssl_certificate_key /path/to/hoge.key;
client_max_body_size 1g;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Fowarded-Proto \$scheme;
proxy_max_temp_file_size 0; #この記述を追加
location / {
proxy_pass https://localhost:8081;
}
}
これでnet::ERR_CONTENT_LENGTH_MISMATCHエラーが消滅し、とりあえず無事サイトが表示されるようになりました。
しかしなぜ突然こんなエラーが出るようになってしまったのか…原因は分かっていないので、さらに調査が必要そうです。
著者:takahashi
GoogleがGoogle Chrome 69をリリース。テスト中だった新UIがついに正式版に。
GoogleがGoogle Chrome 69をリリースしました。
新バージョンに更新してまず最初に目につくのがツールバー部分のデザインの変更でしょう。
以前
Google Chrome Ver.68でChromeの新しいデザインが利用可能に。
でご紹介したテスト中の新UIが、正式版として実装されたものと思われます。
Chrome68で実装されていたテスト版のUIはこんな感じでした。
正式版ではタブの追加ボタンが再び右端のタブの右側に戻り、直感性が上がりました。
また、今までアプリモードでは右クリックメニュー以外からは一切メニューにアクセスできませんでしたが、
タイトルバーから一部メニューにアクセスできるようになりました。
アプリ上から拡張機能の設定も行えるため、さらに便利になりそうです。
そして今回の最も多きな変更はやはりSSL関連。
SSLが有効となっているサイトの表示が、ついに灰色の鍵マークとなり、Chromeの”SSLは適用されていて当たり前”という考え方がより色濃く感じられるようになりました。
なお、次バージョンのChrome 70 では、ついにhttpサイトへつないだ際に文字入力をすると、赤文字の”保護されていません”表示が行われるように変更されるとのことです。
Google Chrome、HTTPSサイトの「保護された通信」を非表示に 「デフォルトで安全が前提」 – ITMedia エンタープライズ
Chrome 69からHTTPSの表記が変化！Chrome 70以降も要チェック！ – 常時SSL Lab.
まだSSL対応をしていない皆さんはお早めに。
著者:takahashi
テストサーバーの仮想マシンに大量のI/Oエラー… 調べたらホストマシンのディスク不良だった件
今朝会社に来て、テストサーバーのシェルに接続しようとしたところ、接続できない状態に。
今回接続できなくなったのは、Windows上に建てたLinux仮想サーバーでした。ホストOS側のWindowsはリモートデスクトップで何とか接続することができたので状況を確認すると…
ほぼすべての仮想マシンでIOエラーが出ていました…
このマシンは以前からやや不安定な挙動は見せてはいたのですが、ドライバのアップデートやメモリの増設を行った後、暫くは問題なく稼働してはいました。
が、再びIOエラーが出てしまったので流石にハードを疑わざるを得なくなってきました。
案の定、S.M.A.R.T.情報を確認したところ回復不能セクタも出ていた模様。
ホストOS側でも読み込みに失敗する症状も出始めていたので、HDDを交換することになりました。
S.M.A.R.T.情報を監視するアプリを入れて置けばメールでの通知もできたとのことで、テスト環境とはいえ、怪しいと思った時点で監視ツールを入れておけばよかったなとちょっと後悔です。
著者:takahashi
有線LANはあるけど無線LANがない…！ そんな時に役に立つWIndowsで逆テザリング(Hotspot化)する方法
最近はビジネスホテルなどでも無線LANが標準で提供されるところも増えてきました。
しかし一部のホテルや施設などでは未だに有線LANだけの提供だけ、というところがある場合もありますし、どこかの場面で急に無線LANが必要になる場合もあるかもしれません。
特に、スマートフォンなタブレットなどの端末は有線LAN接続が困難な機種が多いので、いざというときに有線LANしか使えない環境だと不安です。
そんな状況下のとき、もし無線・有線LAN搭載のWindows 10 PC一台さえあれば簡単に解決することができます。
通知エリアの無線LANアイコンを押すと、
”モバイルホットスポット”というアイコンがあるのがわかるかるかと思います。
実はこれが今回の目的の機能になります。
モバイルホットスポットって何だろう? – テザリング機能の使い方 – マイナビニュース パソコン
モバイル回線をスマホなどを通じてPCに提供することを”テザリング”と呼ぶのに対し、ホットスポット機能はPCが接続するネットワークをスマホなどのWi-Fi端末へ流す使われ方が多い為、しばしば”逆テザリング”と呼ばれます。（やってることはテザリングとほぼ変わりません。）
実は他のOS(macOS、Linux)でも”逆テザリング”する機能はありますが、Windowsには標準で、他OSにはない仕組みを持っています。
それは1つのWi-Fiアダプタを仮想的に分割し、Wi-FiからWi-Fiへネットワークを中継することができる機能です。
基本的に他OSでは、別のネットワークアダプタのネットワークを”逆テザリング”することしかできません。
つまり、共有する元のネットワークにつながるネットワークアダプタとWi-Fiの電波を端末に発信するネットワークアダプタはハード的に別でないといけません。
一般的にノートPCではWi-Fiアダプタと有線LANポートをひとつづつ備えている構成が多いかと思いますので、この場合は有線LANでつないでいるネットワークをWi-Fiから飛ばす、というような使い方に限られます。
しかしWindowsでは、Wi-Fiアダプタでネットワークにつないだまま、同じWi-Fiアダプタから他の端末に対してWi-Fiのアクセスポイントを提供することができます。
この機能はVirtual Wi-Fiと呼ばれています。
また、Windows 10ではBluetoothを搭載していればBluetoothのPANプロファイルを使って逆テザリングすることもできます。
Bluetoothを除く上記の機能は、正式なGUIが実装されたのはWindows 10からですが、機能自体はWindows 7から利用することができます。
Windows 7をお使いで、GUIでホットスポットのON/OFFを行いたいのであれば、
を使うと実現できます。
いざというときにWi-Fiルーターが必要になった際に役に立ちそうですね。