こっそりと。

すべて参考サイトの通りです｡
SMBパケットをキャプチャしてみた

古いNASを回収してきて､それのテストをしたいと言われました｡
そして設定は終わっているが､Windows端末からアクセスできない｡そのように相談を受けたのです｡

設定が問題なくできているのに､ファイル共有にアクセスできない場合､最近はSMB1.0の通信を疑います｡
少し前から､Windowsでは SMB1.0 ではデフォルトで無効化されています｡

ping 等では応答があるので､設定的な問題だとは思えませんでした｡
Wiresharkでキャプチャーしてみたところ､以下の通りでした｡※参考サイトと一緒です｡

Negotiate Protocol Response を確認すると､
NT LM 0.12 となっていました｡

以下のファイル共有プロトコル、SMBとCIFSの違いを正しく理解できていますか?(後編)を見てみると､ SMB 1.0 の場合にこのような表示になるようです｡

結局動作としては問題無いが､SMB1.0ということなので､PC側に追加の設定を行わなければアクセスすることができませんでした｡
※追加の設定といっても､SMB1.0でのアクセスを許可する内容です｡

テスト用にドメインを所有しています｡
時々しか利用しないのですが､ログなどのちょっとしたメールが1日1通ぐらいあります｡

そのメールを gmail などに転送することがあるのですが､よく gmail 側で拒否されています｡
少しでも努力して､スパム扱いされるのは防ぎたいと思います｡

あまり意味が無いかもしれませんが､postfix を経由して gmail に送信されるとき､SSL暗号化されるように設定を行いました｡

以下の2行を追加しました｡
smtp_tls_security_level=may
smtp_tls_loglevel=1 # ログ設定です｡

※なお以下の設定値はかなり似ていますが､意味が異なります｡
smtpd_tls_security_level=may

smtp[d] の有無の部分が異なっています｡サーバーとして動作する場合とクライアントとして動作する場合に使い分けられているようです｡
今回はgmailに送信する場合なので､クライアント側の動作となります｡

サーバー側としても､すでに may で設定がされており､暗号化された状態で送信はできていました｡

送信テストを行ったところ以下のログがでていました｡
Untrusted TLS connection established to gmail-smtp-in.l.google.com[2404:6800:4008:c06::1b]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256

TLS1.3で暗号化されているようです｡

構築したときの動作確認では問題なくメールの送受信ができていたように記憶しています｡
しかしあるときから gmail へのメール送信ができなくなってしまいました｡

以下のメールが出ていました｡

gmail-smtp-in.l.google.com[2404:6800:4008:c03::1b] said: 550-5.7.26 This
mail is unauthenticated, which poses a security risk to the 550-5.7.26
sender and Gmail users, and has been blocked. The sender must 550-5.7.26
authenticate with at least one of SPF or DKIM. For this message, 550-5.7.26
DKIM checks did not pass and SPF check for [XXX] did not
550-5.7.26 pass with ip: [Z::Z]. The sender
should 550-5.7.26 visit 550-5.7.26

これは spf レコードに関する指摘でした｡
確かに ipv6 アドレスについては､ spf レコードを設定していませんでした｡これを設定することで解決しました｡

続いて以下のエラーがでました｡

550-5.7.1 [133.18.236.180] The IP you're using to send mail is not
authorized to 550-5.7.1 send email directly to our servers. Please use the
SMTP relay at your 550-5.7.1 service provider instead. Learn more at 550
5.7.1

SMTP ブラックリストなどを調べてみると､Spamhaus の PBL に該当していることがわかりました｡
あらためて以下のURLで調べます｡
https://check.spamhaus.org/

PBL というのは､プロバイダ等IPアドレス業者側で設定しているもののようです｡要するに我々の管理するIPアドレス群からはメール送信を基本的には許可していません｡
というものです｡
ただし､PBLに登録されているIPアドレスであっても､手動で削除することができるようです｡

一旦削除申請を挙げてみて様子を見たいと思います｡

参考
WAVE Log : VPS Construction : KAGOYA CLOUD VPS

私が管理している企業のドメインですが､サブドメインを利用するときはグローバルIPをもらい､その通りに設定することがほとんどでした｡
いくつものドメインを管理していましたが､だいたいはそれで事足りていました｡

今回は､ 特定のサブドメインについて､設定するべきIPアドレスが通知されるのではなく､DNSサーバーが通知されました｡
本当にこれで間違いないですが?

そのように担当者に聞くと､｢私も今までのと違いIPじゃないので違和感があるのですが､これを制作会社から依頼されました｣と｡

たしかにあまりよくある方法では無いように思いますが､サブドメイン毎委任させることを希望しているのだと思われます｡
例えば管理しているドメインが example.com だとします｡

そして依頼があったサブドメインが sub1.example.com という感じです｡
通常は上記URLのIPをもらえれば､それで事足りるのですが､今回は委任でした｡
となると､結果的には sub-a.sub1.example.com というようなさらに下層のサブドメインを利用することが可能です｡一方で､ sub2.example.com というドメインを利用する場合には引き続き私の方で設定が必要です｡これに意味があるのかどうか･･｡
たぶんホスティング側のサーバーでは､IPアドレスが絶対に変わらないことが保証されていないということから､このようにしたのだと思います｡
ただその場合も cname を利用するのが一般的な感じも･･｡

Windows DNS サーバーを利用していたので､該当するドメインを右クリック､新しい委任を選択し設定を進めることで無事に完了しました｡その後の動作確認も問題ありませんでした｡

すでに同じ内容で記事が書かれていました｡
YAMAHAルーター 外部からSSHへの接続に失敗する

ようするに不正アタックが非常に多い環境では､SSH接続ができなくなるというものです｡
これは設定に起因するものでは無く､昨日まではSSHできていたのに､今日になるとできないといったトラブルになります｡

問題なのは､Teraterm等では､いきなり disconnect となってしまい､原因が不明なことです｡
上記で挙げた記事でも､通信エラーとなっています｡

Wiresherkで確認してみると､パケットの一つに､ To many users login という文字列が確認できました｡
ポイントとしては､ちゃんと相互に通信が行われており応答もあると言うことです｡
応答があるということは､FWなどの問題は無く､昨今話題になりがちな､アルゴリズムか､今回のようなセッションオーバーだと考えられました｡


再起動できる環境ではないので､しばらく放置して様子を見たいと思います｡
※なお30分ぐらいでは解決しませんでした｡･･･再起動じゃないとだめなのかな??

サーバーのセットアップをするとき､セッションが不意に切れても大丈夫なように screen コマンドを利用します｡
大変便利なのですが､挙動がちょっと異なります｡

マウスホイールをくるくるすると､履歴が出てしまいます｡Teratermなどのページが動いて欲しいのですが･･｡(この件はまだスマートに解決できていません｡)

同様に文字が入力されていない状態で､バックスペースキーを押したり､コマンドを補完させるために tab キーを押すと､画面がちらつくようになりました｡
そしてこれは screen コマンドの機能のようです｡

簡単なのは Ctrl+a Ctrl+g を押すことです｡
または /etc/screenrc の vbell を off にすることです｡