平成30年 春期 午後Ⅰ 問2 DMZへの通信について教えて
広告
DDDDMMさん
(No.1)
平成30年 春期 午後Ⅰ 問2に出てくるネットワーク構成なのですが(下記リンク)
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000fabr-att/2018h30h_sc_pm1_qs.pdf#page=9
DMZ上プロキシへの通信がどうなるかについてどなたか教えて頂いてもよろしいでしょうか。
プロキシはDMZ上にあるのですが、プロキシには接続元IPによってURLフィルタリング機能が切り替えられるとありました。(P11 表2)
しかし、LAN内PCからDMZへの通信は、FWで(もしくはルーターで)NAPTされてしまい、送信元IPアドレスはグローバルIPアドレスに変換されるかと思います。
プロキシ視点だと送信元IPアドレスでは社内LANから飛んできたパケットだな~くらいしか分からないのではないかと思いました。
設問3の(2)では運用PCに対してだけ、特別なURLフィルタリングを行うよう設定することが解答になっているのですが、NAPTされた後のIPアドレスでどうやって運用PCとプロキシが判定するのか疑問を持った次第です。
もしかしたら自分が根本的な誤解があるかもしれず、どのような通信でプロキシが判定出来るのか、どなたかご教示いただけますと幸いです。
https://www.ipa.go.jp/shiken/mondai-kaiotu/gmcbt8000000fabr-att/2018h30h_sc_pm1_qs.pdf#page=9
DMZ上プロキシへの通信がどうなるかについてどなたか教えて頂いてもよろしいでしょうか。
プロキシはDMZ上にあるのですが、プロキシには接続元IPによってURLフィルタリング機能が切り替えられるとありました。(P11 表2)
しかし、LAN内PCからDMZへの通信は、FWで(もしくはルーターで)NAPTされてしまい、送信元IPアドレスはグローバルIPアドレスに変換されるかと思います。
プロキシ視点だと送信元IPアドレスでは社内LANから飛んできたパケットだな~くらいしか分からないのではないかと思いました。
設問3の(2)では運用PCに対してだけ、特別なURLフィルタリングを行うよう設定することが解答になっているのですが、NAPTされた後のIPアドレスでどうやって運用PCとプロキシが判定するのか疑問を持った次第です。
もしかしたら自分が根本的な誤解があるかもしれず、どのような通信でプロキシが判定出来るのか、どなたかご教示いただけますと幸いです。
2024.10.07 21:00
pixさん
★SC ダイヤモンドマイスター
(No.2)
>しかし、LAN内PCからDMZへの通信は、FWで(もしくはルーターで)NAPTされてしまい、
>送信元IPアドレスはグローバルIPアドレスに変換されるかと思います。
すみません。問中にNAPTするという記述は見つけられませんでした。
スレ主様の誤解ではないでしょうか?
2024.10.07 21:20
いまいさんさん
(No.3)
>LAN内PCからDMZへの通信は、FWで(もしくはルーターで)NAPTされてしまい、
>送信元IPアドレスはグローバルIPアドレスに変換されるかと思います。
LAN内PC→FW→プロキシサーバ(DMZ) のパケットはNAPTによるアドレス変換はされません!
プロキシサーバ(DMZ)→FW→インターネット のパケットはNAPTによって送信元IPアドレスがGIPに変換されます!
たぶんDMZが外部NW的な誤解をされている?のかと思いました!
2024.10.07 21:37
DDDDMMさん
(No.4)
pixさん、いまいさんさん
ご教示大変助かります。
申し訳ないのですが、まだ理解しきれていないので、もう1点質問してもよろしいでしょうか。
NAPTが行われると思い込んでいた原因として2点あるのですが、どちらか(もしくはどちらも)間違いになりますでしょうか
1点目:DMZ内の機器はグローバルIPアドレス。
DMZ内に、外部からT社ドメイン名の問い合わせを受けるDNSサーバーや、外部メールサーバーがあったので、グローバルIPアドレスが必須なのかと思っていました。
2点目:ローカルIPアドレスの機器とグローバルIPアドレスの機器間の通信はNATが必要。
たとえ社内ネットワーク内だったとしても、グローバルIPアドレス領域にパケットを送出する際はNATされてしまうのかと思っていました。
ご教示大変助かります。
申し訳ないのですが、まだ理解しきれていないので、もう1点質問してもよろしいでしょうか。
NAPTが行われると思い込んでいた原因として2点あるのですが、どちらか(もしくはどちらも)間違いになりますでしょうか
1点目:DMZ内の機器はグローバルIPアドレス。
DMZ内に、外部からT社ドメイン名の問い合わせを受けるDNSサーバーや、外部メールサーバーがあったので、グローバルIPアドレスが必須なのかと思っていました。
2点目:ローカルIPアドレスの機器とグローバルIPアドレスの機器間の通信はNATが必要。
たとえ社内ネットワーク内だったとしても、グローバルIPアドレス領域にパケットを送出する際はNATされてしまうのかと思っていました。
2024.10.07 22:34
pixさん
★SC ダイヤモンドマイスター
(No.5)
>NAPTが行われると思い込んでいた原因として2点あるのですが、
>どちらか(もしくはどちらも)間違いになりますでしょうか
両方と思われます。
FWのルーティングテーブルの設定でいかようにもトラフィックは捌けます。
2024.10.07 22:56
いまいさんさん
(No.6)
この投稿は投稿者により削除されました。(2024.10.07 23:38)
2024.10.07 23:38
いまいさんさん
(No.7)
DDDDMMさんが誤解してる点が分かりました!
1点目も2点目もおっしゃてることは合ってます!
…NAPTやNATを理解することと、今回の問題を理解するはいったん切り離した方がいいと思います。FWのNATに関する設定について明記されてないので。
以下は一般的なNAPTの使われ方として理解してもらえると!
◆1点目
DMZ内の機器(DNSサーバ、外部メールサーバ)がGIPが必須だと思いました。
→必須です!
…ですが、実際にGIPを持っているのはFWで、DMZ内の機器はローカルIPアドレスしか持ってないです。
FWが所有しているいくつかのGIP宛のパケットを、DMZ内機器に着信するようにしてくれるのがNAPTやNATの機能です。
◆2点目
内部LAN機器からDMZ内機器に接続するときは、当然内部IPアドレスで接続します!
前述でも記載しましたが、DMZ内機器に設定されているのは内部IPアドレスです!!
(この部分が誤解されているように思います!)
本文中の「DMZ上のサーバには、固定のグローバルIPアドレスを割り当てている」の部分をよむと、機器に設定されているIPアドレスがGIPだ!…って感じますが違います。
ここの部分が誤解の原因だと思いました!
1点目も2点目もおっしゃてることは合ってます!
…NAPTやNATを理解することと、今回の問題を理解するはいったん切り離した方がいいと思います。FWのNATに関する設定について明記されてないので。
以下は一般的なNAPTの使われ方として理解してもらえると!
◆1点目
DMZ内の機器(DNSサーバ、外部メールサーバ)がGIPが必須だと思いました。
→必須です!
…ですが、実際にGIPを持っているのはFWで、DMZ内の機器はローカルIPアドレスしか持ってないです。
FWが所有しているいくつかのGIP宛のパケットを、DMZ内機器に着信するようにしてくれるのがNAPTやNATの機能です。
◆2点目
内部LAN機器からDMZ内機器に接続するときは、当然内部IPアドレスで接続します!
前述でも記載しましたが、DMZ内機器に設定されているのは内部IPアドレスです!!
(この部分が誤解されているように思います!)
本文中の「DMZ上のサーバには、固定のグローバルIPアドレスを割り当てている」の部分をよむと、機器に設定されているIPアドレスがGIPだ!…って感じますが違います。
ここの部分が誤解の原因だと思いました!
2024.10.07 23:38
X8bWwさん
(No.8)
この問題では、NAPTはどの通信でも一切行われていないと解釈するのが妥当かと思います。
そのため、プライベートIPを持っているPCや内部サーバーはインターネットに全く到達できません。
まず、先に述べられている通り、NATを用いなくても、プライベートIPとグローバルIPの間での通信は可能です。
プライベートIPというのはあくまでISP等でルーティングされないIPという意味しかないので、社内ネットワークで使う分にはグローバルIPと変わりありません。
そもそもプライベートIPとはグローバルIP用の領域の一部を後から内部用に予約したものです。
全く到達できないというとWeb等の閲覧はどうなっているのかと思われるかもしれませんが、HTTPとSMTPだけはプロキシサーバーなどが代行してくれるので可能なのです。
逆に、HTTPとSMTP以外で外に接続可能にしようとするためには新たなプロキシかNATかを導入する必要が出てきます。
PCが全てインターネットに繋がっていないというのは衝撃的かもしれませんが、組織ではしばしばある構成です。
余談
私も複数事例のネットワーク構成をよく知っているわけではないので、参考程度に
実際にグローバルIPとプライベートIPの間をNATせずルーティングするような構成をしている事例はあまりないと思います。
プロキシサーバー(やその他DMZにいるような機器)をプライベートIPだけのネットワークとグローバルIPだけのネットワークの両方に接続しているほうが一般的なんじゃないかと勝手に思っています。
問題ではDMZ内機器にグローバルIPが割り当てていると言っており、プライベートIPは割り当てているとは言っていない(割り当てていないとも言ってないけど)ので、おそらくルーティングする方を想定していると思いますが。
余談2
DNSサーバーやSMTPサーバーは、NAPT下にあっても動作可能ではあります。
53や25といった待ち受けるポートをポートフォワーディング設定する必要はあります。
ただ、IPアドレスが非常に限られた環境でなければ素直に専用のグローバルIPを割り当てることが多いとは思います。
そのため、プライベートIPを持っているPCや内部サーバーはインターネットに全く到達できません。
まず、先に述べられている通り、NATを用いなくても、プライベートIPとグローバルIPの間での通信は可能です。
プライベートIPというのはあくまでISP等でルーティングされないIPという意味しかないので、社内ネットワークで使う分にはグローバルIPと変わりありません。
そもそもプライベートIPとはグローバルIP用の領域の一部を後から内部用に予約したものです。
全く到達できないというとWeb等の閲覧はどうなっているのかと思われるかもしれませんが、HTTPとSMTPだけはプロキシサーバーなどが代行してくれるので可能なのです。
逆に、HTTPとSMTP以外で外に接続可能にしようとするためには新たなプロキシかNATかを導入する必要が出てきます。
PCが全てインターネットに繋がっていないというのは衝撃的かもしれませんが、組織ではしばしばある構成です。
余談
私も複数事例のネットワーク構成をよく知っているわけではないので、参考程度に
実際にグローバルIPとプライベートIPの間をNATせずルーティングするような構成をしている事例はあまりないと思います。
プロキシサーバー(やその他DMZにいるような機器)をプライベートIPだけのネットワークとグローバルIPだけのネットワークの両方に接続しているほうが一般的なんじゃないかと勝手に思っています。
問題ではDMZ内機器にグローバルIPが割り当てていると言っており、プライベートIPは割り当てているとは言っていない(割り当てていないとも言ってないけど)ので、おそらくルーティングする方を想定していると思いますが。
余談2
DNSサーバーやSMTPサーバーは、NAPT下にあっても動作可能ではあります。
53や25といった待ち受けるポートをポートフォワーディング設定する必要はあります。
ただ、IPアドレスが非常に限られた環境でなければ素直に専用のグローバルIPを割り当てることが多いとは思います。
2024.10.08 12:18
boyonboyonさん
(No.9)
自分はプロキシ経由のパケットの流れを下記のように理解しているのですが、どうでしょうか。
宛先:SC掲示板 IPアドレスをIP-SC
送信元:PC-LAN内のPC IPアドレスをIP-PC
で考えてみます。
PCから送信
宛先:IP-SC
送信元:IP-PC
プロキシまではこの状態で届く。(PCのプロキシ設定でこうなると思う。違っていたらご教授をお願い致します。)
プロキシで、送信元をプロキシのグローバルIPアドレスに変換
宛先:IP-SC
送信元:x1.y1.z1.5
インターネットへ出て行き、掲示板に届く。
掲示板からの戻り
宛先:x1.y1.z1.5
送信元:IP-SC
これがプロキシに届く。プロキシ内で宛先を送り元のIP-PCに変換
宛先:IP-PC
送信元:IP-SC
これが、送り元のPCに戻ってくる。
宛先:SC掲示板 IPアドレスをIP-SC
送信元:PC-LAN内のPC IPアドレスをIP-PC
で考えてみます。
PCから送信
宛先:IP-SC
送信元:IP-PC
プロキシまではこの状態で届く。(PCのプロキシ設定でこうなると思う。違っていたらご教授をお願い致します。)
プロキシで、送信元をプロキシのグローバルIPアドレスに変換
宛先:IP-SC
送信元:x1.y1.z1.5
インターネットへ出て行き、掲示板に届く。
掲示板からの戻り
宛先:x1.y1.z1.5
送信元:IP-SC
これがプロキシに届く。プロキシ内で宛先を送り元のIP-PCに変換
宛先:IP-PC
送信元:IP-SC
これが、送り元のPCに戻ってくる。
2024.10.08 18:20
いまいさんさん
(No.10)
FW・プロキシサーバ・NATの仕組みを誤解をされてるような気がします!
今回の問題、明記されていないので誤魔化しましたが、一般的なNW構成を想定するとこうなります。
①FWのWAN側ポートがGIPを取得します。
→構成図にルータがないから、プロバイダ情報を書き込めるのはFWくらいです。
②FWはNAT機能を使用しています。
→GIPは私達がデバイスに設定するものではなく、プロバイダから割り当てられるものです。FWのWAN側ポートに割り当てられてGIP宛のパケットは、NAT機能により宛先IPがローカルIPに変換され、DMZ内の機器に着信します。
③DMZ内機器は、FWのNAT機能を使って固定GIPが割り当てられています。
→これはDMZ内機器のLANポートにGIPが設定されているという意味ではないです。
問題のプロキシサーバを例にすると、インターネット側から宛先「x1.y1.z1.5」パケットは、プロキシサーバに着信するように宛先アドレスがFWでNAT変換されます。
このNAT設定のことを「固定のグローバルIPアドレスを割り当てている」と表現しています。
問題の構成において、NWの内部外部の境界はFWです。
FWを貫通して内部NWにGIPが割り当てられることは通常ありえないです。FWの意味がなくなってしまいます。(ただし絶対ないとは言いません!)
やろうと思えばそういったことも出来るかもしれませんが、
通常プロキシサーバのパケットの流れはそうではないです!
①PCから送信
宛先:IP-SC 送信元:IP-PC
プロキシまではこの状態で届く。
→あってます!
②プロキシで、送信元をプロキシのグローバルIPアドレスに変換
宛先:IP-SC
送信元:x1.y1.z1.5
→ここが違います!プロキシサーバが送信元を偽装するようなことはありません!
この変換はNATのことだと思いますが、NATは自身に割り当てられていないIPアドレスを設定することはありません。プロキシサーバがGIP持ってるじゃんって思うかもしれませんが、GIPを持ってるのはプロバイダ情報が書かれたルータかFWです。
boyonboyonさんが書かれてるパケットの流れにはルータが抜けています!
今回の問題、明記されていないので誤魔化しましたが、一般的なNW構成を想定するとこうなります。
①FWのWAN側ポートがGIPを取得します。
→構成図にルータがないから、プロバイダ情報を書き込めるのはFWくらいです。
②FWはNAT機能を使用しています。
→GIPは私達がデバイスに設定するものではなく、プロバイダから割り当てられるものです。FWのWAN側ポートに割り当てられてGIP宛のパケットは、NAT機能により宛先IPがローカルIPに変換され、DMZ内の機器に着信します。
③DMZ内機器は、FWのNAT機能を使って固定GIPが割り当てられています。
→これはDMZ内機器のLANポートにGIPが設定されているという意味ではないです。
問題のプロキシサーバを例にすると、インターネット側から宛先「x1.y1.z1.5」パケットは、プロキシサーバに着信するように宛先アドレスがFWでNAT変換されます。
このNAT設定のことを「固定のグローバルIPアドレスを割り当てている」と表現しています。
問題の構成において、NWの内部外部の境界はFWです。
FWを貫通して内部NWにGIPが割り当てられることは通常ありえないです。FWの意味がなくなってしまいます。(ただし絶対ないとは言いません!)
>boyonboyonさん
やろうと思えばそういったことも出来るかもしれませんが、
通常プロキシサーバのパケットの流れはそうではないです!
①PCから送信
宛先:IP-SC 送信元:IP-PC
プロキシまではこの状態で届く。
→あってます!
②プロキシで、送信元をプロキシのグローバルIPアドレスに変換
宛先:IP-SC
送信元:x1.y1.z1.5
→ここが違います!プロキシサーバが送信元を偽装するようなことはありません!
この変換はNATのことだと思いますが、NATは自身に割り当てられていないIPアドレスを設定することはありません。プロキシサーバがGIP持ってるじゃんって思うかもしれませんが、GIPを持ってるのはプロバイダ情報が書かれたルータかFWです。
boyonboyonさんが書かれてるパケットの流れにはルータが抜けています!
2024.10.08 22:13
いまいさんさん
(No.11)
すみません。。。。下記の部分念の為調べたら違いました。。。
①PCから送信
宛先:IP-SC 送信元:IP-PC
プロキシまではこの状態で届く。
→違いました。。。
宛先:プロキシサーバのIPアドレス
になるようです。
HTTPリクエストのヘッダー情報に、
GET xxxx://IP-SC/~~~
って書かれることで、プロキシサーバはSC掲示板に接続しにいくことができます。
①PCから送信
宛先:IP-SC 送信元:IP-PC
プロキシまではこの状態で届く。
→違いました。。。
宛先:プロキシサーバのIPアドレス
になるようです。
HTTPリクエストのヘッダー情報に、
GET xxxx://IP-SC/~~~
って書かれることで、プロキシサーバはSC掲示板に接続しにいくことができます。
2024.10.08 22:33
boyonboyonさん
(No.12)
>いまいさんさん
ご教授ありがとうございます。
教えていただいたことをふまえるとPCからの送信の流れは、
プロキシのIPアドレスを IP-PR とした場合
宛先:IP-PR (IP-SCは、HTTPリクエストのヘッダー情報に書かれる)
送信元:IP-PC
プロキシに到着、
・・・ここは推測ですが、ヘッダーから取り出したアドレスに変換して
宛先:IP-SC
送信元:IP-PR
FW通過するときに
宛先:IP-SC
送信元:x1.y1.z1.5
に変わる。
インターネットへ出て行き、掲示板に届く。
掲示板からの戻り
宛先:x1.y1.z1.5
送信元:IP-SC
FW通過で
宛先:IP-PR
送信元:IP-SC
これがプロキシに届く。プロキシ内で宛先を送り元のIP-PCに変換
宛先:IP-PC
送信元:IP-SC
のような流れでよいでしょうか。
2024.10.08 23:38
X8bWwさん
(No.13)
なんか、色んな人が違うことを言ってて混沌としてきましたね...
順番に反応していきます。
No.9
結論から言うと、Noです。
透過型プロキシの場合には、確かにそのような挙動になると思います。
しかし、問題のプロキシは明示型プロキシと思われます。(透過型プロキシに表2で述べられているようなCONNECTメソッドなんていう概念はないので)
この場合、以下のようになります。
宛先:www.sc-siken.com(IP-SC)
送信元:PC-LAN内のPC(IPアドレスをIP-PC)
PCから送信
宛先:x1.y1.z1.5
送信元:IP-PC
このようなIPヘッダで、プロキシに以下のようなリクエストが送られます。(上に乗っているのがHTTPS通信の場合です,HTTPの場合はちょっとややこしくなるので略)
CONNECT www.sc-siken.com:443
送信元PCはWebサーバーのIPすら知りません。
これを受けたプロキシは、 www.sc-siken.com をIP-SCに解決した後、以下のような通信を行います。
宛先:IP-SC
送信元:x1.y1.z1.5
帰りは逆をやるだけなので、略。
NATのようにIPの書き換えやらはしておらず、ただTCPの上で内容を中継しているだけの単純な作りです。
明示型プロキシをNATやルーティングといったものと同列に考えないでください。L2やL3ではなくL7です。
No.10
たしかにそうです。家庭環境においては。
問題の企業のように、固定IPな上に複数あるような場合は、プロバイダから割り当てられたアドレスをサーバーに手動設定するというのは珍しいことではありません。というかそれが割とスタンダードです。
No.10
これも、Noです。
ファイヤウォールの意味がなくなる道理がありません。おそらくNAPTによって副次的にもたらされる、ポートマッピング設定しないと外部からアクセスできなくなるという効果と混同しています。
そもそも以前はNATやプライベートIPなど使われず、すべてのPCにグローバルIPを割り当てていました。そして、そんな時代でもファイヤウォールという概念は存在しました。
今でも大学など昔からある組織はグローバルIPv4アドレスを潤沢に保有しているため、全デバイスにグローバルIPを配った上でファイヤウォールをかけていることも珍しくありません。(というかよくあります)
また現代にはIPv6がありますが、これは一般家庭においてもすべてのデバイスにグローバルユニークアドレスを割り当てるのがスタンダードであり、家庭用ルーターにはIPv6ファイヤウォール機能があります。
No.10
確かにそのような構成も可能です。
が、問題からそれを読み取るのは行間を読みすぎていると思います。
の記述からして、DMZ上のサーバーは直接グローバルIPアドレスを持っておりプライベートIPアドレスを持たないと解するのが妥当だと思います。
順番に反応していきます。
No.9
> 自分はプロキシ経由のパケットの流れを下記のように理解しているのですが、どうでしょうか。(以下略)
結論から言うと、Noです。
透過型プロキシの場合には、確かにそのような挙動になると思います。
しかし、問題のプロキシは明示型プロキシと思われます。(透過型プロキシに表2で述べられているようなCONNECTメソッドなんていう概念はないので)
この場合、以下のようになります。
宛先:www.sc-siken.com(IP-SC)
送信元:PC-LAN内のPC(IPアドレスをIP-PC)
PCから送信
宛先:x1.y1.z1.5
送信元:IP-PC
このようなIPヘッダで、プロキシに以下のようなリクエストが送られます。(上に乗っているのがHTTPS通信の場合です,HTTPの場合はちょっとややこしくなるので略)
CONNECT www.sc-siken.com:443
送信元PCはWebサーバーのIPすら知りません。
これを受けたプロキシは、 www.sc-siken.com をIP-SCに解決した後、以下のような通信を行います。
宛先:IP-SC
送信元:x1.y1.z1.5
帰りは逆をやるだけなので、略。
NATのようにIPの書き換えやらはしておらず、ただTCPの上で内容を中継しているだけの単純な作りです。
明示型プロキシをNATやルーティングといったものと同列に考えないでください。L2やL3ではなくL7です。
No.10
> GIPは私達がデバイスに設定するものではなく、プロバイダから割り当てられるものです。
たしかにそうです。家庭環境においては。
問題の企業のように、固定IPな上に複数あるような場合は、プロバイダから割り当てられたアドレスをサーバーに手動設定するというのは珍しいことではありません。というかそれが割とスタンダードです。
No.10
> FWを貫通して内部NWにGIPが割り当てられることは通常ありえないです。FWの意味がなくなってしまいます。(ただし絶対ないとは言いません!)
これも、Noです。
ファイヤウォールの意味がなくなる道理がありません。おそらくNAPTによって副次的にもたらされる、ポートマッピング設定しないと外部からアクセスできなくなるという効果と混同しています。
そもそも以前はNATやプライベートIPなど使われず、すべてのPCにグローバルIPを割り当てていました。そして、そんな時代でもファイヤウォールという概念は存在しました。
今でも大学など昔からある組織はグローバルIPv4アドレスを潤沢に保有しているため、全デバイスにグローバルIPを配った上でファイヤウォールをかけていることも珍しくありません。(というかよくあります)
また現代にはIPv6がありますが、これは一般家庭においてもすべてのデバイスにグローバルユニークアドレスを割り当てるのがスタンダードであり、家庭用ルーターにはIPv6ファイヤウォール機能があります。
No.10
> 問題のプロキシサーバを例にすると、インターネット側から宛先「x1.y1.z1.5」パケットは、プロキシサーバに着信するように宛先アドレスがFWでNAT変換されます。
> このNAT設定のことを「固定のグローバルIPアドレスを割り当てている」と表現しています。
確かにそのような構成も可能です。
が、問題からそれを読み取るのは行間を読みすぎていると思います。
> PC及び内部システムLANのサーバーには,固定のプライベートIPアドレスを割り当てている。
> DMZ上のサーバには,固定のグローバルIPアドレスを割り当てている。
の記述からして、DMZ上のサーバーは直接グローバルIPアドレスを持っておりプライベートIPアドレスを持たないと解するのが妥当だと思います。
2024.10.08 23:58
X8bWwさん
(No.14)
おっと、書いてる間に新しい投稿が増えていました。
被った部分は適当に読み飛ばしてください...
被った部分は適当に読み飛ばしてください...
2024.10.08 23:59
いまいさんさん
(No.15)
>boyonboyonさん
間違えないです!!
私がNo7のコメントで「NAPTやNATを理解することと、今回の問題を理解するはいったん切り離した方がいい」と書いたのは、
今回の問題は、NATによるアドレスの変換を考えなくても解けるようになっていると思ったからです。(問1-2がIPアドレスではなくサーバ名で答えるようになっていたり)
誤解をさせてしまった気がしているので改めて説明させて下さい!
・FWのNATに関する設定について明記されてない
→明記されていないからNATが使われていない…と考えるのは無理筋だと思っています。
一般的にFWを導入して固定IPを割り当てる場合、NATを使います!
(X8bWwさんには誤解させてしまった気がしてます…!すみません!!)
(問題作成者様に怒られそうですが…)
FW設定について学ぶという点ではいい問題ですが、
NWうんぬんを理解するという点では、マジで良くない問題だと思います!
ほかの問題を参考にしたほうがいいです!
2024.10.08 23:59
X8bWwさん
(No.16)
No.13
ここだけもうちょっとわかりやすく郵便物っぽく説明すると、
NATは「封筒の宛先や送り主の部分をちょっと書き換えて中継する」
プロキシは「封筒を開けて中身を取り出してから全く新しい封筒に入れて送り直す」
というレベルで違います。
TCPのストリームレベルでやっているので、1封筒あたりの枚数(パケットサイズ)とかも変わったりしますし、なんなら暗号化されていないHTTPの場合は中の文書にまで手を加えられたり(キャッシングやヘッダー追加)します。
> 明示型プロキシをNATやルーティングといったものと同列に考えないでください。L2やL3ではなくL7です。
ここだけもうちょっとわかりやすく郵便物っぽく説明すると、
NATは「封筒の宛先や送り主の部分をちょっと書き換えて中継する」
プロキシは「封筒を開けて中身を取り出してから全く新しい封筒に入れて送り直す」
というレベルで違います。
TCPのストリームレベルでやっているので、1封筒あたりの枚数(パケットサイズ)とかも変わったりしますし、なんなら暗号化されていないHTTPの場合は中の文書にまで手を加えられたり(キャッシングやヘッダー追加)します。
2024.10.09 00:10
いまいさんさん
(No.17)
失礼しました・・・!
私はPPPoE接続でしか考えてませんでした。
問題だとデータセンタとあるので、
X8bWwさんのおっしゃている構成が正解かと思います!
私はPPPoE接続でしか考えてませんでした。
問題だとデータセンタとあるので、
X8bWwさんのおっしゃている構成が正解かと思います!
2024.10.09 00:41
boyonboyonさん
(No.18)
>X8bWwさん
ご教授ありがとうございます。
透過型と明示型について調べてみました。
No.9で私が示したのは、透過型に近いですね。
明示型についても調べてみて、X8bWwさんのおっしゃっていることが分かりました。
ご教授いただいたこと、調べたことを整理してまとめてみました。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
目的:PC-LAN内のPCから、www.sc-siken.com (IPアドレスは、IP-SC)にHTTPSでアクセスしたい
PCからプロキシ
宛先:x1.y1.z1.5
送信元:IP-PC
3wayハンドシェイクをしてTCPコネクションができる。
【CONNECT www.sc-siken.com:443】を送る。
「www.sc-siken.comにアクセスしたいのでよろしく。」
プロキシからSCドットコム
www.sc-siken.comの名前解決処理をしてIP-SCを入手
宛先:IP-SC
送信元:x1.y1.z1.5
3wayハンドシェイクをしてTCPコネクションができる。
プロキシからPC
【Connection Established】を送る。
「コネクションができたから通信できるよ。」
できあがったコネクションの上で、PCとSCドットコムが、TLS通信を行う。
***TCPコネクションが2つできる。プロキシは中継するだけで、TLSには関与しない。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
こんな感じになりました。
あと、調べていて気になったことがあります。
この問題ではプロキシのIPアドレスは1つだけですが、
調べた中には、内部用と外部用の2つのIPアドレスを持っているものがありました。
実際にはどちらがよく使われるのか気になりました。
2024.10.09 18:44
X8bWwさん
(No.19)
No.18
それで完璧だと思います。
No.18
No.8余談で多少言及しています。
もっと語りたいところではありますが、これ以上はさすがにスレッドの本題から離れすぎるのでやめておきます。
> ご教授いただいたこと、調べたことを整理してまとめてみました。(以下略)
それで完璧だと思います。
No.18
> この問題ではプロキシのIPアドレスは1つだけですが、
> 調べた中には、内部用と外部用の2つのIPアドレスを持っているものがありました。
> 実際にはどちらがよく使われるのか気になりました。
No.8余談で多少言及しています。
もっと語りたいところではありますが、これ以上はさすがにスレッドの本題から離れすぎるのでやめておきます。
2024.10.10 13:39
boyonboyonさん
(No.20)
>X8bWwさん、いまいさんさん
いろいろ教えていただきありがとうございました。
プロキシについての理解が深まりました。
>スレ主様
提起された疑問から、逸脱してしまい申し訳ありません。
プロキシでの通信の流れについて、理解が深まったということでご容赦ください。
2024.10.10 15:45
広告
返信投稿用フォーム
投稿記事削除用フォーム
広告