トップに関する質問プロキシー接続による異なるネットワーク間のルーティングができない

編集履歴

質問編集履歴

字数制限による、新たな投稿

2018/09/07 11:52

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -568,21 +568,11 @@
-```
-エラーメッセージ
-```
-### 該当のソースコード
-### 試したこと
+### 続き
+字数制限のため、[新たな投稿](https://teratail.com/questions/145425)をしました。
 ### 補足情報（FW/ツールのバージョンなど）

eth1のipがdhcp再リースで変更されたこと。

2018/09/07 11:52

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -232,7 +232,7 @@
 ```
-root@raspberrypi:/etc# ip route
+root@raspberrypi:/# ip route
 default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 202
@@ -360,8 +360,12 @@
 やっていることは、「特定ユーザのip route変更」です。squidのユーザーであるproxyのip route変更のため、このサイトを参考にし、
+(当該記事は、異なるnicの切り替えでなく、単純な同一ネットワーク内でのgw変更である)
 http://d.hatena.ne.jp/rti7743/20150320/1426880601
 以下の操作をしました。
@@ -372,7 +376,7 @@
-#再起動で各nicのipが変動するための取得方法
+#再起動で各nicのipが再dhcpリースにより変動するための自動的な取得方法
 #https://askubuntu.com/questions/430853/how-do-i-find-my-internal-ip-address
@@ -522,8 +526,6 @@
 ```
@@ -540,6 +542,10 @@
+proxygwのルーティングテーブルは理解していますが、iptablesのmangleはまだ正しく理解していないところです。
 ###事前調査について

rpi再インストールで、squid + iptables でsub-gwへの転送ができなくなった。

2018/07/16 16:46

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -350,6 +350,196 @@
+## 発生している問題・エラーメッセージ)(その3)
+rpiが起動しなくなり、再インストールしてから、squid + iptables で同様の設定までしたところ、何故かsub-gwへの転送ができなくなってしまいました。
+やっていることは、「特定ユーザのip route変更」です。squidのユーザーであるproxyのip route変更のため、このサイトを参考にし、
+http://d.hatena.ne.jp/rti7743/20150320/1426880601
+以下の操作をしました。
+squidユーザのルーティングテーブル変更コード
+```
+#再起動で各nicのipが変動するための取得方法
+#https://askubuntu.com/questions/430853/how-do-i-find-my-internal-ip-address
+eth0_ip=$(ip addr show eth0 |grep -v inet6 | awk '/inet/ {print $2}' | cut -d/ -f1) &&
+eth1_ip=$(ip addr show eth1 |grep -v inet6 | awk '/inet/ {print $2}' | cut -d/ -f1)
+proxy_route_tbl=proxygw &&
+proxy_route_tbl_number=201 &&
+echo 1 > /proc/sys/net/ipv4/ip_forward &&
+echo "$proxy_route_tbl_number $proxy_route_tbl" >> /etc/iproute2/rt_tables &&
+ip rule  add fwmark 1 table $proxy_route_tbl &&
+ip route add table $proxy_route_tbl default via 192.168.0.1 dev eth0 src $eth0_ip metric 203 &&
+ip route add table $proxy_route_tbl default via 192.168.1.1 dev eth1 src $eth1_ip metric 202 &&
+ip route add table $proxy_route_tbl 192.168.0.0/24 dev eth0 proto kernel scope link src $eth0_ip metric 203 &&
+ip route add table $proxy_route_tbl 192.168.1.0/24 dev eth1 proto kernel scope link src $eth1_ip metric 202 &&
+iptables -t mangle -P OUTPUT ACCEPT &&
+iptables -t mangle -A OUTPUT -m owner --uid-owner proxy -j MARK --set-mark 1
+# ip route,iptables 初期化用
+ip rule  del fwmark 1 table $proxy_route_tbl &&
+ip route del table $proxy_route_tbl default via 192.168.0.1 dev eth0 src $eth0_ip metric 203 &&
+ip route del table $proxy_route_tbl default via 192.168.1.1 dev eth1 src $eth1_ip metric 202 &&
+ip route del table $proxy_route_tbl 192.168.0.0/24 dev eth0 proto kernel scope link src $eth0_ip metric 203 &&
+ip route del table $proxy_route_tbl 192.168.1.0/24 dev eth1 proto kernel scope link src $eth1_ip metric 202 &&
+iptables -F &&
+iptables -F -t mangle
+```
+また、変更後のip route,iptablesの設定は、
+ip routeの変更後の設定
+```
+root@raspberrypi:/# ip route show table main
+default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 202
+default via 192.168.1.1 dev eth1 src 192.168.1.5 metric 203
+192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 202
+192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5 metric 203
+root@raspberrypi:/# ip route show table proxygw
+default via 192.168.1.1 dev eth1 src 192.168.1.5 metric 202
+default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 203
+192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 203
+192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5 metric 202
+```
+iptablesの変更後の設定
+```
+root@raspberrypi:/# iptables -L
+Chain INPUT (policy ACCEPT)
+target     prot opt source               destination
+Chain FORWARD (policy ACCEPT)
+target     prot opt source               destination
+Chain OUTPUT (policy ACCEPT)
+target     prot opt source               destination
+root@raspberrypi:/# iptables -L -t mangle
+Chain PREROUTING (policy ACCEPT)
+target     prot opt source               destination
+Chain INPUT (policy ACCEPT)
+target     prot opt source               destination
+Chain FORWARD (policy ACCEPT)
+target     prot opt source               destination
+Chain OUTPUT (policy ACCEPT)
+target     prot opt source               destination
+MARK       all  --  anywhere             anywhere             owner UID match proxy MARK set 0x1
+Chain POSTROUTING (policy ACCEPT)
+target     prot opt source               destination
+```
+また、rpi側から見たtcpdumpの結果としては、
+client-rpi間は、普通に (eth0のip):3128 への通信
+rpi-通信先サーバ間は、例えば1.1.1.1宛にすると、
+物理nicがeth1でのdumpなのに、srcipがeth0のipとなり、
+サーバからの応答を受信できません。
 ###事前調査について

あ

2018/07/16 16:42

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -364,7 +364,11 @@
-また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。(普段のネット接続と別の通信にしたいなどの要望は多く、vpnでの対応が多いが、望ましくない。)
+また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。
+普段のネット接続と別の通信にしたいなどの要望は多く、ip routeやvpnでの対応が多いが、設定を大幅に変更してしまい、普段のネットワーク環境を破壊する恐れがあるので、簡単な操作・変更で済みそうなプロキシーにより実現できると良い。

事前調査について

2018/07/15 15:52

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -348,6 +348,12 @@
+###事前調査について
 よく「linuxルータを作ろう」などという記事があり、
 異なるネットワーク間の通信を異なるnicでクリアしていますが、
@@ -358,6 +364,8 @@
+また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。(普段のネット接続と別の通信にしたいなどの要望は多く、vpnでの対応が多いが、望ましくない。)
 ```

誤字脱字

2018/07/15 15:49

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -262,7 +262,7 @@
 client-pcがrpi-eth0 (192.168.0.3:3218)を宛先とする通信しかしない
-(client pcからwirsharkで確認)ので、
+(client-pcからwiresharkで確認)ので、
 squidで処理したあとの通信をどうにかしてsubnet-Bに向ける事が重要です。

ツールのバージョンの追加

2018/07/15 15:46

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -16,10 +16,6 @@
 今、以下のようなネットワーク構成であるとする。
-(左側のaはスペースを反映させるための装飾で、特に意味はない。
-また、モバイル版では図が崩れて表示されます。)
 ```
@@ -50,11 +46,11 @@
-client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
+client-pc : ubuntu 18.04 (client-pcは今後増える可能性あり)
-rpi: raspberry pi stretch
+rpi : raspberry pi stretch
-main-gw,sub-gw:市販のルータで、dhcpサーバ機能を持つ
+main-gw,sub-gw : 市販のルータで、dhcpサーバ機能を持つ
@@ -383,3 +379,7 @@
 ### 補足情報（FW/ツールのバージョンなど）
 dante 1.52.10.2
+iptables v1.6.0
+squid3-3.5.23

ネットワーク構成図の修正その2

2018/07/15 15:35

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -1,5 +1,3 @@
-```
 ## 注意点
@@ -24,6 +22,8 @@
+```
 (subnet-A : 192.168.0.0/24)
 clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
@@ -46,6 +46,8 @@
 (subnet-B : 192.168.1.0/24)
+```
 client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
@@ -381,5 +383,3 @@
 ### 補足情報（FW/ツールのバージョンなど）
 dante 1.52.10.2
-```

ネットワーク構成図の修正

2018/07/15 15:30

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -1,3 +1,5 @@
+```
 ## 注意点
@@ -26,21 +28,21 @@
 clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
-a　　　　　　　    |
+      　　　　　　    　    |
-a　　　　　　　    |
+      　　　　　　    　    |
-a　　　　　　　    |
+      　　　　　　    　    |
-a                             rpi-eth0 (192.168.0.3)
+                       rpi-eth0 (192.168.0.3)
-a                               |  (rpi内部)
+                         |  (rpi内部)
-a                             rpi-eth1 (192.168.1.3)
+                       rpi-eth1 (192.168.1.3)
-a                               |
+                         |
-a                              sub-gw (192.168.1.1)ーwan2
+                       sub-gw (192.168.1.1)ーwan2
 (subnet-B : 192.168.1.0/24)
@@ -379,3 +381,5 @@
 ### 補足情報（FW/ツールのバージョンなど）
 dante 1.52.10.2
+```

あ

2018/07/15 15:28

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -1,4 +1,4 @@
-### 注意点
+## 注意点
@@ -8,7 +8,7 @@
-### 前提・実現したいこと
+##前提・実現したいこと
@@ -16,7 +16,9 @@
 今、以下のようなネットワーク構成であるとする。
-(左側のaはスペースを反映させるための装飾で、特に意味はない)
+(左側のaはスペースを反映させるための装飾で、特に意味はない。
+また、モバイル版では図が崩れて表示されます。)
@@ -86,7 +88,7 @@
-### 発生している問題・エラーメッセージ(その1)
+## 発生している問題・エラーメッセージ(その1)
 danteについて
@@ -178,11 +180,11 @@
-まず、client-pcからのsocks proxy接続の結果について、
+####client-pcからのsocks proxy接続の結果について、
-すると、sub-gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
+sub-gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
 subnet-B(eth1を経由とは書かない)を経由しているが、
@@ -212,7 +214,7 @@
-次に、proxy server本体となるrpiを送信元とする結果について
+####proxy server本体となるrpiを送信元とする結果について
@@ -244,9 +246,11 @@
-### 発生している問題・エラーメッセージ(というより、方法を模索中)(その2)
+## 発生している問題・エラーメッセージ(というより、方法を模索中)(その2)
-squid + iptablesについて
+###squid + iptablesについて
@@ -264,7 +268,7 @@
-次に、中継プロキシ-通信先サーバの間の通信について
+####中継プロキシ-通信先サーバの間の通信について
@@ -344,6 +348,16 @@
+よく「linuxルータを作ろう」などという記事があり、
+異なるネットワーク間の通信を異なるnicでクリアしていますが、
+今回はrpiをgwとする通常のルータの利用方法とは違うので、
+それらの記事を参考にして、目標を達成することはできません。
 ```

ネットワークの質問なのに、説明不足と致命的なミス、さらに説明の流れがなっていないので、修正

2018/07/15 10:26

投稿

minsuke54

スコア4

test CHANGED Viewed

	@@ -1 +1 @@
1	- ~~squid + iptables , dante socks等を利用した~~プロキシー接続による異なる~~nic or~~ ネットワーク~~セグメント~~間のルーティングについて
1	+ プロキシー接続による異なるネットワーク間のルーティングができない

test CHANGED Viewed

@@ -1,18 +1,28 @@
+### 注意点
+この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
+ご了承ください。
 ### 前提・実現したいこと
-(書いている途中ですが、何個か試したので、随時追加で投稿します。)
-2つの回線があり、メインの回線とは別に、特定の操作をした時にサブ回線を通るようにしたい。
+2つの回線があり、メインの回線とは別に、特定の操作をした時に通信がサブ回線を経由するようにしたい。
+今、以下のようなネットワーク構成であるとする。
-今、以下のようなネットワーク構成であるとする。(左側のaはスペースを反映させるための装飾で、特に意味はない)
+(左側のaはスペースを反映させるための装飾で、特に意味はない)
-(subnet A)
+(subnet-A : 192.168.0.0/24)
-pc(192.168.0.2)--main gw(192.168.0.1)--wan1
+clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
 a　　　　　　　    |
@@ -20,39 +30,59 @@
 a　　　　　　　    |
-a                             rpi eth0(192.168.0.3)
+a                             rpi-eth0 (192.168.0.3)
-a                               |(rpi内部)
+a                               |  (rpi内部)
-a                             rpi eth1(192.168.1.3)
+a                             rpi-eth1 (192.168.1.3)
-a                                |
+a                               |
-a                              sub gw(192.168.0.1)--wan2
+a                              sub-gw (192.168.1.1)ーwan2
-(subnet B)
+(subnet-B : 192.168.1.0/24)
+client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
+rpi: raspberry pi stretch
+main-gw,sub-gw:市販のルータで、dhcpサーバ機能を持つ
+rpiには、lanケーブルとusb-lanアダプタの2つのnicがついており、それぞれeth0,eth1である。また、ip割当は各ルータのdhcp機能により行った。rpiがルータの役割をする事はない。
-特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
+特定の操作をしたときに、client-pcの通信がsub-gwを経由してwan2を利用できればよいので、
-どんな方法でも良いが、client pcのip routeの変更やvpn設定はしたくない。
+どんな方法でも良いが、client-pcのip routeの変更やvpn設定はしたくない。
-あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
+プログラムの通信を経由させる事を考えると、プログラム上でも人間でも簡単な操作により、wan2が利用できることが望ましいので、方法はプロキシあたりになると思います。
-大きな変更はプロキシとなるrpiに対して行うものとする。
+そして、大きな変更はプロキシとなるrpiに対して行うものとして、
-(プログラムの通信も通すことを考えて)
+client機器には負担をかけたくない。
-自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
+自分が考えている方法は、rpi-eth0にプロキシ接続をして、ルーティングされる方法です。
-やった方法は、「squid + iptables」 or 「dante socks proxy」でした。
+やった方法は、 「dante socks proxy」で、
+途中で諦めて、再び試しているのは、「squid + iptables」です。
-できなかったので、経緯を詳しく書きます。
+できていないので、経緯を詳しく書きます。
-使用したツールについての動作や概念を正しく理解している自身はありません。
+使用したツールについての動作や概念を正しく理解している自信がないため、
+自分の理解を提示しつつ、説明を書いていきます。
@@ -62,6 +92,262 @@
 ```
+・subnet-B宛の通信はeth1を経由するが、それ以外はeth0経由となる。
+```
+### 該当のソースコード
+「danted.conf」の設定
+・入口と出口のnicを別々にした
+・カーネルパニック対策にローカルアドレスに対しても、client passを設定した。(https://qiita.com/hirohiro77/items/087c4d9e6b03050f70ad)
+```
+# $Id: sockd.conf,v 1.52.10.2 2014/09/03 14:49:13 michaels Exp $
+logoutput: syslog stdout /var/log/sockd.log
+debug: 1
+internal: eth0 port = 1080
+external: eth1
+socksmethod: none
+clientmethod: none
+user.privileged: root
+user.unprivileged: nobody
+timeout.connect: 30
+client pass {
+from: 192.168.0.0/24 port 1-65535 to: 0.0.0.0/0
+}
+client pass {
+        from: 127.0.0.1/32 port 1-65535 to: 0.0.0.0/0
+}
+socks pass {
+        from: 192.168.0.0/24 to: 0.0.0.0/0
+}
+```
+### 試したこと
+まず、firefoxのプロキシ設定を
+protocol version : socks_v4 or v5
+proxy server:eth0のipアドレス
+に設定した。
+また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにしたつもり。
+まず、client-pcからのsocks proxy接続の結果について、
+すると、sub-gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
+subnet-B(eth1を経由とは書かない)を経由しているが、
+1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
+subnet-Aを経由しています。
+tcpdumpで確認すると、
+subnet-B宛は、tcpdump -i eth1 で確認できるが、
+1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
+つまり、danteの設定において、
+宛先がsubnet-B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、応答パケット受信できないです。
+この意味は、danteの設定において、interanlとexternalが異なる事は、
+送信先ネットワークセグメントの違いとは限らない、ということなので、
+セグメント分けには利用できないです。
+次に、proxy server本体となるrpiを送信元とする結果について
+rpiにssh loginしてpingすると、
+subnet-B宛はeth1を通るが、
+それ以外はeth0を経由しており、
+宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付けた)
+danteなら異なるnic間の転送ができると期待しましたが、異なるネットワークセグメント間の転送はできないようです。
+```
+root@raspberrypi:/etc# ip route
+default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 202
+default via 192.168.1.1 dev eth1 src 192.168.1.3 metric 203
+192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 202
+192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 203
+```
+### 発生している問題・エラーメッセージ(というより、方法を模索中)(その2)
+squid + iptablesについて
+次に考えたことは、rpiにsquidを立て、client-pcからsquidに対する通信をiptablesによりsubnet-Bへルーティングする事です。http/httpsプロキシの挙動については知らないので、自分の理解を示しながら説明していきます。
+http/httpsプロキシだと、本来の通信先サーバがどこでも、
+client-pcがrpi-eth0 (192.168.0.3:3218)を宛先とする通信しかしない
+(client pcからwirsharkで確認)ので、
+squidで処理したあとの通信をどうにかしてsubnet-Bに向ける事が重要です。
+次に、中継プロキシ-通信先サーバの間の通信について
+http/httpsのproxy接続では、中継プロキシ-通信先サーバの間の通信は、
+メインの通信内容(layer5以上？)はclient-pcのもの、
+tcpヘッダまでは中継プロキシのものになる。
+よって、実質的には、中継プロキシであるrpiを発信元とする通信とみなして問題を考えれば良い。
+そこで、このサイトの
+https://www.virment.com/iptables-outline/
+「各チェインがどのパケットを対象とするかを表したイメージ図」を参考にすると、
+「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
+そして、これらの説明には、
+引用文:
+「
+OUTPUTとPOSTROUTINGの違い
+OUTPUTはローカルプロセスに処理されて出力されたパケット、すなわち送信元がホストマシンであるパケットを対象としているのに対し、POSTROUTINGは送信元がホストマシンであるとは限りません。例えば、FORWARDによって転送されたパケットも対象となります。
+」
+とあり、今回はrpi本体からの通信とみなして良いので、
+説明文中の「ホストマシン」だけを考えており、実質的には、「OUTPUT」だけを考えれば良いです。
+しかし、これでは、iptablesから見た時に、
+src ipはrpi本体、src portはランダムなため、
+squidからの通信かどうか判別不能です。
+さらに、iptablesのsubnet-Bへの転送設定を弄ろうとしているので、
+OUTPUTで変な設定をすると、
+rpiへのssh accessも含め、全てsubnet Bへ転送されて、
+ssh切断の危険性もあります。
+となると、iptablesをやめて、squidの設定に、
+client-pcからのsquid宛はsubnet-Bへ転送させる設定をする必要があります。
+そのような設定があるか探しましたが、転送先を変更する方法として、「tcp_outgoing_address」というものがありましたが、
+転送先nicではなく宛先ipが変更されるため、
+通信先サーバへのアクセスができないです。
+転送先nicとネットワークセグメントをうまく処理するツールがないため、
+どうしようもありません。
+自分でツール開発できるスキルはありません。
+```
 エラーメッセージ
 ```
@@ -72,196 +358,10 @@
-「danted.conf」の設定
-・入口と出口のnicを別々にした
-・カーネルパニック対策にローカルアドレスに対しても、client passを設定した。(https://qiita.com/hirohiro77/items/087c4d9e6b03050f70ad)
-```
-# $Id: sockd.conf,v 1.52.10.2 2014/09/03 14:49:13 michaels Exp $
-logoutput: syslog stdout /var/log/sockd.log
-debug: 1
-internal: eth0 port = 1080
-external: eth1
-socksmethod: none
-clientmethod: none
-user.privileged: root
-user.unprivileged: nobody
-timeout.connect: 30
-client pass {
-from: 192.168.0.0/24 port 1-65535 to: 0.0.0.0/0
-}
-client pass {
-        from: 127.0.0.1/32 port 1-65535 to: 0.0.0.0/0
-}
-socks pass {
-        from: 192.168.0.0/24 to: 0.0.0.0/0
-}
-```
 ### 試したこと
-まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定した。
-また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにした。
-すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
-subnet B(eth1を経由とは書かない)を経由しているが、
-1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
-subnet Aを経由しています。
-tcpdumpで確認すると、
-subnet B宛は、tcpdump -i eth1 で確認できるが、
-1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
-つまり、danteの設定において、
-宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、応答パケット受信できないです。
-そして、interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
-また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
-それ以外はeth0を経由しており、
-宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付けた)
-danteなら異なるnic間の転送ができると期待しましたが。
-```
-root@raspberrypi:/etc# ip route
-default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 202
-default via 192.168.1.1 dev eth1 src 192.168.1.3 metric 203
-192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 202
-192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 203
-```
-### 発生している問題・エラーメッセージ(その2)
-squid + iptablesについて、
-次に考えたことは、rpiにsquidを立て、client pcからsquidに対する通信をiptablesによりsubnet Bへルーティングする事です。
-http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしない(client pcからwirsharkで確認)ので、squidで処理したあとの通信をどう扱うかが重要です。
-特に、このサイトの
-https://www.virment.com/iptables-outline/
-「各チェインがどのパケットを対象とするかを表したイメージ図」を参考にすると、
-「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
-そして、これらの説明には、
-引用文:
-「
-OUTPUTとPOSTROUTINGの違い
-OUTPUTはローカルプロセスに処理されて出力されたパケット、すなわち送信元がホストマシンであるパケットを対象としているのに対し、POSTROUTINGは送信元がホストマシンであるとは限りません。例えば、FORWARDによって転送されたパケットも対象となります。
-」
-とあり、実質的には、「OUTPUT」だけを考えれば良いです。
-そして、http/https接続では、中継プロキシ-通信先サーバの間の通信は、
-tcpヘッダまでは中継プロキシのものになるので、
-iptablesから見た時に、src ip,portによりsquidからの通信かどうか判別不能です。
-だから、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bへ転送されて、ssh切断の危険性もあります。
-となると、squidの設定に、squid宛はsubnet Bへ転送させる設定をすることになりますが、tcp_outgoing_addressを設定すると、転送先nicが変更されるのではなく、宛先ipが変更されており、通信先サーバへのアクセスができないです。
-転送先nicとネットワークセグメントをうまく処理するツールがないため、
-どうしようもありません。
-自分でツール開発できるスキルはありません。
-```
-エラーメッセージ
-```
-### 該当のソースコード
-### 試したこと
 ### 補足情報（FW/ツールのバージョンなど）
 dante 1.52.10.2

タグ追加

2018/07/15 10:16

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

File without changes

あ

2018/07/15 07:19

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -36,7 +36,7 @@
 特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
-どんな方法でも良いが、client pcのip routeの変更はしたくない。
+どんな方法でも良いが、client pcのip routeの変更やvpn設定はしたくない。
 あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
@@ -76,7 +76,7 @@
-・入り口と出口のポートを別々にした
+・入口と出口のnicを別々にした
 ・カーネルパニック対策にローカルアドレスに対しても、client passを設定した。(https://qiita.com/hirohiro77/items/087c4d9e6b03050f70ad)

iptables squidではできないこと

2018/07/15 07:16

投稿

minsuke54

スコア4

test CHANGED Viewed

	@@ -1 +1 @@
1	- squid+iptables , dante socks等~~による~~プロキシー接続による異なるnic or ネットワークセグメント間のルーティング
1	+ squid + iptables , dante socks等を利用したプロキシー接続による異なるnic or ネットワークセグメント間のルーティングについて

test CHANGED Viewed

@@ -52,7 +52,7 @@
 できなかったので、経緯を詳しく書きます。
+使用したツールについての動作や概念を正しく理解している自身はありません。
@@ -190,13 +190,15 @@
-http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしないので、squidで処理したあとの通信をどう扱うかが重要です。
+http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしない(client pcからwirsharkで確認)ので、squidで処理したあとの通信をどう扱うかが重要です。
 特に、このサイトの
 https://www.virment.com/iptables-outline/
-「各チェインがどのパケットを対象とするかを表したイメージ図」に参考にすると、
+「各チェインがどのパケットを対象とするかを表したイメージ図」を参考にすると、
 「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
@@ -216,9 +218,17 @@
 」
+とあり、実質的には、「OUTPUT」だけを考えれば良いです。
-とあり、http/https接続では、中継プロキシ-通信先サーバの間の通信は、tcpヘッダまでは中継プロキシのものになるので、squidによる通信か判別不能です。
+そして、http/https接続では、中継プロキシ-通信先サーバの間の通信は、
+tcpヘッダまでは中継プロキシのものになるので、
+iptablesから見た時に、src ip,portによりsquidからの通信かどうか判別不能です。
-だから、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bからやる必要が出る可能性もあります。
+だから、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bへ転送されて、ssh切断の危険性もあります。
@@ -226,8 +236,14 @@
+転送先nicとネットワークセグメントをうまく処理するツールがないため、
 どうしようもありません。
+自分でツール開発できるスキルはありません。
 ```

iptables or squidの設定ではどうにもできない

2018/07/15 07:11

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -182,9 +182,51 @@
 ### 発生している問題・エラーメッセージ(その2)
-squid + iptables
+squid + iptablesについて、
+次に考えたことは、rpiにsquidを立て、client pcからsquidに対する通信をiptablesによりsubnet Bへルーティングする事です。
+http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしないので、squidで処理したあとの通信をどう扱うかが重要です。
+特に、このサイトの
+https://www.virment.com/iptables-outline/
+「各チェインがどのパケットを対象とするかを表したイメージ図」に参考にすると、
+「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
+そして、これらの説明には、
+引用文:
+「
+OUTPUTとPOSTROUTINGの違い
+OUTPUTはローカルプロセスに処理されて出力されたパケット、すなわち送信元がホストマシンであるパケットを対象としているのに対し、POSTROUTINGは送信元がホストマシンであるとは限りません。例えば、FORWARDによって転送されたパケットも対象となります。
+」
+とあり、http/https接続では、中継プロキシ-通信先サーバの間の通信は、tcpヘッダまでは中継プロキシのものになるので、squidによる通信か判別不能です。
+だから、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bからやる必要が出る可能性もあります。
+となると、squidの設定に、squid宛はsubnet Bへ転送させる設定をすることになりますが、tcp_outgoing_addressを設定すると、転送先nicが変更されるのではなく、宛先ipが変更されており、通信先サーバへのアクセスができないです。
+どうしようもありません。

あ

2018/07/15 07:05

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -128,9 +128,9 @@
 ### 試したこと
-まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定し、
+まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定した。
-eth0からeth1に流れるように、danted.confを設定した。
+また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにした。
 すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
@@ -138,7 +138,9 @@
 1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
-eth0を経由しています。
+subnet Aを経由しています。
 tcpdumpで確認すると、
@@ -148,9 +150,9 @@
 つまり、danteの設定において、
-宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、
+宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、応答パケット受信できないです。
-interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
+そして、interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
 また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、

danteがnic設定が宛先ネットワークセグメントを選択できない事

2018/07/15 06:53

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -72,7 +72,17 @@
-```danted.conf
+「danted.conf」の設定
+・入り口と出口のポートを別々にした
+・カーネルパニック対策にローカルアドレスに対しても、client passを設定した。(https://qiita.com/hirohiro77/items/087c4d9e6b03050f70ad)
+```
 # $Id: sockd.conf,v 1.52.10.2 2014/09/03 14:49:13 michaels Exp $
@@ -124,15 +134,31 @@
 すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
-eth1を経由しているが、
+subnet B(eth1を経由とは書かない)を経由しているが、
 1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
+eth0を経由しています。
+tcpdumpで確認すると、
-eth0を経由しています。これらはrpi上でのtcpdumpでも確認済みです。
+subnet B宛は、tcpdump -i eth1 で確認できるが、
+1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
+つまり、danteの設定において、
+宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、
+interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
 また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
+それ以外はeth0を経由しており、
-それ以外はeth0を経由しており、danteの設定以前にosのルーティングテーブルが優先されているようです。danteなら異なるnic間の転送ができると期待しましたが。
+宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付けた)
+danteなら異なるnic間の転送ができると期待しましたが。

