アカウント名:
パスワード:
ルーター下のIPにその上層のものとかち合う番号が振られていても、なんら問題ないのが「ルーター」ってもんじゃないの?
自分の家の中で中古のルーターでもいいので1個買ってきて試すといいよ、たぶんあなたにとって予想だにしない結果が出るから。
#そしてここからネットワーク構築を学んでいっていつの間にかにネットワークエンジニアになるまでたどり着こう
いや、いままで家でも会社でもいくつもルーターをセットアップしたことがあるけど。ちなみに「わかってる」あなたは、どういう問題が起きると思っているわけ?
その発言自体で分かってないのが丸出しだぞ。実際にルーター2台ハブにくっつけてルーターのIPアドレス設定を重複させてみればわかるんじゃない?よほど気の利いたルーターじゃない限り、どちらともが正当性を主張してARPパケット投げまくるから通信がまともにできなくなる。
フロアのL3スイッチでちゃんとVLAN割っておけば、やらかした部屋で繋がらなくなるだけだから、わざわざこんな注意書きをしなくてもよいのでは、ということでは?
部屋ごとにVLAN切ってセグメントを分けるのかぁ。めんどくさそうw
4094室以上のホテルの場合は・・・
#まずフロアレベルではL3スイッチは置かない(エッジかそのフロアスイッチをPoE(+)対応する必要があって、そっちに費用が吸われてコアorゲートウェイルーター以外のL3化予算はつかない)、ってのもあるが、それはさておき...
ホテルの場合は一般的に各部屋ごとでL3レベルも含めた分割ではなく、L2レベルて特殊なVLANの組み方(プライベートVLAN(エッジ)やらマルチプルVLANやら)で対応するんだけど、これもろくすっぼ機能の中身を理解しないで設定をミスると同じフロアは大丈夫なんだけど、他フロアにはバラまけるという問題が発生する。で、実際にそんな設定になっているホテルが有線LANポートのついているビジネスホテルでは多めの印象。Wi-Fiはわりかししっかりしてるんだけどね。今回はそれ以前のレベルだと思うけど、案外ネットワーク的に危険なホテルそこかしこに存在してる。
せっかくエッジかそのフロアのL2スイッチでプライベートVLAN切ってるのに、フロアを纏めてる基幹スイッチとかでフロアスイッチと接続するポートに対してはプライベートVLAN切って無くてフロア間で通信出来ちゃうのか……
プライベートVLANが設定されたスイッチの集約ポートに対して受ける側が同じ会社のスイッチだったら問題起きにくい(起きないとは言ってない)んだけど、他社製だったりルーターのLANスイッチポートだったりすると悲惨。実装の違いで集約ポートからの受けは制限なしにしないと通信できないとかざらに発生する。
新規開業以外は大抵機器は見積設計時から既存の設備と同レベルまで削られるのと、既存配線維持を厳命されるので、タコな実装設計が生まれやすい。
#いい加減8フロア以内ならフロアからYAMAHAルーター直結とかやめませんか?あいつ純粋なIPルーターとしては優秀だけど、それ以外はそんなに良い処理能力持ってませんぜ。
やらかした客にもサポートしなきゃいけないから注意書きで回避しようとしてるのでは?
横からですが分かってなくて申し訳ない(オンライン情報処理技術者合格したがネスペは落ちた)
ホテルルータ(LAN側192.168.0.1/24)に客ルータ(WAN側192.168.0.10,LAN側192.168.0.1/24)をつなぐことを言っていますか?それともホテルルータ(LAN側192.168.0.1/24)に客Aルータ(WAN側192.168.0.10,LAN側192.168.1.1/24)と客Bルータ(WAN側192.168.0.11,LAN側192.168.1.1/24)をつなぐことを言っていますか?いずれもホテルLANが落ちる事態にはならないと認識していますが間違っていますでしょうか。
認識は前者であってるが、残念ながらホテル側の機器が適切に調達・設定されていないとホテルLANは落ちる。ホテル側でなにも制限設定が掛かっていないと、以下のことが発生する。
まずDHCPによるIPアドレス重複が発生する可能性が高いので端末が通信できなくなる。が、これはWindows等の受信側で下記のARPによる重複検知してくれる可能性が高いので端末ローカルの障害で終わる可能性が高い。
次に、通常ARPでIPアドレス解決を行うのだが、冗長化設定時を除き大抵のネットワーク機器は静的にIPアドレスを設定した場合、重複したIPアドレスのARPパケットを検知した場合は、自分がそのアドレスの正当な保持者として同じIPアドレスのGARPパケットを投げる。で、それを検知した同じIPアドレスの機器がまたGARPを投げるという挙動をお互いで繰り返すようになる。そして、受信側も通常の場合は最後にARPパケットを受信した方を正とする場合が特殊な設定でもしない限り圧倒的に多い(そうなっていないとL3レベルの冗長化機能やライブマイグレーション機能が使えなくなる)ので、結果正常な通信はができなくなる可能性が極めて高い。
ありがとうございます。前者の構成を前提に、ホテルLANに端末A(192.168.0.100)、客LANに端末B(192.168.0.100)があるとして、端末AのGARPが客LANや端末Bに届いたりその逆があったりするということでしょうか。ARPはルータ(ここでは客ルータ)を超えないと認識しています。
前者の構成を前提に、ホテルLANに端末A(192.168.0.100)、客LANに端末B(192.168.0.100)があるとして、端末AのGARPが客LANや端末Bに届いたりその逆があったりするということでしょうか。ARPはルータ(ここでは客ルータ)を超えないと認識しています。
ここにちょっと認識のずれがでてきていると思います。今回の場合は大前提として「客ルーターの"LAN側"ポートにホテル側のLANケーブルを挿した」という状態です。なので、ホテルLAN/客LANとあなたが識別しているものは実際には存在しておらず、同一ネットワークセグメント上
> 今回の場合は大前提として「客ルーターの"LAN側"ポートにホテル側のLANケーブルを挿した」という状態です。
そんな勝手な前提立てるなよw
> 実際にルーター2台ハブにくっつけて
って話でどうそこまで話が飛ぶんだ?www
いや。そんな前提でっせ、今回の話。ちゃんと読んでこい。
ホテルルータって書くと、ポータブルルータ(客ルータ)と読み間違いしやすい気がする。ホテルルータ: https://www.elecom.co.jp/products/WRH-300WH-H.html [elecom.co.jp]
>ホテルルータ(LAN側192.168.0.1/24)に客ルータ(WAN側192.168.0.10,LAN側192.168.0.1/24)をつなぐことを言っていますか?コッチでしょ。エレコムだから、ホテルと客は両方192.168.2.x/24な可能性が高いけど。
で、そこにLinuxの仕様が絡む [srad.jp]と正しくホテルのLAN側と客ルータのWAN側を繋いでも、客ルータのLANインタフェースの192.168.0.1(実際は192.168.2.1)のARP応答がホテルのLAN側に流れ込むように。結果、ARPスプーフィング攻撃されたと判定してネットワークから切り離されたり、IPアドレスの競合を検出して最悪ホテルルータのLAN側が止まったり、他のクライアントが同一LANセグメントに存在しない客ルータのLAN側に投げるようになって不通になる。IPセグメント被りと実装の考慮不足のコンボだけど、まじでありそうだな、このシナリオ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
ん?「ホテル側のIPアドレスと重複した物が割り当てられることがあり…」 (スコア:0)
ルーター下のIPにその上層のものとかち合う番号が振られていても、なんら問題ないのが「ルーター」ってもんじゃないの?
Re: (スコア:0)
自分の家の中で中古のルーターでもいいので1個買ってきて試すといいよ、たぶんあなたにとって予想だにしない結果が出るから。
#そしてここからネットワーク構築を学んでいっていつの間にかにネットワークエンジニアになるまでたどり着こう
Re: (スコア:0)
いや、いままで家でも会社でもいくつもルーターをセットアップしたことがあるけど。
ちなみに「わかってる」あなたは、どういう問題が起きると思っているわけ?
Re:ん?「ホテル側のIPアドレスと重複した物が割り当てられることがあり…」 (スコア:0)
その発言自体で分かってないのが丸出しだぞ。
実際にルーター2台ハブにくっつけてルーターのIPアドレス設定を重複させてみればわかるんじゃない?
よほど気の利いたルーターじゃない限り、どちらともが正当性を主張してARPパケット投げまくるから通信がまともにできなくなる。
Re:ん?「ホテル側のIPアドレスと重複した物が割り当てられることがあり…」 (スコア:2)
フロアのL3スイッチでちゃんとVLAN割っておけば、
やらかした部屋で繋がらなくなるだけだから、
わざわざこんな注意書きをしなくてもよいのでは、ということでは?
Re: (スコア:0)
部屋ごとにVLAN切ってセグメントを分けるのかぁ。
めんどくさそうw
4094室以上のホテルの場合は・・・
Re: (スコア:0)
#まずフロアレベルではL3スイッチは置かない(エッジかそのフロアスイッチをPoE(+)対応する必要があって、そっちに費用が吸われてコアorゲートウェイルーター以外のL3化予算はつかない)、ってのもあるが、それはさておき...
ホテルの場合は一般的に各部屋ごとでL3レベルも含めた分割ではなく、L2レベルて特殊なVLANの組み方(プライベートVLAN(エッジ)やらマルチプルVLANやら)で対応するんだけど、
これもろくすっぼ機能の中身を理解しないで設定をミスると同じフロアは大丈夫なんだけど、他フロアにはバラまけるという問題が発生する。
で、実際にそんな設定になっているホテルが有線LANポートのついているビジネスホテルでは多めの印象。Wi-Fiはわりかししっかりしてるんだけどね。
今回はそれ以前のレベルだと思うけど、案外ネットワーク的に危険なホテルそこかしこに存在してる。
Re: (スコア:0)
せっかくエッジかそのフロアのL2スイッチでプライベートVLAN切ってるのに、
フロアを纏めてる基幹スイッチとかでフロアスイッチと接続するポートに対してはプライベートVLAN切って無くてフロア間で通信出来ちゃうのか……
Re: (スコア:0)
プライベートVLANが設定されたスイッチの集約ポートに対して受ける側が同じ会社のスイッチだったら問題起きにくい(起きないとは言ってない)んだけど、他社製だったりルーターのLANスイッチポートだったりすると悲惨。
実装の違いで集約ポートからの受けは制限なしにしないと通信できないとかざらに発生する。
新規開業以外は大抵機器は見積設計時から既存の設備と同レベルまで削られるのと、既存配線維持を厳命されるので、タコな実装設計が生まれやすい。
#いい加減8フロア以内ならフロアからYAMAHAルーター直結とかやめませんか?あいつ純粋なIPルーターとしては優秀だけど、それ以外はそんなに良い処理能力持ってませんぜ。
Re: (スコア:0)
やらかした客にもサポートしなきゃいけないから注意書きで回避しようとしてるのでは?
Re: (スコア:0)
横からですが分かってなくて申し訳ない(オンライン情報処理技術者合格したがネスペは落ちた)
ホテルルータ(LAN側192.168.0.1/24)に客ルータ(WAN側192.168.0.10,LAN側192.168.0.1/24)をつなぐことを言っていますか?
それともホテルルータ(LAN側192.168.0.1/24)に客Aルータ(WAN側192.168.0.10,LAN側192.168.1.1/24)と客Bルータ(WAN側192.168.0.11,LAN側192.168.1.1/24)をつなぐことを言っていますか?
いずれもホテルLANが落ちる事態にはならないと認識していますが間違っていますでしょうか。
Re:ん?「ホテル側のIPアドレスと重複した物が割り当てられることがあり…」 (スコア:1)
認識は前者であってるが、残念ながらホテル側の機器が適切に調達・設定されていないとホテルLANは落ちる。
ホテル側でなにも制限設定が掛かっていないと、以下のことが発生する。
まずDHCPによるIPアドレス重複が発生する可能性が高いので端末が通信できなくなる。
が、これはWindows等の受信側で下記のARPによる重複検知してくれる可能性が高いので端末ローカルの障害で終わる可能性が高い。
次に、通常ARPでIPアドレス解決を行うのだが、冗長化設定時を除き大抵のネットワーク機器は静的にIPアドレスを設定した場合、
重複したIPアドレスのARPパケットを検知した場合は、自分がそのアドレスの正当な保持者として同じIPアドレスのGARPパケットを投げる。
で、それを検知した同じIPアドレスの機器がまたGARPを投げるという挙動をお互いで繰り返すようになる。
そして、受信側も通常の場合は最後にARPパケットを受信した方を正とする場合が特殊な設定でもしない限り圧倒的に多い(そうなっていないとL3レベルの冗長化機能やライブマイグレーション機能が使えなくなる)ので、
結果正常な通信はができなくなる可能性が極めて高い。
Re: (スコア:0)
ありがとうございます。
前者の構成を前提に、ホテルLANに端末A(192.168.0.100)、客LANに端末B(192.168.0.100)があるとして、
端末AのGARPが客LANや端末Bに届いたりその逆があったりするということでしょうか。
ARPはルータ(ここでは客ルータ)を超えないと認識しています。
Re: (スコア:0)
前者の構成を前提に、ホテルLANに端末A(192.168.0.100)、客LANに端末B(192.168.0.100)があるとして、
端末AのGARPが客LANや端末Bに届いたりその逆があったりするということでしょうか。
ARPはルータ(ここでは客ルータ)を超えないと認識しています。
ここにちょっと認識のずれがでてきていると思います。
今回の場合は大前提として「客ルーターの"LAN側"ポートにホテル側のLANケーブルを挿した」という状態です。
なので、ホテルLAN/客LANとあなたが識別しているものは実際には存在しておらず、
同一ネットワークセグメント上
Re: (スコア:0)
> 今回の場合は大前提として「客ルーターの"LAN側"ポートにホテル側のLANケーブルを挿した」という状態です。
そんな勝手な前提立てるなよw
> 実際にルーター2台ハブにくっつけて
って話でどうそこまで話が飛ぶんだ?www
Re: (スコア:0)
いや。そんな前提でっせ、今回の話。ちゃんと読んでこい。
Re:ん?「ホテル側のIPアドレスと重複した物が割り当てられることがあり…」 (スコア:1)
ホテルルータって書くと、ポータブルルータ(客ルータ)と読み間違いしやすい気がする。
ホテルルータ: https://www.elecom.co.jp/products/WRH-300WH-H.html [elecom.co.jp]
>ホテルルータ(LAN側192.168.0.1/24)に客ルータ(WAN側192.168.0.10,LAN側192.168.0.1/24)をつなぐことを言っていますか?
コッチでしょ。
エレコムだから、ホテルと客は両方192.168.2.x/24な可能性が高いけど。
で、そこにLinuxの仕様が絡む [srad.jp]と正しくホテルのLAN側と客ルータのWAN側を繋いでも、客ルータのLANインタフェースの192.168.0.1(実際は192.168.2.1)のARP応答がホテルのLAN側に流れ込むように。
結果、ARPスプーフィング攻撃されたと判定してネットワークから切り離されたり、IPアドレスの競合を検出して最悪ホテルルータのLAN側が止まったり、他のクライアントが同一LANセグメントに存在しない客ルータのLAN側に投げるようになって不通になる。
IPセグメント被りと実装の考慮不足のコンボだけど、まじでありそうだな、このシナリオ。