「Com/Tech」カテゴリーアーカイブ

VFesマッチングが早くなる PS4のMTU調整 バーチャファイターeスポーツ

投稿日時: 投稿者:
返信

バーチャファイターeSports、ランクマッチが全然マッチングしない！ということでPS4のMTUを調整してみたらどんどんマッチングするようになりました。
しっかりとマッチングできてる人はいじる必要ありません。あまりに繋がらないためにネットワークを疑った場合の話です。

MTU調査はこちらで https://www.speedguide.net/analyzer.php

MTUを1280にしろと

このMTUの値をPS4の
設定＞ネットワーク＞インターネット接続を設定する＞（うちの場合）LANケーブルを使う＞カスタム
で進めていった先の、MTU設定を「手動」にして、入力してやります。
うちはフレッツ光ネクストのIPoE+transix(DS-Lite)固定IPという環境もあって、1280でした。

すると、設定前には1分2分かかって当たり前だったマッチングが、10秒未満に。
調子がいいと何度も6秒でマッチングするように。

そもそもフレッツ光(東日本)でPPPoEだとMTUは1454だった覚えがあったのですが、DS-Liteだと1460になるようで。うちはtransixの固定IPv4アドレスなので、その影響で1280になっているようです。
当然、環境毎に異なるので確認サイトで見てみてください。

追記

環境がIPoE+transix(DS-Lite)固定IPv4という状況かつ、ルーターRTX810でデフォルトのtunnel MTUが適用されており、1280になっていました。
MTU値を詰めていくと…1460で通る。ルーターで明示的にIPv4用のIPIPトンネルのMTUを1460に設定してやったところ、当然PS4側も1460で通信できるようになりました。
ルーターがMTU 1460の状態だと、PS4側はMTU自動設定でも大丈夫みたいです。

PCをスリープにしたのにすぐ復帰してしまう件、WOLが原因か

投稿日時: 投稿者:
返信

自作PCを組んで常に電源入れっぱなし的に使っていますが、やはり暑い夏には単なる熱源である時間も多いので、使わないときにはスリープもしくは休止状態にしてやりたいと思い、そのように運用を開始したところ、休止状態でもなぜかすぐ復帰してしまう。

マウスとかキーボードが動いちゃうのかなーなんて思いましたが、デバイスの電源を切ってもすぐ復帰する。こりゃ別の原因だと思ってあれこれしてるうちに見つけたのがNIC。LAN。

Magic Packetでのみ、コンピューターのスタンバイ状態を解除できるようにする

Wake On Lan(WOL)なんて設定してないのになーと思ってNICのプロパティを見たら「このデバイスで、コンピューターのスタンバイ状態を解除できるようにする」にチェックが入ってました。そして「Magic Packetでのみ、コンピューターのスタンバイ状態を解除できるようにする」にはチェックなし。
WOLするにはマジックパケットが必須だと思っていたのですが、調べたらそうじゃないpingなんかでも起きてしまうんだそう。Magic Packet限定にしないとすぐ起きてしまう。

ということで「Magic Packetでのみ、コンピューターのスタンバイ状態を解除できるようにする」にチェックを入れたら、スッキリとスリープ・休止状態になってくれました。
Magic Packet以外でも起きる設定がデフォルトってどういうことだい…たまたまデバイスとドライバの組み合わせがそうなっていただけかもしれませんけども。

特定サーバーからメールが届かなくなった（TLSv1.1廃止の影響）

投稿日時: 投稿者:
返信

CentOS7,8あたりでpostfixによるメールサーバーを運用中。
最近いくつかのサーバーからメールが届かなくなったということで調査したら、TLSv1.1以前が廃止された影響だったようです。

受信サーバーのpostfixは smtpd_tls_security_level = mayとしているので、STARTTLSしなければ平文のSMTPでメールが受信できます。

問題は送信元がSTARTTLSしてしまうけれどもTLSv1.1以下だった場合。バージョンアップされていないメールサーバー（今回は某レンタルサーバーのqmail）がSSL3で通信しようとしてきて、STARTTLS→失敗・切断という流れだったようです。

相手からreturn mailが来たと連絡をもらったときの内容は以下↓

TLS connect failed: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version; connected to XXX.XXX.XXX.XXX.
I'm not going to try again; this message has been in the queue too long.