修正

2018/07/15 06:48

投稿

minsuke54

スコア4

test CHANGED Viewed

File without changes

test CHANGED Viewed

@@ -38,7 +38,9 @@
 どんな方法でも良いが、client pcのip routeの変更はしたくない。
-あくまでも、簡易な特定の操作により、wan2が利用できることが望ましい。
+あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
+大きな変更はプロキシとなるrpiに対して行うものとする。
 (プログラムの通信も通すことを考えて)

追加

2018/07/15 06:28

投稿

minsuke54

スコア4

test CHANGED Viewed

	@@ -1 +1 @@
1	- プロキシー接続による異なるnic or ネットワークセグメント間のルーティング
1	+ squid+iptables , dante socks等によるプロキシー接続による異なるnic or ネットワークセグメント間のルーティング

test CHANGED Viewed

@@ -1,4 +1,8 @@
 ### 前提・実現したいこと
+(書いている途中ですが、何個か試したので、随時追加で投稿します。)
 2つの回線があり、メインの回線とは別に、特定の操作をした時にサブ回線を通るようにしたい。
@@ -30,7 +34,15 @@
-特定の操作をしたときに、sub gwを経由してwan2を利用したいが、
+特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
+どんな方法でも良いが、client pcのip routeの変更はしたくない。
+あくまでも、簡易な特定の操作により、wan2が利用できることが望ましい。
+(プログラムの通信も通すことを考えて)
 自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
@@ -42,7 +54,7 @@
-### 発生している問題・エラーメッセージ
+### 発生している問題・エラーメッセージ(その1)
 danteについて
@@ -114,7 +126,7 @@
 1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
-eth0を経由しています。これらはtcpdumpでも確認済みです。
+eth0を経由しています。これらはrpi上でのtcpdumpでも確認済みです。
 また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
@@ -138,6 +150,30 @@
+### 発生している問題・エラーメッセージ(その2)
+squid + iptables
+```
+エラーメッセージ
+```
+### 該当のソースコード
+### 試したこと
 ### 補足情報（FW/ツールのバージョンなど）
 dante 1.52.10.2