質問するログイン新規登録

質問編集履歴

19

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

2018/09/07 11:52

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -283,14 +283,9 @@
283
283
 
284
284
  普段のネット接続と別の通信にしたいなどの要望は多く、ip routeやvpnでの対応が多いが、設定を大幅に変更してしまい、普段のネットワーク環境を破壊する恐れがあるので、簡単な操作・変更で済みそうなプロキシーにより実現できると良い。
285
285
 
286
- ```
287
- エラーメッセージ
286
+ ### 続き
288
- ```
287
+ 字数制限のため、[新たな投稿](https://teratail.com/questions/145425)をしました。
289
288
 
290
- ### 該当のソースコード
291
-
292
-
293
- ### 試したこと
294
289
  ### 補足情報(FW/ツールのバージョンなど)
295
290
  dante 1.52.10.2
296
291
  iptables v1.6.0

18

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

2018/09/07 11:52

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -115,7 +115,7 @@
115
115
  danteなら異なるnic間の転送ができると期待しましたが、異なるネットワークセグメント間の転送はできないようです。
116
116
 
117
117
  ```
118
- root@raspberrypi:/etc# ip route
118
+ root@raspberrypi:/# ip route
119
119
  default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 202
120
120
  default via 192.168.1.1 dev eth1 src 192.168.1.3 metric 203
121
121
  192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 202
@@ -179,13 +179,15 @@
179
179
  rpiが起動しなくなり、再インストールしてから、squid + iptables で同様の設定までしたところ、何故かsub-gwへの転送ができなくなってしまいました。
180
180
 
181
181
  やっていることは、「特定ユーザのip route変更」です。squidのユーザーであるproxyのip route変更のため、このサイトを参考にし、
182
+ (当該記事は、異なるnicの切り替えでなく、単純な同一ネットワーク内でのgw変更である)
182
183
  http://d.hatena.ne.jp/rti7743/20150320/1426880601
184
+
183
185
  以下の操作をしました。
184
186
 
185
187
  squidユーザのルーティングテーブル変更コード
186
188
  ```
187
189
 
188
- #再起動で各nicのipが変動するための取得方法
190
+ #再起動で各nicのipが再dhcpリースにより変動するための自動的な取得方法
189
191
  #https://askubuntu.com/questions/430853/how-do-i-find-my-internal-ip-address
190
192
 
191
193
  eth0_ip=$(ip addr show eth0 |grep -v inet6 | awk '/inet/ {print $2}' | cut -d/ -f1) &&
@@ -260,7 +262,6 @@
260
262
  Chain POSTROUTING (policy ACCEPT)
261
263
  target prot opt source destination
262
264
 
263
-
264
265
  ```
265
266
 
266
267
  また、rpi側から見たtcpdumpの結果としては、
@@ -269,6 +270,8 @@
269
270
  物理nicがeth1でのdumpなのに、srcipがeth0のipとなり、
270
271
  サーバからの応答を受信できません。
271
272
 
273
+ proxygwのルーティングテーブルは理解していますが、iptablesのmangleはまだ正しく理解していないところです。
274
+
272
275
  ###事前調査について
273
276
 
274
277
  よく「linuxルータを作ろう」などという記事があり、

17

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

2018/07/16 16:46

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -174,6 +174,101 @@
174
174
  自分でツール開発できるスキルはありません。
175
175
 
176
176
 
177
+ ## 発生している問題・エラーメッセージ)(その3)
178
+
179
+ rpiが起動しなくなり、再インストールしてから、squid + iptables で同様の設定までしたところ、何故かsub-gwへの転送ができなくなってしまいました。
180
+
181
+ やっていることは、「特定ユーザのip route変更」です。squidのユーザーであるproxyのip route変更のため、このサイトを参考にし、
182
+ http://d.hatena.ne.jp/rti7743/20150320/1426880601
183
+ 以下の操作をしました。
184
+
185
+ squidユーザのルーティングテーブル変更コード
186
+ ```
187
+
188
+ #再起動で各nicのipが変動するための取得方法
189
+ #https://askubuntu.com/questions/430853/how-do-i-find-my-internal-ip-address
190
+
191
+ eth0_ip=$(ip addr show eth0 |grep -v inet6 | awk '/inet/ {print $2}' | cut -d/ -f1) &&
192
+ eth1_ip=$(ip addr show eth1 |grep -v inet6 | awk '/inet/ {print $2}' | cut -d/ -f1)
193
+
194
+ proxy_route_tbl=proxygw &&
195
+ proxy_route_tbl_number=201 &&
196
+ echo 1 > /proc/sys/net/ipv4/ip_forward &&
197
+ echo "$proxy_route_tbl_number $proxy_route_tbl" >> /etc/iproute2/rt_tables &&
198
+ ip rule add fwmark 1 table $proxy_route_tbl &&
199
+ ip route add table $proxy_route_tbl default via 192.168.0.1 dev eth0 src $eth0_ip metric 203 &&
200
+ ip route add table $proxy_route_tbl default via 192.168.1.1 dev eth1 src $eth1_ip metric 202 &&
201
+ ip route add table $proxy_route_tbl 192.168.0.0/24 dev eth0 proto kernel scope link src $eth0_ip metric 203 &&
202
+ ip route add table $proxy_route_tbl 192.168.1.0/24 dev eth1 proto kernel scope link src $eth1_ip metric 202 &&
203
+ iptables -t mangle -P OUTPUT ACCEPT &&
204
+ iptables -t mangle -A OUTPUT -m owner --uid-owner proxy -j MARK --set-mark 1
205
+
206
+ # ip route,iptables 初期化用
207
+
208
+ ip rule del fwmark 1 table $proxy_route_tbl &&
209
+ ip route del table $proxy_route_tbl default via 192.168.0.1 dev eth0 src $eth0_ip metric 203 &&
210
+ ip route del table $proxy_route_tbl default via 192.168.1.1 dev eth1 src $eth1_ip metric 202 &&
211
+ ip route del table $proxy_route_tbl 192.168.0.0/24 dev eth0 proto kernel scope link src $eth0_ip metric 203 &&
212
+ ip route del table $proxy_route_tbl 192.168.1.0/24 dev eth1 proto kernel scope link src $eth1_ip metric 202 &&
213
+ iptables -F &&
214
+ iptables -F -t mangle
215
+
216
+ ```
217
+ また、変更後のip route,iptablesの設定は、
218
+
219
+ ip routeの変更後の設定
220
+ ```
221
+ root@raspberrypi:/# ip route show table main
222
+ default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 202
223
+ default via 192.168.1.1 dev eth1 src 192.168.1.5 metric 203
224
+ 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 202
225
+ 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5 metric 203
226
+
227
+ root@raspberrypi:/# ip route show table proxygw
228
+ default via 192.168.1.1 dev eth1 src 192.168.1.5 metric 202
229
+ default via 192.168.0.1 dev eth0 src 192.168.0.3 metric 203
230
+ 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.3 metric 203
231
+ 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.5 metric 202
232
+ ```
233
+ iptablesの変更後の設定
234
+
235
+ ```
236
+ root@raspberrypi:/# iptables -L
237
+ Chain INPUT (policy ACCEPT)
238
+ target prot opt source destination
239
+
240
+ Chain FORWARD (policy ACCEPT)
241
+ target prot opt source destination
242
+
243
+ Chain OUTPUT (policy ACCEPT)
244
+ target prot opt source destination
245
+
246
+ root@raspberrypi:/# iptables -L -t mangle
247
+ Chain PREROUTING (policy ACCEPT)
248
+ target prot opt source destination
249
+
250
+ Chain INPUT (policy ACCEPT)
251
+ target prot opt source destination
252
+
253
+ Chain FORWARD (policy ACCEPT)
254
+ target prot opt source destination
255
+
256
+ Chain OUTPUT (policy ACCEPT)
257
+ target prot opt source destination
258
+ MARK all -- anywhere anywhere owner UID match proxy MARK set 0x1
259
+
260
+ Chain POSTROUTING (policy ACCEPT)
261
+ target prot opt source destination
262
+
263
+
264
+ ```
265
+
266
+ また、rpi側から見たtcpdumpの結果としては、
267
+ client-rpi間は、普通に (eth0のip):3128 への通信
268
+ rpi-通信先サーバ間は、例えば1.1.1.1宛にすると、
269
+ 物理nicがeth1でのdumpなのに、srcipがeth0のipとなり、
270
+ サーバからの応答を受信できません。
271
+
177
272
  ###事前調査について
178
273
 
179
274
  よく「linuxルータを作ろう」などという記事があり、

16

2018/07/16 16:42

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -181,8 +181,10 @@
181
181
  今回はrpiをgwとする通常のルータの利用方法とは違うので、
182
182
  それらの記事を参考にして、目標を達成することはできません。
183
183
 
184
- また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。(普段のネット接続と別の通信にしたいなどの要望は多く、vpnでの対応が多いが、望ましくない。)
184
+ また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。
185
185
 
186
+ 普段のネット接続と別の通信にしたいなどの要望は多く、ip routeやvpnでの対応が多いが、設定を大幅に変更してしまい、普段のネットワーク環境を破壊する恐れがあるので、簡単な操作・変更で済みそうなプロキシーにより実現できると良い。
187
+
186
188
  ```
187
189
  エラーメッセージ
188
190
  ```

15

事前調査について

2018/07/15 15:52

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -173,11 +173,15 @@
173
173
  どうしようもありません。
174
174
  自分でツール開発できるスキルはありません。
175
175
 
176
+
177
+ ###事前調査について
178
+
176
179
  よく「linuxルータを作ろう」などという記事があり、
177
180
  異なるネットワーク間の通信を異なるnicでクリアしていますが、
178
181
  今回はrpiをgwとする通常のルータの利用方法とは違うので、
179
182
  それらの記事を参考にして、目標を達成することはできません。
180
183
 
184
+ また、英語の質問サイトで、本質問で挙げた3つのツールと「異なるnicに変更する方法」、「異なるネットワークに転送する方法」を調べても、これといったものはありませんでした。(普段のネット接続と別の通信にしたいなどの要望は多く、vpnでの対応が多いが、望ましくない。)
181
185
 
182
186
  ```
183
187
  エラーメッセージ

14

誤字脱字

2018/07/15 15:49

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -130,7 +130,7 @@
130
130
 
131
131
  http/httpsプロキシだと、本来の通信先サーバがどこでも、
132
132
  client-pcがrpi-eth0 (192.168.0.3:3218)を宛先とする通信しかしない
133
- (client pcからwirsharkで確認)ので、
133
+ (client-pcからwiresharkで確認)ので、
134
134
  squidで処理したあとの通信をどうにかしてsubnet-Bに向ける事が重要です。
135
135
 
136
136
  ####中継プロキシ-通信先サーバの間の通信について

13

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

2018/07/15 15:46

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -7,8 +7,6 @@
7
7
 
8
8
  2つの回線があり、メインの回線とは別に、特定の操作をした時に通信がサブ回線を経由するようにしたい。
9
9
  今、以下のようなネットワーク構成であるとする。
10
- (左側のaはスペースを反映させるための装飾で、特に意味はない。
11
- また、モバイル版では図が崩れて表示されます。)
12
10
 
13
11
  ```
14
12
  (subnet-A : 192.168.0.0/24)
@@ -24,9 +22,9 @@
24
22
  (subnet-B : 192.168.1.0/24)
25
23
  ```
26
24
 
27
- client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
25
+ client-pc : ubuntu 18.04 (client-pcは今後増える可能性あり)
28
- rpi: raspberry pi stretch
26
+ rpi : raspberry pi stretch
29
- main-gw,sub-gw:市販のルータで、dhcpサーバ機能を持つ
27
+ main-gw,sub-gw : 市販のルータで、dhcpサーバ機能を持つ
30
28
 
31
29
  rpiには、lanケーブルとusb-lanアダプタの2つのnicがついており、それぞれeth0,eth1である。また、ip割当は各ルータのdhcp機能により行った。rpiがルータの役割をする事はない。
32
30
 
@@ -190,4 +188,6 @@
190
188
 
191
189
  ### 試したこと
192
190
  ### 補足情報(FW/ツールのバージョンなど)
193
- dante 1.52.10.2
191
+ dante 1.52.10.2
192
+ iptables v1.6.0
193
+ squid3-3.5.23

12

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

2018/07/15 15:35

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -1,4 +1,3 @@
1
- ```
2
1
  ## 注意点
3
2
 
4
3
  この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
@@ -11,6 +10,7 @@
11
10
  (左側のaはスペースを反映させるための装飾で、特に意味はない。
12
11
  また、モバイル版では図が崩れて表示されます。)
13
12
 
13
+ ```
14
14
  (subnet-A : 192.168.0.0/24)
15
15
  clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
16
16
           |
@@ -22,6 +22,7 @@
22
22
  |
23
23
  sub-gw (192.168.1.1)ーwan2
24
24
  (subnet-B : 192.168.1.0/24)
25
+ ```
25
26
 
26
27
  client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
27
28
  rpi: raspberry pi stretch
@@ -189,5 +190,4 @@
189
190
 
190
191
  ### 試したこと
191
192
  ### 補足情報(FW/ツールのバージョンなど)
192
- dante 1.52.10.2
193
+ dante 1.52.10.2
193
- ```

11

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

2018/07/15 15:30

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -1,3 +1,4 @@
1
+ ```
1
2
  ## 注意点
2
3
 
3
4
  この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
@@ -12,14 +13,14 @@
12
13
 
13
14
  (subnet-A : 192.168.0.0/24)
14
15
  clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
15
- a        |
16
+          |
16
- a        |
17
+          |
17
- a        |
18
+          |
18
- a rpi-eth0 (192.168.0.3)
19
+ rpi-eth0 (192.168.0.3)
19
- a | (rpi内部)
20
+ | (rpi内部)
20
- a rpi-eth1 (192.168.1.3)
21
+ rpi-eth1 (192.168.1.3)
21
- a |
22
+ |
22
- a sub-gw (192.168.1.1)ーwan2
23
+ sub-gw (192.168.1.1)ーwan2
23
24
  (subnet-B : 192.168.1.0/24)
24
25
 
25
26
  client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
@@ -188,4 +189,5 @@
188
189
 
189
190
  ### 試したこと
190
191
  ### 補足情報(FW/ツールのバージョンなど)
191
- dante 1.52.10.2
192
+ dante 1.52.10.2
193
+ ```

10

2018/07/15 15:28

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -1,13 +1,14 @@
1
- ### 注意点
1
+ ## 注意点
2
2
 
3
3
  この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
4
4
  ご了承ください。
5
5
 
6
- ### 前提・実現したいこと
6
+ ##前提・実現したいこと
7
7
 
8
8
  2つの回線があり、メインの回線とは別に、特定の操作をした時に通信がサブ回線を経由するようにしたい。
9
9
  今、以下のようなネットワーク構成であるとする。
10
- (左側のaはスペースを反映させるための装飾で、特に意味はない)
10
+ (左側のaはスペースを反映させるための装飾で、特に意味はない
11
+ また、モバイル版では図が崩れて表示されます。)
11
12
 
12
13
  (subnet-A : 192.168.0.0/24)
13
14
  clien-pc(192.168.0.2)ー main-gw(192.168.0.1)ーwan1
@@ -42,7 +43,7 @@
42
43
  使用したツールについての動作や概念を正しく理解している自信がないため、
43
44
  自分の理解を提示しつつ、説明を書いていきます。
44
45
 
45
- ### 発生している問題・エラーメッセージ(その1)
46
+ ## 発生している問題・エラーメッセージ(その1)
46
47
  danteについて
47
48
  ```
48
49
  ・subnet-B宛の通信はeth1を経由するが、それ以外はeth0経由となる。
@@ -88,9 +89,9 @@
88
89
 
89
90
  また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにしたつもり。
90
91
 
91
- まず、client-pcからのsocks proxy接続の結果について、
92
+ ####client-pcからのsocks proxy接続の結果について、
92
93
 
93
- すると、sub-gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
94
+ sub-gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
94
95
  subnet-B(eth1を経由とは書かない)を経由しているが、
95
96
  1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
96
97
  subnet-Aを経由しています。
@@ -105,7 +106,7 @@
105
106
  送信先ネットワークセグメントの違いとは限らない、ということなので、
106
107
  セグメント分けには利用できないです。
107
108
 
108
- 次に、proxy server本体となるrpiを送信元とする結果について
109
+ ####proxy server本体となるrpiを送信元とする結果について
109
110
 
110
111
  rpiにssh loginしてpingすると、
111
112
  subnet-B宛はeth1を通るが、
@@ -121,9 +122,10 @@
121
122
  192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 203
122
123
  ```
123
124
 
124
- ### 発生している問題・エラーメッセージ(というより、方法を模索中)(その2)
125
+ ## 発生している問題・エラーメッセージ(というより、方法を模索中)(その2)
125
- squid + iptablesについて
126
126
 
127
+ ###squid + iptablesについて
128
+
127
129
  次に考えたことは、rpiにsquidを立て、client-pcからsquidに対する通信をiptablesによりsubnet-Bへルーティングする事です。http/httpsプロキシの挙動については知らないので、自分の理解を示しながら説明していきます。
128
130
 
129
131
  http/httpsプロキシだと、本来の通信先サーバがどこでも、
@@ -131,7 +133,7 @@
131
133
  (client pcからwirsharkで確認)ので、
132
134
  squidで処理したあとの通信をどうにかしてsubnet-Bに向ける事が重要です。
133
135
 
134
- 次に、中継プロキシ-通信先サーバの間の通信について
136
+ ####中継プロキシ-通信先サーバの間の通信について
135
137
 
136
138
  http/httpsのproxy接続では、中継プロキシ-通信先サーバの間の通信は、
137
139
  メインの通信内容(layer5以上?)はclient-pcのもの、
@@ -171,7 +173,12 @@
171
173
  どうしようもありません。
172
174
  自分でツール開発できるスキルはありません。
173
175
 
176
+ よく「linuxルータを作ろう」などという記事があり、
177
+ 異なるネットワーク間の通信を異なるnicでクリアしていますが、
178
+ 今回はrpiをgwとする通常のルータの利用方法とは違うので、
179
+ それらの記事を参考にして、目標を達成することはできません。
174
180
 
181
+
175
182
  ```
176
183
  エラーメッセージ
177
184
  ```

9

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

2018/07/15 10:26

投稿

minsuke54
minsuke54

スコア4

title CHANGED
@@ -1,1 +1,1 @@
1
- squid + iptables , dante socks等を利用したプロキシー接続による異なるnic or ネットワークセグメント間のルーティングにつ
1
+ プロキシー接続による異なるネットワーク間のルーティングができな
body CHANGED
@@ -1,36 +1,51 @@
1
+ ### 注意点
2
+
3
+ この質問は、既に行った方法と、これからやろうと試みているが、理解が足りず進んでいない部分を並列して載せているので、読みづらいかと思います。
4
+ ご了承ください。
5
+
1
6
  ### 前提・実現したいこと
2
- (書いている途中ですが、何個か試したので、随時追加で投稿します。)
3
7
 
4
- 2つの回線があり、メインの回線とは別に、特定の操作をした時にサブ回線をるようにしたい。
8
+ 2つの回線があり、メインの回線とは別に、特定の操作をした時に通信がサブ回線を経由するようにしたい。
9
+ 今、以下のようなネットワーク構成であるとする。
5
- 今、以下のようなネットワーク構成であるとする。(左側のaはスペースを反映させるための装飾で、特に意味はない)
10
+ (左側のaはスペースを反映させるための装飾で、特に意味はない)
6
11
 
7
- (subnet A)
12
+ (subnet-A : 192.168.0.0/24)
8
- pc(192.168.0.2)--main gw(192.168.0.1)--wan1
13
+ clien-pc(192.168.0.2) main-gw(192.168.0.1)wan1
9
14
  a        |
10
15
  a        |
11
16
  a        |
12
- a rpi eth0(192.168.0.3)
17
+ a rpi-eth0 (192.168.0.3)
13
- a |(rpi内部)
18
+ a | (rpi内部)
14
- a rpi eth1(192.168.1.3)
19
+ a rpi-eth1 (192.168.1.3)
15
- a |
20
+ a |
16
- a sub gw(192.168.0.1)--wan2
21
+ a sub-gw (192.168.1.1)wan2
17
- (subnet B)
22
+ (subnet-B : 192.168.1.0/24)
18
23
 
24
+ client-pc:ubuntu 18.04 (client-pcは今後増える可能性あり)
25
+ rpi: raspberry pi stretch
19
- 特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
26
+ main-gw,sub-gw:市販ルータで、dhcpサーバ機能を持つ
20
- どんな方法でも良いが、client pcのip routeの変更やvpn設定はしたくない。
21
- あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
22
- 大きな変更はプロキシとなるrpiに対して行うものとする。
23
- (プログラムの通信も通すことを考えて)
24
27
 
25
- 自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
26
- やった方法は、「squid + iptables」 or 「dante socks proxy」た。
28
+ rpiには、lanケーブルとusb-lanアダプタの2つのnicがついており、それぞれeth0,eth1ある。ま、ip割当は各ルータのdhcp機能により行ったrpiがルータの役割をする事はない。
27
- できなかったので、経緯を詳しく書きます。
28
- 使用したツールについての動作や概念を正しく理解している自身はありません。
29
29
 
30
+ 特定の操作をしたときに、client-pcの通信がsub-gwを経由してwan2を利用できればよいので、
31
+ どんな方法でも良いが、client-pcのip routeの変更やvpn設定はしたくない。
32
+
33
+ プログラムの通信を経由させる事を考えると、プログラム上でも人間でも簡単な操作により、wan2が利用できることが望ましいので、方法はプロキシあたりになると思います。
34
+ そして、大きな変更はプロキシとなるrpiに対して行うものとして、
35
+ client機器には負担をかけたくない。
36
+
37
+ 自分が考えている方法は、rpi-eth0にプロキシ接続をして、ルーティングされる方法です。
38
+ やった方法は、 「dante socks proxy」で、
39
+ 途中で諦めて、再び試しているのは、「squid + iptables」です。
40
+
41
+ できていないので、経緯を詳しく書きます。
42
+ 使用したツールについての動作や概念を正しく理解している自信がないため、
43
+ 自分の理解を提示しつつ、説明を書いていきます。
44
+
30
45
  ### 発生している問題・エラーメッセージ(その1)
31
46
  danteについて
32
47
  ```
33
- エラーメッセージ
48
+ ・subnet-B宛の通信はeth1を経由するが、それ以外はeth0経由となる。
34
49
  ```
35
50
 
36
51
  ### 該当のソースコード
@@ -63,23 +78,40 @@
63
78
  ```
64
79
 
65
80
  ### 試したこと
81
+
82
+ まず、firefoxのプロキシ設定を
83
+
66
- まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定した。
84
+ protocol version : socks_v4 or v5
85
+ proxy server:eth0のipアドレス
86
+
87
+ に設定した。
88
+
67
- また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにした。
89
+ また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにしたつもり
90
+
91
+ まず、client-pcからのsocks proxy接続の結果について、
92
+
68
- すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
93
+ すると、sub-gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
69
- subnet B(eth1を経由とは書かない)を経由しているが、
94
+ subnet-B(eth1を経由とは書かない)を経由しているが、
70
95
  1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
71
- subnet Aを経由しています。
96
+ subnet-Aを経由しています。
72
97
 
73
98
  tcpdumpで確認すると、
74
- subnet B宛は、tcpdump -i eth1 で確認できるが、
99
+ subnet-B宛は、tcpdump -i eth1 で確認できるが、
75
100
  1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
101
+
76
102
  つまり、danteの設定において、
77
- 宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、応答パケット受信できないです。
103
+ 宛先がsubnet-B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、応答パケット受信できないです。
104
+ この意味は、danteの設定において、interanlとexternalが異なる事は、
78
- そして、interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはらないうなので、セグメント分けには利用できないです。
105
+ 送信先ネットワークセグメントの違いとはらない、といことなので、
106
+ セグメント分けには利用できないです。
107
+
108
+ 次に、proxy server本体となるrpiを送信元とする結果について
109
+
79
- また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
110
+ rpiにssh loginしてpingすると、
111
+ subnet-B宛はeth1を通るが、
80
112
  それ以外はeth0を経由しており、
81
113
  宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付けた)
82
- danteなら異なるnic間の転送ができると期待しましたが。
114
+ danteなら異なるnic間の転送ができると期待しましたが、異なるネットワークセグメント間の転送はできないようです
83
115
 
84
116
  ```
85
117
  root@raspberrypi:/etc# ip route
@@ -89,14 +121,24 @@
89
121
  192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 203
90
122
  ```
91
123
 
92
- ### 発生している問題・エラーメッセージ(その2)
124
+ ### 発生している問題・エラーメッセージ(というより、方法を模索中)(その2)
93
- squid + iptablesについて
125
+ squid + iptablesについて
94
126
 
95
- 次に考えたことは、rpiにsquidを立て、client pcからsquidに対する通信をiptablesによりsubnet Bへルーティングする事です。
127
+ 次に考えたことは、rpiにsquidを立て、client-pcからsquidに対する通信をiptablesによりsubnet-Bへルーティングする事です。http/httpsプロキシの挙動については知らないので、自分の理解を示しながら説明していきます。
96
128
 
129
+ http/httpsプロキシだと、本来の通信先サーバがどこでも、
97
- http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしない(client pcからwirsharkで確認)ので、squidで処理したあとの通信をどう扱うかが重要です。
130
+ client-pcがrpi-eth0 (192.168.0.3:3218)を宛先とする通信しかしない
131
+ (client pcからwirsharkで確認)ので、
132
+ squidで処理したあとの通信をどうにかしてsubnet-Bに向ける事が重要です。
98
133
 
134
+ 次に、中継プロキシ-通信先サーバの間の通信について
135
+
136
+ http/httpsのproxy接続では、中継プロキシ-通信先サーバの間の通信は、
137
+ メインの通信内容(layer5以上?)はclient-pcのもの、
138
+ tcpヘッダまでは中継プロキシのものになる。
139
+ よって、実質的には、中継プロキシであるrpiを発信元とする通信とみなして問題を考えれば良い。
140
+
99
- 特に、このサイトの
141
+ そこで、このサイトの
100
142
  https://www.virment.com/iptables-outline/
101
143
  「各チェインがどのパケットを対象とするかを表したイメージ図」を参考にすると、
102
144
  「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
@@ -108,14 +150,22 @@
108
150
 
109
151
  OUTPUTはローカルプロセスに処理されて出力されたパケット、すなわち送信元がホストマシンであるパケットを対象としているのに対し、POSTROUTINGは送信元がホストマシンであるとは限りません。例えば、FORWARDによって転送されたパケットも対象となります。
110
152
 
153
+ とあり、今回はrpi本体からの通信とみなして良いので、
111
- とあり、実質的には、「OUTPUT」だけを考えれば良いです。
154
+ 説明文中の「ホストマシン」だけを考えており、実質的には、「OUTPUT」だけを考えれば良いです。
112
- そして、http/https接続では、中継プロキシ-通信先サーバの間の通信は、
113
- tcpヘッダまでは中継プロキシのものなるので
155
+ しかし、これでは、iptablesから見た時に、
156
+ src ipはrpi本体、src portはランダムなため、
114
- iptablesから見た時に、src ip,portによりsquidからの通信かどうか判別不能です。
157
+ squidからの通信かどうか判別不能です。
115
158
 
159
+ さらに、iptablesのsubnet-Bへの転送設定を弄ろうとしているので、
160
+ OUTPUTで変な設定をすると、
116
- だから、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bへ転送されて、ssh切断の危険性もあります。
161
+ rpiへのssh accessも含め、全てsubnet Bへ転送されて、
162
+ ssh切断の危険性もあります。
117
163
 
164
+ となると、iptablesをやめて、squidの設定に、
165
+ client-pcからのsquid宛はsubnet-Bへ転送させる設定をする必要があります。
118
- となると、squidの設定に、squid宛はsubnet Bへ転送させ設定をすることになりが、tcp_outgoing_addressを設定すると、転送先nicが変更されのではなく、宛先ipが変更されおり通信先サーバへアクセスできないです。
166
+ ような設定があか探ししたが、転送先変更方法として、「tcp_outgoing_address」というものがありましたが、
167
+ 転送先nicではなく宛先ipが変更されるため、
168
+ 通信先サーバへのアクセスができないです。
119
169
 
120
170
  転送先nicとネットワークセグメントをうまく処理するツールがないため、
121
171
  どうしようもありません。

8

タグ追加

2018/07/15 10:16

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
File without changes

7

2018/07/15 07:19

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -17,7 +17,7 @@
17
17
  (subnet B)
18
18
 
19
19
  特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
20
- どんな方法でも良いが、client pcのip routeの変更はしたくない。
20
+ どんな方法でも良いが、client pcのip routeの変更やvpn設定はしたくない。
21
21
  あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
22
22
  大きな変更はプロキシとなるrpiに対して行うものとする。
23
23
  (プログラムの通信も通すことを考えて)
@@ -37,7 +37,7 @@
37
37
 
38
38
  「danted.conf」の設定
39
39
 
40
- ・入口と出口のポートを別々にした
40
+ ・入口と出口のnicを別々にした
41
41
  ・カーネルパニック対策にローカルアドレスに対しても、client passを設定した。(https://qiita.com/hirohiro77/items/087c4d9e6b03050f70ad)
42
42
 
43
43
  ```

6

iptables squidではできないこと

2018/07/15 07:16

投稿

minsuke54
minsuke54

スコア4

title CHANGED
@@ -1,1 +1,1 @@
1
- squid+iptables , dante socks等によるプロキシー接続による異なるnic or ネットワークセグメント間のルーティング
1
+ squid + iptables , dante socks等を利用したプロキシー接続による異なるnic or ネットワークセグメント間のルーティングについて
body CHANGED
@@ -25,8 +25,8 @@
25
25
  自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
26
26
  やった方法は、「squid + iptables」 or 「dante socks proxy」でした。
27
27
  できなかったので、経緯を詳しく書きます。
28
+ 使用したツールについての動作や概念を正しく理解している自身はありません。
28
29
 
29
-
30
30
  ### 発生している問題・エラーメッセージ(その1)
31
31
  danteについて
32
32
  ```
@@ -94,10 +94,11 @@
94
94
 
95
95
  次に考えたことは、rpiにsquidを立て、client pcからsquidに対する通信をiptablesによりsubnet Bへルーティングする事です。
96
96
 
97
- http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしないので、squidで処理したあとの通信をどう扱うかが重要です。
97
+ http/httpsプロキシだと、client pcがrpi (192.168.0.3:3218)を宛先とする通信しかしない(client pcからwirsharkで確認)ので、squidで処理したあとの通信をどう扱うかが重要です。
98
+
98
99
  特に、このサイトの
99
100
  https://www.virment.com/iptables-outline/
100
- 「各チェインがどのパケットを対象とするかを表したイメージ図」参考にすると、
101
+ 「各チェインがどのパケットを対象とするかを表したイメージ図」参考にすると、
101
102
  「squid」というローカルプロセスで処理された通信を、「OUTPUT」「POSTROUTING」で操作する必要があります。
102
103
  そして、これらの説明には、
103
104
 
@@ -107,13 +108,20 @@
107
108
 
108
109
  OUTPUTはローカルプロセスに処理されて出力されたパケット、すなわち送信元がホストマシンであるパケットを対象としているのに対し、POSTROUTINGは送信元がホストマシンであるとは限りません。例えば、FORWARDによって転送されたパケットも対象となります。
109
110
 
111
+ とあり、実質的には、「OUTPUT」だけを考えれば良いです。
110
- とあり、http/https接続では、中継プロキシ-通信先サーバの間の通信は、tcpヘッダまでは中継プロキシのものになるので、squidによる通信か判別不能です。
112
+ そして、http/https接続では、中継プロキシ-通信先サーバの間の通信は、
113
+ tcpヘッダまでは中継プロキシのものになるので、
111
- から、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bからやる必要が出る可性もあります。
114
+ iptablesから見た時にsrc ip,portによりsquidからの通信かどうか判別不す。
112
115
 
116
+ だから、OUTPUTで変な設定をすると、rpiへのssh accessも含め、全てsubnet Bへ転送されて、ssh切断の危険性もあります。
117
+
113
118
  となると、squidの設定に、squid宛はsubnet Bへ転送させる設定をすることになりますが、tcp_outgoing_addressを設定すると、転送先nicが変更されるのではなく、宛先ipが変更されており、通信先サーバへのアクセスができないです。
114
119
 
120
+ 転送先nicとネットワークセグメントをうまく処理するツールがないため、
115
121
  どうしようもありません。
122
+ 自分でツール開発できるスキルはありません。
116
123
 
124
+
117
125
  ```
118
126
  エラーメッセージ
119
127
  ```

5

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

2018/07/15 07:11

投稿

minsuke54
minsuke54

スコア4

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

4

2018/07/15 07:05

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -63,18 +63,19 @@
63
63
  ```
64
64
 
65
65
  ### 試したこと
66
- まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定し
66
+ まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定した。
67
- eth0からeth1に流れるように、danted.confを設定した。
67
+ また、上記に記載したdanted.confの設定により、eth0からeth1に転送できるようにした。
68
68
  すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
69
69
  subnet B(eth1を経由とは書かない)を経由しているが、
70
70
  1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
71
- eth0を経由しています。
71
+ subnet Aを経由しています。
72
+
72
73
  tcpdumpで確認すると、
73
74
  subnet B宛は、tcpdump -i eth1 で確認できるが、
74
75
  1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
75
76
  つまり、danteの設定において、
76
- 宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、
77
+ 宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、応答パケット受信できないです。
77
- interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
78
+ そして、interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
78
79
  また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
79
80
  それ以外はeth0を経由しており、
80
81
  宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付けた)