受信側postfixをsmtpd_tls_log_level = 2 にして様子見したときのログ↓

connect from mxXXX.example.com[XXX.XXX.XXX.XXX]
setting up TLS connection from mxXXX.example.com[XXX.X.XXX.XXX]
mxXXX.example.com[XXX.XXX.XXX.XXX]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
SSL3 alert write:fatal:protocol version
SSL_accept:error in error
SSL_accept error from mxXXX.example.com[XXX.XXX.XXX.XXX]: -1
warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1661:
lost connection after STARTTLS from mxXXX.example.com[XXX.XXX.XXX.XXX]
disconnect from mxXXX.example.com[XXX.XXX.XXX.XXX] ehlo=1 starttls=0/1 commands=1/2

SSL3 alert writeって出てますね。

解決策としては、先方のバージョンアップをお願いするか、手元のサーバーで半端にTLSさせないように、そもそもSTARTTLS非対応にしてしまうか。
今回はレンタルサーバーということで先方が即時に対応できないため、postfixで smtpd_tls_security_level = none としました。
master.cfでsubmissionポートの場合はTLSになるようにしておいたし、不正リレーもないことをあらためて確認。
受信メールサーバーだからある程度は開いておかないといけないということで may だったのですが、このパターンは今後結構出てきそう…

nginx webサーバーをIPv6対応にするときSSLでハマった

投稿日時: 投稿者:
返信

CentOS8 + nginxの環境で、もともとIPv4のみ対応だったサーバーをIPv6対応にすることにした。
OSレベルでのIPv6有効化は結構環境というかそのときのバージョンに左右されているので随時資料を見ることにする。（さくらのVPSではデフォルトでIPv6無効だが、有効にする手順も提供されていた。「再起動してください」とか雑な感じではあったが）

nginxではconfのserverディレクティブ内で listen [::]:80; listen [::]:443 ssl;を追加すればすぐ動く。ファイアウォールもfirewalldでサービス単位で通しているのでIPv4/IPv6を意識しなくても良い。

しかし、動かなかった…。

正確に言えば、ポート80でのIPv6通信はOKだったが、443でのSSLがダメ。ERR_CONNECTION_RESETやERR_CONNECTION_CLOSEDが返ってくる。

これ、IPv6かつ443 SSLのなかでのdefault_serverが決まっていないと起こる。
適当なserverディレクティブにdefault_serverを書くと期待通りに動いた。IPv4では既にdefault_serverが設定されていたので、増設分が必要だったわけだな。

オフィスのIPv6、v6プラス、DS-Lite設定でハマった2件

投稿日時: 投稿者:
返信

最近立て続けにIPv6というかフレッツ光でのv6プラス、DS-Lite(transix)の設定でハマったので記します。どちらもYAMAHAのRTシリーズをルーターで使用。

リモートワーク需要もあり、より高速にインターネット接続したいという要望があり、だったら固定IPの件はなんとか回避するとして、v6プラス/DS-Liteでいかがですか、ということで設定することになりました。
ひかり電話装置の下の場合はルーターのIPv6アドレスはDHCPv6-PDで取得する、ひかり電話装置じゃない場合はRAプロキシで、という基本的な理解とあとは豊富な設定例でなんとかなるんだろ！と思っておりましたが、環境がそれを許さなかった…！

その1: 西日本と隠れOCN

西日本エリア、ひかり電話オフィス、OCNのv6プラスでのRTX830設定。
実は最初、Interlinkを使っていたのでDS-Liteの設定を準備、Interlinkの申込時に「既に使用されています」と表示されるため、おかしいと思いクライアントさんに契約を確認してもらったところ、プロバイダとしてはOCNを利用していないがメールアドレス維持のために契約を残しており（PPPoEのアカウントは生きている状態）、かつ回線がOCN光での契約で、なおかつこの6月からOCNはデフォルトでv6プラスを有効にしているというのです。

■ニュース 2020年6月11日:「OCN 光回線サービス」において、IPoE接続を標準機能として提供開始 | NTTコミュニケーションズ 企業情報

既にCAF番号とアクセスキーはOCNで使われているので、InterlinkではDS-Liteを申し込めません。じゃぁOCNを使いましょう。InterlinkのIPv4は固定IPアドレスのため引き続き使います。

