さくらVPSでWEBアクセスできないなど。

状況

さくらVPSでUbuntu。

「ufw」という簡単でわかりやすいツールがあるんだと。
iptables のラッパーらしいが。


# ufw allow 80

のような操作で、簡単に穴あけできる。

だが、しかし、塞がったままででした。

なにやっても #80アクセスできません。

nc コマンド 使い方メモ - Qiita

公式アナウンス

※ さくらのVPSデフォルト設定であるiptables以外のファイアウォールをご利用になりたい場合は、再起動時に設定が2重に反映されてしまう可能性がありますため、/etc/network/if-pre-up.d/iptables の削除が必要となります。あわせて、iptablesのルール情報である /etc/iptables/iptables.rules も不要となりますため削除いただくこと推奨いたします。

さくらのVPS、スタートアップスクリプト「Ubuntu ufw」を更新しました – さくらのVPSニュース

初期設定では ssh/icmpのみ許可しています。
/etc/network/if-pre-up.d/iptables より、下記設定ファイルを読み込んでおります。

OSセットアップ情報(Ubuntu16.04 LTS) – さくらのサポート情報

まとめ

さくらのVPS(クラウドも含む可能性があります)のUbuntu 16.04 LTS環境では、2017-12-07現在、netfilter-persistentパッケージをインストールした状態でも設定が上書きされてiptablesのフィルタリング設定が元に戻ってしまう可能性があるようです。

netfilter-persistent が動かないよ @ さくら - Qiita

結局、利用は以下の2つのパターン。


// ufw を使う。 iptables の設定で上書きさせない。
# rm /etc/network/if-pre-upid/iptables
# rm /etc/iptables/iptables.rules
# reboot

# ufw enable
# ufw allow 80
# systemctl enable ufw


// iptables を使う。ufw を無効化。
# iptables -I INPUT 5 -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
# iptables-save > /etc/iptables/iptables.rules
# ufw disable
# systemctl disable ufw
# reboot

ufw では届かない設定があるので、ルールの変更は「ufw」と「iptables」コマンドを併用しないほうがよいのだろう。

はまる。


いまさらAndroid端末にすばやくWiFiで接続する

なんとなく面倒なのでスクリプトで。

USBで接続のあと #5555 で待たせて再起動する。

「restart」なので、kill-server → start-server は不要。


adb tcpip 5555

IPアドレスをコマンドラインから取得。


ip="$(adb shell ip route | awk '{print $9}')"

そのIPにWiFi接続。


adb connect $ip



 

まとめ

ついでに、開発時には邪魔なスリープもOFFに。


adb shell svc power stayon true

How to prevent an android device from entering sleep (via adb command shell) - Stack Overflow

connect_via_wifi.sh


#!/bin/sh

adb tcpip 5555

sleep 1

ip="$(adb shell ip route | awk '{print $9}')"

adb connect $ip

adb shell svc power stayon true

adb devices -l

端末内 adbd の TCPモード(#5555)が起動している限り再接続が可能。

なので、USB接続なしの状態でも

IPの目処つけて 「adb connect」 でどうぞ。


~ $ adb devices
List of devices attached

~ $ get-oui -v
Renaming ieee-oui.txt to ieee-oui.txt.bak
Fetching OUI data from http://standards-oui.ieee.org/oui/oui.txt
Fetched 4084734 bytes
Opening output file ieee-oui.txt
25968 OUI entries written to file ieee-oui.txt

~ $ sudo arp-scan -l
Interface: en0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.0.1	8a:af:ec:9c:91:08	BUFFALO.INC
192.168.0.2	dc:23:76:3d:9b:75	HTC Corporation
192.168.0.3	d0:27:82:f5:e8:2a	AzureWave Technology Inc.
192.168.0.8	8c:85:00:14:89:d1	Murata Manufacturing Co., Ltd.
192.168.0.4	a2:37:e3:12:9a:88	HTC Corporation
192.168.0.6	33:28:6d:29:7b:72	Google, Inc.

~ $ adb connect 192.168.0.4
connected to 192.168.0.4:5555

~ $ adb devices
List of devices attached
192.168.0.4:5555	device

初回の、USBケーブルなしでTCPモードを起動できないのはセキュリティ絡みでか。

ADBオーバーネットワークでWiFiで複数端末を一括接続する

Android Devices Being Shipped with TCP Port 5555 Enabled - DEV Community 👩‍💻👨‍💻


自宅でネットがつながらない時の連絡先と話し方

ネットが繋がらなくなっとき。

「サポートに電話しよう。」などと考えます。

面倒くさい謎の説明を受けた挙げ句、たらい回しにされることが多いですよね。

電話するにも、電話番号がたくさんあったり、

プロバイダなのかメーカーなのか、とか。

実際、たらい回されて、しつこく電話して解決した私が少し思うことを書いてみたいと思います。

 

問題位置の把握

パソコンやスマートフォンに到達する前のどこで問題が起きてるか。

切り分けが大事になります。

モデムとルーターのランプから判別しましょう。

POWER(電源)
LINK(物理的接続)
ACT(通信状況)
ALARM(機器異常警告)

順番に確認していきます、

「POWER」はすべてONであるか。

「LINK」はすべてONか。

たぶん、ここは、フツーの家電感覚で確認できます。

電源スイッチか配線を疑いましょう。

「ACT」ランプは、通信の状況に合わせて、

不定期に点滅

するのが正常です。

正常な場合。



光モデムの場合、問題が、VDSL側(壁側)かLAN側か、をランプで明快に確認できます。

今回、私の場合、「VDSL LINK/ACT」のランプが、「定期的な点滅」だったので、上流であるそこを疑いました。

連絡先は、「NTT東日本」です。

サポートセンターの方に、ランプの確認のあと、

「ケーブル端子の抜き差し」

をするように言われたあと、1分ほど待っていたら正常な元気なランプの点滅が始まり、ネット利用ができるようになりました。

 

まとめ

今回学んだ問い合わせのコツとしては、

「上流から問い合わせていく」

ということです。

もし、プロバイダやルーターメーカーから電話していたら、もっと復旧に時間がかかったと思います。

その時は会話の中心を

「ランプの状態」

にするとスムーズに話が進みます。