3

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

2018/07/15 06:53

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -35,7 +35,12 @@
35
35
 
36
36
  ### 該当のソースコード
37
37
 
38
- ```danted.conf
38
+ danted.conf」の設定
39
+
40
+ ・入り口と出口のポートを別々にした
41
+ ・カーネルパニック対策にローカルアドレスに対しても、client passを設定した。(https://qiita.com/hirohiro77/items/087c4d9e6b03050f70ad)
42
+
43
+ ```
39
44
  # $Id: sockd.conf,v 1.52.10.2 2014/09/03 14:49:13 michaels Exp $
40
45
  logoutput: syslog stdout /var/log/sockd.log
41
46
  debug: 1
@@ -61,11 +66,19 @@
61
66
  まず、firefoxのプロキシ設定からsocks_v4 or v5でeth0に設定し、
62
67
  eth0からeth1に流れるように、danted.confを設定した。
63
68
  すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
64
- eth1を経由しているが、
69
+ subnet B(eth1を経由とは書かない)を経由しているが、
65
70
  1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
71
+ eth0を経由しています。
72
+ tcpdumpで確認すると、
66
- eth0を経由しています。これらrpi上でのtcpdumpで確認済みす。
73
+ subnet B宛tcpdump -i eth1 で確認できるが、
74
+ 1.1.1.1宛は、tcpdump -i eth0で、しかも送信元が192.168.1.3(eth1)のアドレスです。
75
+ つまり、danteの設定において、
76
+ 宛先がsubnet B以外だと、必ずeth0から出力されるが、送信元がexternalで設定したeth1のアドレスとなり、
77
+ interanlとexternalが異なる事は、送信先ネットワークセグメントの違いとはならないようなので、セグメント分けには利用できないです。
67
78
  また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