西日本ではHGW（ホームゲートウェイですかね）の配下では、DHCPv6-PDではなくRAプロキシで取れという話はなんとなく覚えていたのですが、ここの環境ではひかり電話オフィスのαA1という主装置の下です。主装置下ではDHCPv6-PDだと思っていたのでそのようにしますが、繋がりません。

もしかして、αA1もHGWと同じ挙動か?と思って試してみたら当たり。
RTシリーズのv6プラス対応機能の「設定例その3」の通り、HGW配下と同じRAプロキシの設定にしたところ、無事に接続できました。
■v6プラス対応機能

IPv4のデフォルトゲートウェイをIPIPトンネルとし、LAN内のwebサーバーの公開のため、webサーバーからの通信のみInterlinkのPPPoEを通すように書きました。
filter11に合致した通信はpp1、その他はtunnel1ということができます。
nat descriptorはpp1とtunnel1の2つ分必要です。

ip route default gateway pp 1 filter 11 gateway tunnel 1
ip filter 11 pass 192.168.0.200 * * * *

その2: 古いひかり電話主装置を避けたかった

東日本エリア、ひかり電話オフィス、InterlinkのDS-LiteでのRTX1200設定。
こちらもInterlinkの固定IPv4アドレスを使用しており、またパートナー会社との接続のためIPv4アドレスを変えたくないということで、こちらもPPPoEは残します。

このクライアントさんではInterlinkしか契約がないのと、フレッツ光も東日本純正の契約なので、DS-Liteの対応でトラブることはありませんでした。
しかし、ひかり電話主装置がαGX type Lという古いもので、WAN側が100Mbpsです。そのためこの主装置の下にルーターを接続しても、外向きが100Mbpsになってしまいます（実効値はもっとはるかに低いでしょう）。ということで、ONUの下にHUBをおいて、ひかり電話主装置とRTX1200に分配して使用しておりました。

RTX1200にRAプロキシの設定でのIPv6設定を行い、transix終端点へのIPIPトンネルを設定しました。transix経由のIPv4とPPPoE経由のIPv4の使い分けはあっさり動きますが、v6通信が通らない。
さらに、数時間するとtransix経由の通信もできなくなり、ルーター再起動で直るという現象が起きます。何かがおかしい
なおその間、ひかり電話はなんの支障もなく通話できている。

やたらとググったんですがアドレス保存してなかった。たぶんこのへんをさんざん読んで理解したような気になっているところ。
■フレッツ光ネクスト (ひかり電話あり) 回線において、ひかり電話と自前の設備を IPoE IPv6 的な意味で仲良くさせる – diary.sorah

結論としては、ひかり電話契約があり、かつ主装置αGX-LとRTX1200が並行にある状態だと、どちらもDHCPv6-PDを受けようとして奪い合いになってしまう。NGNからのm-flagつきRAは3時間毎に配られるらしく、奪い合いが発生して通信が停止するのもそのタイミングと合致する。
つまり、遅いαGX-Lの下でDHCPv6で動かすか、並行でのv6利用は諦めるしかない。あとは主装置を買い換えてください…

ちなみに、DHCPv6-PDの奪い合いをしているのにひかり電話が途切れなかったのは、主装置からのひかり電話はNGN内でのIPv4通信だからだそうだ。じゃぁv6やめてくれてもいいじゃんとか思ったけど、v6はv6なりにファームウェアのアップデートとかで使っているようです。資料はどっか忘れました。ダメだということだけは確認した段階で疲れて閉じちゃった。ごめん。

もしかしたらRTX1200のLAN3ポートに主装置を繋いでIPv6やらNGN内の通信をスルーしてあげればいけるのかもしれないけど、主装置に対してのv6通信は削ることになるし、その場合の電話の挙動がどうなるかわからん（＆電話は止められない）ので、やめました。

リモートワーク全盛なので

中小企業様よりVPNとかv6化とかの注文をいただいております。安価かどうかは知りませんが、あんまり大規模にお高くやるやつじゃない感じで対応しております。環境毎に異なる場面が結構ありますので、上記はその一部の例です。
社内SEがいるぐらいの会社だったら自前でできることだとは思いますが、そうでない規模のところをお手伝いしております。