草地です。
何とか解決できた様でよかったですね。
原因はおそらく青木さんが解説なさっている様に VPSに SSHで接続されて
いた為に ipfw を初期化した際に一旦ルールがクリアされてしまって SSH
のセッションが通信不能に陥ってしまったのだと思います、VNCコンソール
は仮想PCからは物理コンソールと同じ扱いになるのでVPS上でのネットワー
クの影響を受ける事は無いです。
私もさくら、Conohaで VPSを運用していますが、同じ問題があるのでファ
イアーウォール関係をいじる時は仮想コンソールから作業する様にしています。
とりあえず、問題解決のお手伝いが出来てよかったです。
On 2022.10.08 16:05, Yoshito Takeuchi wrote:
何度も申し訳ありません。竹内です。
理由は分からないのですが、open で動く様になりました。
私は今までずっと ssh から ipfw onestart などのコマンドを打ち
直後固まってしまい、reboot するを繰り返していました。
それを VNC コンソールからログインして ipfw onestart しました。
rc.conf には firewall_type="open" だけ書いてあります。
すると flush all なんとかなんとか 65000 allow any to any みたいな
お馴染みのメッセージが出てきました。なんだ、動くじゃないか。
ssh で接続出来ました。そして、それ以降は ssh からでも
ipfw onestart しても同じ様に動く様になりました。
これは最初、さくらVPS でやったので、続いて conoha VPS でも
コンソールから 1度 ipfw onestart したら、以後は ssh からでも
ipfw コマンドが動く様になりました。コンソールから一度動かすと
何が変わるのか分かりませんが、以上が現在できるご報告です。
お騒がせしたことを再度お詫び申し上げます。
失礼します。
p.s. 言い訳なんですが、、、、今手元に ipad(外付けキーボード無し)
だけなもので、VNC コンソールでの文字入力が物凄くやりにくいので
コンソールでの実験が後回しになっておりました。
2022年10月8日(土) 14:35 Tomoaki AOKI <junch...@dec.sakura.ne.jp>:
青木@名古屋です。
VPSで提供されているゲストOSイメージだと、業者が何らかの
手を加えている可能性も否定できませんねぇ。
firewall_type="OPEN"だと、詳細は/etc/rc.firewallを
読んで頂くとして、
・ループバックの設定
・IPv6で必ず通さなければならないものの設定
・NATを使う設定の場合、その反映。
・65000番に pass all from any to anyを設定
するだけですので、追加で65000番より若い番号で
何か遮断する設定をしない限り、何でも通ってしまう
筈です。
草地さんご指摘のipfw listで何らかのルールが追加
されていたりしませんか？
NATを使わずIPv6ありの設定の場合、openなら草地さんの
最初の返信のipfw listの例のとおりになっている筈ですが、
業者OSイメージ独自の追加設定で65000番より前に
deny ip from any to anyが入っていたりしませんか？
※業者独自に/etc/rc.firewallに手を入れていたり。
また、NATを使う構成の場合、NATの設定側で特定ポート
へのアクセスはそのまま変換せず通すようになって
いなければ内側からのリクエストへの返信以外の
アクセスは一切通せません（ipfwではどうしようもない）
が、ipfwを起動していない状態でアクセスできているのなら
除外して大丈夫と思います。
それ以前に、正直、firewall_type="open"でipfwを使用する
意義が全く見いだせないのですが...。
※特定の通したくない通信以外全部通したい場合の下敷きに
するなら別として。 65000番より前にdenyの設定を
必要なだけ追加する形ですね。
なお、ipfwでは若い番号のルールから順に評価し、最初に
マッチした処理を行ったら後はまるごと無視します。
On Sat, 8 Oct 2022 09:16:46 +0900
Yoshito Takeuchi <kinc...@kinchan.com> wrote:
皆様、ご指導ありがとうございます。
私の環境は conoha vps です。
今、まっさらの FreeBSD 13.0 (conoha のプレインストールが古い) を作成して
最初にログインした段階で ./etc/rc.conf に
firewall_enable="yes"
firewall_type="open"
を追加
/etc/rc.d/ipfw start
すると open にならず、全ポートが deny any to any になっていました。
ipfw 自体は動いている様です。
正直なところ、？？？状態です。
ご報告まで
失礼します。
2022年10月8日(土) 8:52 Kaoru Kusachi <t...@st.rim.or.jp>:
草地です。
手元の同等の環境でも起動時に ipfw のカーネルモジュールが読み込ま
れた時点で同じメッセージがコンソールに表示と /var/log/messagesに
記録されていますので ipfw のモジュールは読み込まれて起動している
と思います、/etc/rc.firewall が正常に実行されると設定されている
有効なルールが表示されるのですが表示されませんか？
試しに /etc/rc.conf の firewall_enable= を "NO" にして起動時に
実行されない様にしておいて、手動で /etc/rc.d/ipfw を手動で実行
してみると以下の様に表示されます、因みに start を指定すると、
rc.confで "NO" を指定しているので onestart せよと警告が表示され
ます。
# /etc/rc.d/ipfw onestart
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny,
logging disabled
Flushed all rules.
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 deny ip from any to ::1
00500 deny ip from ::1 to any
00600 allow ipv6-icmp from :: to ff02::/16
00700 allow ipv6-icmp from fe80::/10 to fe80::/10
00800 allow ipv6-icmp from fe80::/10 to ff02::/16
00900 allow ipv6-icmp from any to any icmp6types 1
01000 allow ipv6-icmp from any to any icmp6types 2,135,136
65000 allow ip from any to any
Firewall rules loaded.
設定ルールの読み込みが表示されない様であれば rc.firewall の
スクリプトが実行されていない可能性が考えられますので、
その辺りを調べてみてはいかがでしょうか？
とりあえず参考まで。
On 2022.10.07 18:38, Yoshito Takeuchi wrote:
お騒がせしております。
ipfw start したタイミングで /var/log/message に
kernel: ipfw2 (+ipv6) initialized, divert loadable, nat loadable,
default to deny, logging disabled
と出ていました。これって、
firewall_type="open"
を認識していないって事なんでしょうか？
--
青木 知明 [Tomoaki AOKI] <junch...@dec.sakura.ne.jp>
--
草地 薫 (Kaoru Kusachi) t...@st.rim.or.jp
Nakno,Tokyo,Japan.