79
+ それ以外はeth0を経由しており、
68
- それ以外eth0を経由しており、danteの設定以前にosのルーティングテーブルが優先されているようです。danteなら異なるnic間の転送ができると期待しましが。
80
+ 宛先選択には、danteの設定以前にosのルーティングテーブルが優先されているようです。(以下に貼り付け)
81
+ danteなら異なるnic間の転送ができると期待しましたが。
69
82
 
70
83
  ```
71
84
  root@raspberrypi:/etc# ip route

2

修正

2018/07/15 06:48

投稿

minsuke54
minsuke54

スコア4

title CHANGED
File without changes
body CHANGED
@@ -18,7 +18,8 @@
18
18
 
19
19
  特定の操作をしたときに、sub gwを経由してwan2を利用できればよいので、
20
20
  どんな方法でも良いが、client pcのip routeの変更はしたくない。
21
- あくまでも、簡易な特定の操作により、wan2が利用できることが望ましい
21
+ あくまでも、簡易な特定の操作により、wan2が利用できることが望ましいので、
22
+ 大きな変更はプロキシとなるrpiに対して行うものとする。
22
23
  (プログラムの通信も通すことを考えて)
23
24
 
24
25
  自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。

1

追加

2018/07/15 06:28

投稿

minsuke54
minsuke54

スコア4

title CHANGED
@@ -1,1 +1,1 @@
1
- プロキシー接続による異なるnic or ネットワークセグメント間のルーティング
1
+ squid+iptables , dante socks等によるプロキシー接続による異なるnic or ネットワークセグメント間のルーティング
body CHANGED
@@ -1,4 +1,6 @@
1
1
  ### 前提・実現したいこと
2
+ (書いている途中ですが、何個か試したので、随時追加で投稿します。)
3
+
2
4
  2つの回線があり、メインの回線とは別に、特定の操作をした時にサブ回線を通るようにしたい。
3
5
  今、以下のようなネットワーク構成であるとする。(左側のaはスペースを反映させるための装飾で、特に意味はない)
4
6
 
@@ -14,13 +16,17 @@
14
16
  a sub gw(192.168.0.1)--wan2
15
17
  (subnet B)
16
18
 
17
- 特定の操作をしたときに、sub gwを経由してwan2を利用した
19
+ 特定の操作をしたときに、sub gwを経由してwan2を利用できればよので
20
+ どんな方法でも良いが、client pcのip routeの変更はしたくない。
21
+ あくまでも、簡易な特定の操作により、wan2が利用できることが望ましい。
22
+ (プログラムの通信も通すことを考えて)
23
+
18
24
  自分が考えている方法は、rpi eth0にプロキシ接続をして、ルーティングされる方法です。
19
25
  やった方法は、「squid + iptables」 or 「dante socks proxy」でした。
20
26
  できなかったので、経緯を詳しく書きます。
21
27
 
22
28
 
23
- ### 発生している問題・エラーメッセージ
29
+ ### 発生している問題・エラーメッセージ(その1)
24
30
  danteについて
25
31
  ```
26
32
  エラーメッセージ
@@ -56,7 +62,7 @@
56
62
  すると、sub gw(192.168.1.1)の管理画面にはアクセスできる、つまり、
57
63
  eth1を経由しているが、
58
64
  1.1.1.1 (dns無しでhttp/httpsアクセス可能なアドレスで試行) には、
59
- eth0を経由しています。これらはtcpdumpでも確認済みです。
65
+ eth0を経由しています。これらはrpi上でのtcpdumpでも確認済みです。
60
66
  また、rpiにssh loginしてpingすると、subnet B宛はeth1を通るが、
61
67
  それ以外はeth0を経由しており、danteの設定以前にosのルーティングテーブルが優先されているようです。danteなら異なるnic間の転送ができると期待しましたが。
62
68
 
@@ -68,5 +74,17 @@
68
74
  192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.3 metric 203
69
75
  ```
70
76
 
77
+ ### 発生している問題・エラーメッセージ(その2)
78
+ squid + iptables
79
+
80
+
81
+ ```
82
+ エラーメッセージ
83
+ ```
84
+
85
+ ### 該当のソースコード
86
+
87
+
88
+ ### 試したこと
71
89
  ### 補足情報(FW/ツールのバージョンなど)
72
90
  dante 1.52.10.2