YAMAHA業務向けルーター運用構築スレッドPart24
■ このスレッドは過去ログ倉庫に格納されています
>>741
ipv6 prefix 1 dhcp-prefix@lan2::/60
ipv6 lan1 address dhcp-prefix@lan2::1:0:0:0:1/64
でいいんですか？
lan1には二行目で指定したグローバルIPが振られましたが、
RTX830配下のホストにはグローバルIPが振られません。
やっぱだめっぽ LAN2 [client]
state: established
server:
address: ::
preference: 0
prefix: XXXX:YYYY:ZZZZ:AAf0::/60
ちなみに、show status ipv6 dhcpの結果はとなっていました。上>>736の/56というのは間違いでした。 >>750
プレフィックスの設定が違う。
無理と言う前に少し考えたら？ ttps://www.okamoto-net.com/c1072/
/64にしてもだめだった。
ここなど参考にしていろいろやってみたがわからん。
あとは識者の方々にまかせます。
HGW配下でもdhcp-pdが使えるとわかっただけでも収穫ありました。 >>753
だからさ、dhcp-prefix@lan2::/64としたら、「f1」でなく「f0」となるってば。 >>747
ソフトウェアにはハードウェアが必要
形あるものは壊れるのが宿命
>>748
YNO＋外部メモリ
どういう対策になるのですか >>750
その2つの設定はインターフェイスへのアドレス設定だから
それだけではクライアントはインターネットには出られない
ルーター広告の設定
フィルタリングの設定（なければ外部から攻撃し放題）
ゲートウェイの設定
少なくともこれらが必要 dhcp-prefix@lan2::/60でもf0(lan2のアドレス)になるんですが。。。
lan1は自分で指定しているのでf1になりますが。
配下のホストにグローバルipが振られないのはm_flag=onにしていないからかな？ m_flag=onでもだめだわ。配下ホストにグローバルIpが振られない。
もうわからん。ギブアップ。 ipv6 prefix 1 dhcp-prefix@lan2::5:0:0:0:1/64
ipv6 lan1 address dhcp-prefix@lan2::5:0:0:0:1/64
としたら、f0ではなくf5になりました。配下のホストにもf5のサブネットで振られてます。
サブネットの選択はHGW→RTX830の再委譲なので4bitだけできるようですが、とりあえずできました。
どうもお騒がせしました。 ttps://www.okamoto-net.com/c1072/
こちらのホームページの
# 配布するプレフィックスを決める
ipv6 prefix 1 dhcp-prefix@lan2::1:0:0:0:1/64
ipv6 prefix 2 dhcp-prefix@lan2::2:0:0:0:1/64
# LAN3のIPv6アドレスを指定する
ipv6 lan3 address dhcp-prefix@lan2::1:0:0:0:1/64
ここを真似たらできました。 >>761
落ち着いた今なら何が悪かったのかわかるはず。 >>743
ルーターを無くしてもネットワーク機器は何かしら残るから根本的には解決しない
クラウドだってしょっちゅうトラブっているし、ユーザーは待つしかないのが歯痒いトコロ >>762
61bit〜64bitのサブネットを示すには、プレフィックス長/64で指定するしかないですな。
( 注：内部動作の関係上「dhcp-prefix@lan2::1:0:0:0:0/64」ではなく、「dhcp-prefix@lan2::1:0:0:0:1/64」と設定してください。 )
この注意書きの意味がやっとわかりました。prefixの指定なんだから本来1:0:0:0:1と書かなくてもいいはずですしね。 ヤマハのUTMの話題はこのスレでいいのかな？
使っている人いたら感想おしえてほしい
今はFortigate 60E なんだが、そろそろ更新時期なんで・・・ >>766
悪いことは言わないから素直に60Fにしたほうがいいぞ 社内には思ったよりとんでもない事をするアホが居るのだよ LANに野良が繋がらないような物理防御+クラウド型エンドポイントセキュリティソフト+資産管理ソフトでのユーザー監視、使用ソフトの制御
導入が容易な金額の値段のUTMなら、上記をやれば同等以上の効果がありそうだけど。 fortigate使ってるならヤマハルーター要らんよなw 海外製品はガラパゴス仕様のFlet's直収は不得意だからな >>775
ファイアウォール ∋ パケットフィルタ ？ >>777
おかしくはないよ
自組織から犯罪を幇助するような通信が
出て行くことを防ぐのも一つの考え方 >>779
ファイル共有ソフトの通信を遮断するとかだな 何かしらのボットネットに組み込まれた端末が中にいる（若しくは入った）場合の
頻繁に悪用されるポートは塞いでおくとかね そいや、UTX200/100、同時コネクション数が50,000になってるんだよね。
ttps://network.yamaha.com/products/firewalls/utx200/spec
少な過ぎるし、元の1570/1530が500,000なので
誤記だと思うのだが、ニュースなんかでもそのまま流れている。
４ヶ月、誰も指摘しないって、中の人含めて興味無いのだろうなぁ。
＃もしかして、ホントに50,000だったというオチだろうか。 おかしくないと思う。
フィルタかけまくると実質スループット確保できないだろうし
UTMは他社関わらず熱暴走するからヤマハみたいな野良置きされやすい環境だとつらいかも 同時コネクション数はfortigateより劣ってんな
今時数万はねーよwww rtx830、kakaku.comでみたらどこも在庫なしだね。
法人でも手に入らないらしいし、上の方で書いてあったことは本当だったみたい。 そうなんだ。。予備10数台買っといて良かった
当面新型も出ないなこりゃ ヤフオクで4台しか出てない。半年前は結構出てたのになさ 1220なんて830以上に入手困難だよ
ほんとうに生産しているのか あるところにはあるんだよなぁ…w
代理店もお得意様には専用在庫で確保してるよ >>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アドレスの共有環境じゃ一部の通信が通らないから ■ このスレッドは過去ログ倉庫に格納されています
