YAMAHA業務向けルーター運用構築スレッドPart24
■ このスレッドは過去ログ倉庫に格納されています
>>783
自己レス
いつの間に、同時セッションが500,000に修正された。
最初、ユーザーマニュアルが簡易でがっかりだったが、技術資料がちゃんとあった。
http://www.rtpro.yamaha.co.jp/UTM/docs/utx/index.html
元の機種にあったスマホのアプりやSSL-VPNも使えるな。 LANマップ対応とインターフェースのデザイン変えた程度の差だろうからね
従来ヤマハに無い機能をわざわざ減らさないよね
所々にCheckPointの名前が出てくるのが痛々しいw 調子悪い830の保守交換依頼したら全力で回避してきてワラタ
あれ試してくれこれ試してくれって、大丈夫かよ保守体制 保守を気にするならば富士通にしておくと良いぞ
ヤマハは扱い無いけどな Si-RとヤマハはNetVehicle時代から互いにやり合ってる感がすごい 多分、VPN経由なのでMTUの問題だと思う。
https://moji.or.jp/ipafont/ には繋がらない（httpsの鍵交換には成功している模様。wgetコマンドで確認できた。）が、
他のサイトにはしっかりつながる。
こういう場合、他のサイトとはつながるので、
データを送ってくる上記のサーバーが不適切なんだろうか。
たとえば、ICMPを拒絶しているとか。 >>804
相手はMSS=1380でハンドシェイクしてきているようだが、セッション確立後それ以上のサイズでも送信しているようだ。 >>804
自己解決しました。
ゲートウェイにおいて、mssを上書きするようにしたところ、
うまく通信できるようになりました。
>>805さん、レスありがとうございます。 RTXのmss autoってどういう仕組みだろうか
これがないとトンネル経由でいろいろ接続不能の自体に陥った トンネルインタフェースに設定したMTU設定に連動してtcpパケットのmss値を書き換える機能でしょ 「MTU設定に連動してtcpパケットのmss値を書き換える」のことを、
MSS CLAMPっていうの？
RTXのトンネル設定のmss autoって、MSS CLAMPを使うっていう意味でいいのかな。 >>810
MSSをある値でclampするのがMSS Clamping
「ある値」は手動で指定することもあれば、MTUなどから計算させることもある
mss autoは後者 ip tunnel tcp mss limit autoはトンネルテンプレで簡略化してるはずなのにこれだけはコピーされないのかよ！
ってツッコミ入れつつconfig書いた思い出が強い >>811
「インタフェースを通過する TCP パケットを監視し、MSS オプションの値が設定値を越えている場合には、設定値に書き換える」
予想していたとおりの挙動でした。
すみません。ありがとうございます。
>>812
なるほど。
トンネルのMTUって、RTXの場合、
たしかデフォルトでとても低く設定されていたと思います。
帯域を広げるためにあとから手動で最大限で設定した記憶があります。
デフォルトのMTU設定からmss算出されたらけっこう小さくなりますね。
>>813
とにかくその設定入れておけばうまく通信できたので、
入れたままにしておりました。 光ファイバ、ネットワーク、サーバー関係の故障って、因果関係ないのに、なぜか重なることってない？
それがゆえに、原因の追求が難しくなってしまう。 設定ミスや軽微な故障や不具合が潜在的にあってそれが何かをきっかけに露呈してるだけかも >>815
光ファイバ切断事故、ネットワークダウン、DNSが引けなくなってサーバ障害ってのは経験したことある
バックアップ用のDNSがあるから動くはずだったんだけど動いてくれなかったｗ ハードウェアトラブルは環境に起因する事が多いな
ハードソフト関わらず何か発生すると負荷によって次のトラブルが露見したり、通常とは異なる動作が発生して設計した(つもり)とおりに動作せずに次のトラブルを引き起こす
そして連鎖的に想定外の言い訳を使う様な事態になる
人間自体が想定外が不得意な人の方が多いだろ？ RTX1210出た直後の調子悪さは言い訳考える気すら起きなくなったな >>815
＞因果関係ないのに、なぜか重なる
しかし、>>816-819は因果関係がある場合を言っている。
そうではないので実際の一例を挙げる。
(拠点1)-------ping-------(拠点2)----------[本部]------------------(拠点3)
拠点3でDocker コンテナで動作するAsteriskの電話が不通、もしくは音声が途切れるようになってしまった。とりあえず、コンテナを再起動するが解決せず。
（明日から会社は休み明けなのにやばいと焦る。）
拠点3と本部との間のネット回線で輻輳が発生しているのかもしれないと考える。ひかり回線の障害情報を調べると、直前に本部のある地域のすぐ隣の地域について、障害発生情報が挙がっている。
（しかし本部の回線を収容している基地局ではないが、疑わしく思う。輻輳となにか関係があるのではないか。問題0）
拠点1と本部について疎通試験をおこなうと、pingのレスポンスが100msを越えている。いつもなら1ms程度なのにやはりおかしい。本部周りのネット回線で不具合が生じているにちがいない。
普段は正常に動作している構成なので、このようなトラブルはネット回線が引き起こしているに違いないと考える。
どう考えますか。 >>823 つづき
しかし、拠点1と拠点2について疎通試験をおこなうと、pingのレスポンスが100msを越えている。いつもなら1ms程度なのにおかしい。（さらなる悩みにとらわれる）
ん？これは拠点1と拠点2の回線の輻輳だな。本部周りのネット回線の問題ではない。すなわち、別の問題だとわかる。（問題１の切り分け）
改めて、拠点3のAsteriskコンテナに意識を戻す。ねんのため、ホスト丸ごと再起動を行う。
再起動を祈りながら、動作確認をする。電話テストをする。正常になった。レジストも問題なし。
コンテナ再起動では解決しなかったので、ホストレベルの問題だとわかった。（問題２の切り分け）
翌日、さらに別の拠点4にあるハードディスクがゴミメールに溢れて、
メール転送システムが停止する問題が発生していることに気づいた。（問題３）
タイミング的に同じ時間に発生。
このように、これら、バラバラの問題(0から3)が同時に発生したわけだ。これまでの経験では、無関係の問題が複数同時に発生する偶然が多いように思うのである。
結果、問題解決のために色々頭を巡らせる必要が有り、焦るししんどい。これをたった一人で抱え込んでいる。単独管理者である。 ここから得た教訓として、
できるだけ、独立事象であることを確信できるようにするために、
システムを明確に分離しておくことが良いと思う。
同じホストにいろんなものを詰め込むと、問題が発生したときに非常に悩ましくなる。
全てが敵に思えてくる。 sshをホストのポートフォーワーディングなどせずにIP Masquaradeを通したいのですが、
nat descriptor masquerade rlogin 1 on
だとポート22にしなくてはならないとのことですが、22は流石に危険ではないですか？
素直に静的IPマスカーレードなどで好きなポートを使ったほうがいいのでしょうか？ WAN側からアクセスしない
LAN側からアクセスしてるなら信用無い端末がLAN内に有るのを何とかした方が良い ポートが22だからって危険とはならんな
認証前にクラックできるならどのポートだろうがリスクあるが
そういうセキュリティーホールないならアタックされる頻度が減る程度だろう
公開鍵認証使ってればそこにセキュリティーホールなければポート22番でもさしたる問題は無い レスありがとうございます。wan側からのipv4アクセスは控えようと思います。
ipv6の一時アドレスじゃない方（変動しない方)を使って、アクセスしようかと考えています。
こっちは一時アドレスと違ってオフラインでしか流出しませんし。 >>825
先にホストの負荷状況まで確認しておけばよかったね。
pingが悪化したからと言ってネットワークが悪いとは限らない システムとしてはこういうことはよくあるけどね。 >>829
言ってる意味が分からん。
外からの入り口作るなら、IPv4もv6もやらなきゃならんことは変わらんぞ。
IPv6はアドレスが広いから安全とか無いからな。 >>831
うちはv6使ってないんで分からないんだけど、v6でもポートスキャン来るの？ サーバー側でアクセスしてきたv6アドレスのリストを闇で共有してるのはありそうな気がするけど
v6だから安全なんて事はない >>834
特定のポートでのホストスキャンは日常的に来てる
多分存在確認できたらポートスキャンに移ると思う
総当たりでなくてもフィッシングの要領でアドレスは収集できる 普通のクライアントは一時アドレスでアクセスするでしょ
クライアントによるけど普通は定期的に変わるし
プレフィックス /64 なら約1800京個の中で割り当て
リストとっても次使われることなんてほぼないでしょ すぐリスト化されて攻撃されない保証もないけどな
まぁリスト化なんてしなくてもフィッシングで即スキャンとかもあるんじゃね
安心と思って防御しなくてよいって話ではないだろう >>826がそもそも何をしたかったのかがよくわからない
sshを通したくてrloginをonにするんだとしたら
sshのクライアントがIPマスカレードの内側で、かつクライアントのポート番号を変換されたら困る(クライアントが特権ポートを使わないといけなくて、たとえば60000からとかでは困るとか)、という場合だと思うんだけど
今どきそんなsshの使い方するの >>839
829に
>wan側からのipv4アクセスは控えようと思います。
と言っているから、たぶんコマンドの効果を分かっていない気がする。 実際のところ今はランサムウェア全盛だからな
ファイアウォールを正面突破する攻撃は一般的な対策してりゃ十分
というか中小零細は最初から相手にしてない 中小限らずという点だと、社内ネットワーク宛というよりもメールサーバー宛ての方がひどい。
どこで見つけてきたか知らないが、社内でしか使用していなはずの文字列を使用したメールサーバーへのログイン試行がよく見受けられる。
スパムになっている一部は、正規のSMTPログインをした上で送信しているものが見受けられるから、こういうので突破されたんだろうな。。。 >>845
アクセスが来てるアドレスの全部が全部黒ではないようだ。 >>846
＞社内でしか使用していなはずの文字列を使用したメールサーバーへのログイン試行
これってパスワードのことじゃないの？
https://haveibeenpwned.com/Passwords
その試行されているパスワードをここでチェックした？ リモートログインのパスワードを変えたくないからsshのポート番号を変えて欲しいみたいなオーダ受けたことあったな
気持ちは分かるが http://www.rtpro.yamaha.co.jp/RT/docs/relnote/Rev.14.01/relnote_14_01_40.html
IPIPトンネルで、L2TP/IPsecおよびL2TPv3に対応した。
ただし、IPv6 IPoE + IPv4 over IPv6 接続のサービスでは、契約形態により制限があるため、以下の技術資料をご確認のうえ、ご利用ください。
http://www.rtpro.yamaha.co.jp/RT/docs/#ipoe_46
契約形態により制限があるとはどういうことなんでしょうか。
速度制限があるってことですか。
プライオじゃないと使えないとか？ IPv4アドレスの共有環境じゃ一部の通信が通らないから >>850
ん？どういうことですか
IPv4はPPPoEで、IPv6はIPoEですよね >ただし、IPv6 IPoE + IPv4 over IPv6 接続のサービスでは
だから、「IPv4はPPPoEで、IPv6はIPoE」ではありませんよ 普通に一つのv4のIPアドレスを共有している
V6プラスとかバーチャルコネクトとかのサービスの事言ってんだろ フレッツならもう一つPPPoEでプロバイダ契約して
マルチセッションで接続すれば良いよ >>853
不特定多数とv4グローバルを共有するということですか。
それなら、たしかにIPIPは通らないですね。
そういうことなら、ヤマハも「契約形態により制限がある」などと曖昧にせずにきっちりと書けば良いのになあ IPsec over IPIP（IPv6）トンネル複数本（複数拠点行き）を、RTX1210で使っています。
速度計測ソフトで調べたところ、複数トンネルでの通信の合計が3MB/sにしかなりません。MTUも最適化済みです。
奇妙なのは、各トンネルそれぞれで3MB/sは出るのに、同時通信時には複数トンネルでの通信の合計が3MB/sにしかならないことです。
このとき、RTXのCPU使用率は全然上昇していません。
そのためフレッツ光ネクスト（西日本）が、VPNプロトコルパケットに対して帯域制限を掛けているのではないかと疑っています。
念の為、ローカル環境（LANリンクローカルアドレス）で複数台のRTXをつなぎ同様のテストをして、各IPsec over IPIP（IPv6）トンネルの帯域の和が一定になるという制限が生じるのか試そうと思います。
フレッツ光ネクストの網内は、優先制御がされていてそれに関する不正な値をもつパケットはドロップされます。それは知っているのですが、帯域制限までも掛けているのでしょうか。
そうなら何らかの値をセットするようにRTXを設定しようと思います。
何かアドバイスお願いします >>856
まずは、「IPIP（IPv6）」が何を言いたいのかはっきりさせようか。 どっかのVNEのIPIPによる固定IPv4アドレスでIPSecをしている という環境なら、
制限をかけるとするならそれはVNEで、NTTは関係ないよな。 >>857
IPIPが、ipv4 over ipv6 になっているという事です。 フレッツ網内でやってるって話だろ
HGW使ってるなら一度外してみたら？ 投稿の前後関係から、851の「IPv4はPPPoEで、IPv6はIPoEですよね 」といったのと同一かと。 >>859
だったら余計に、「そうなら何らかの値をセットするようにRTXを設定しようと思います。 」が的外れです。 >>862
何らかの値とは、パケットの優先制御の領域の値のことで、
それを書き換えるということです。
それをすることによって、VPN通信が通じた事実があります。
だから、帯域制限があるとするなら解除できる値もあるのではないかと。
>>860
HGWを外すと、ひかり電話できないので無理なんです。
RTX3台でローカルでVPN（IPsec Over IPIP）テストを行おうと思っていたんですが、
ラズパイと、拠点側のPCとを上記と同じプロトコル構成でテストしてみようかと思います。
もしそれで合計3MB/sec帯域にならなければ、RTXがボトルネックになっているということがわかりますし、
同じ結果となれば網側の問題（IPIPに対する帯域制御の可能性）かと思います。 >>863
>それをすることによって、VPN通信が通じた事実があります。
それは、そう見えただけで、事実ではない。 学校でちゃんと勉強してこなかった奴って何言ってるか分からん
なぜ周りが色々推察までして教えてやらんといかんのか 話が通じないならconfigとネットワーク構成図を書けばいい
共通言語でコミュニケーションすること大事 >>868
それらを書いたところで、その認識が誤ったものになる という話なんだよ。 >>863
＞>>860
＞HGWを外すと、ひかり電話できないので無理なんです。
HGWを挟んでるなら自分から先にその情報出してよ
機種は何？
切り分けのために一時的に外すのも無理なの？
外すのが無理ならパケットフィルタ無効くらいは試した？
＞同じ結果となれば網側の問題（IPIPに対する帯域制御の可能性）かと思います。
HGWを外すのが無理だったらHGWの可能性も否定できない NGNじゃなくてインターネット側でVPN構成してるっぽいのとMTUを最適化とか言ってるのが非常に怪しい気がする つかIPv6でVPN張ればNGN網内のスループットで速いのに、VNEのIPv4 over IPv6を通してIPv4でVPN張ってるから遅いんじゃねーの？
足まわりからなにから情報隠しすぎてわけわかんねーしスルーしようとしてたけど、いつまでもグダグダやってるし要領得ないからエスパーしたぞ HGWかましてたらIPv6-ipsecは速度でない。
300型番なら一桁Mbps
500型番で90Mbps程度
400や600は未測定
速度が欲しけりゃIPv6-IPIPにすれば600Mbps以上でる。 まずはファームウェアのリビジョンを知りたいよね
[4] IPsec over IPIPのファストパスに対応した。
これが入っているかどうか そもそもが最大30Mbpsぐらいしか出ない環境かもしれん。 >>877
たぶん質問者の環境は、IPsec over (IPv6 over IPv4)の環境と思われ。 別拠点(Linuxマシン)--IPsec(IPv4) over IPv6 --HGW--RTX1210--This site
という構成が現状です。
今度、HGWのハブに直接Linuxマシンを接続して、
RTX1210で実現しているIPsec(IPv4) over IPv6というオーバーヘッドプロトコルと同じようにして、
別拠点と接続してみます。
別拠点(Linuxマシン)--IPsec(IPv4) over IPv6 --HGW--Linuxマシン--This site
これで、最大の速度をiperf3で測定し、3MB/sec以上でるか試します。
それでも、3MB/secしか出なかったら、RTX1210よりもNTTフレッツネクストの網が怪しいです。
3MB/sec以上出た場合は、RTX1210がボトルネックになっていると思います。
（>>875 そのファーム導入済みです。CPU使用率が低いままでした。）
また結果報告します。
今、LANカードなどを取り寄せ中で、準備中です。 >>871
HGWの可能性もありますね
正確には、HGWでなくて、OGWなんです。10万しました。
実験結果によってどうするか考えたいと思います。
結果によっては、NTT回線辞めるかも。 >>879
Linuxマシン扱えるなら、IPv6上で別のVPNプロトコルを使ってVPNを構築した方が早いし速くなると思うの。 能力が高いのか低いのか分からんが、臨機応変さに欠けるように思える。
ここまで試行錯誤する前に方針転換できなかったのかな？ >>879
情報が足りないからわざわざ聞いてるのにまともに回答できないなら質問するなよ 相談しているように見えて、単にマウント取りたいだけなんだろう。 ていうか仕事で使うなら電話用と通信用に2回線引いたほうがいいぞ >>880
網側の制限を解除する値なんて無いよ
網側で使われたら困る物が通らないだけ
ひかり電話がビジネスホンを指しているならばOGWは優先制御している 前にOGで速度出ないってさんざん検証してただろ
過去ログ漁ってきた方が早いんじゃないのか >>888
優先制御の値を書き換えると、通らなかったパケットも通るようになるよ
rsyncでのファイル転送パケットには優先制御に関する値が書き込まれていて、
それゆえにNGN網を通過できなかった。
しかし、優先制御に関する値をデフォに、経路上のRTXで上書きすると、
通るようになったぞ >>887
電話はNGNで、
ネット通信は癖のない通信会社にしたい それは、値を書き換えるというよりも「優先制御を行わないようにしている」ということなので、888の認識が正しい。 ■ このスレッドは過去ログ倉庫に格納されています
