web-dev-qa-db-ja.com

プライベートネットワークからopenvpnサブネットにトラフィックをルーティングする方法(およびその逆)

Linodeにいくつかのサーバーがあります。いずれかのマシンにVPNを接続し、プライベートlinodeネットワークを使用して他のすべてのマシンにアクセスできるようにセットアップしようとしています。その場合、プライベートサービス(SSHなど)へのパブリックアクセスは、VPNアクセスを持つユーザーのみに制限されます。

注:ファイアウォールなしがこれらのサーバーでまだ実行されています。

root@internal:~# iptables -L -n
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  

内部サーバー(openvpnサーバーを実行)

eth0      Link encap:Ethernet  HWaddr f2:3c:91:db:68:b4  
          inet addr:23.239.17.12  Bcast:23.239.17.255  Mask:255.255.255.0
          inet6 addr: 2600:3c02::f03c:91ff:fedb:68b4/64 Scope:Global
          inet6 addr: fe80::f03c:91ff:fedb:68b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:80780 errors:0 dropped:0 overruns:0 frame:0
          TX packets:102812 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:14317079 (14.3 MB)  TX bytes:17385151 (17.3 MB)

eth0:1    Link encap:Ethernet  HWaddr f2:3c:91:db:68:b4  
          inet addr:192.168.137.64  Bcast:192.168.255.255  Mask:255.255.128.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.20.1.1  P-t-P:172.20.1.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2318 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1484 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:174573 (174.5 KB)  TX bytes:170941 (170.9 KB)

上記についてのコメント:

  • eth0はパブリックインターフェイスです
  • eth0:1はプライベートネットワークへのインターフェイスです
  • VPNトンネルは正しく機能します。 VPNに接続されたクライアントから、172.20.1.1と192.168.137.64にpingを実行できます。
  • このサーバーにはnet.ipv4.ip_forward = 1が設定されています

データベースサーバー(nix03):

root@nix03:~# ifconfig eth0      Link encap:Ethernet  HWaddr f2:3c:91:73:d2:cc  
          inet addr:173.230.140.52  Bcast:173.230.140.255  Mask:255.255.255.0
          inet6 addr: 2600:3c02::f03c:91ff:fe73:d2cc/64 Scope:Global
          inet6 addr: fe80::f03c:91ff:fe73:d2cc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12348 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44434 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1166666 (1.1 MB)  TX bytes:5339936 (5.3 MB)

eth0:1    Link encap:Ethernet  HWaddr f2:3c:91:73:d2:cc  
          inet addr:192.168.137.63  Bcast:192.168.255.255  Mask:255.255.128.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

上記のコメント:

  • eth0はパブリックインターフェイスです
  • eth0:1はプライベートネットワークへのインターフェイスです
  • プライベートインターフェイス(192.168.137.64)で内部サーバーにpingを実行できます。

現在の問題

VPNを介してデータベースサーバーにアクセスできるようにしたい。私のvpnクライアント(私のオフィスのラップトップ)から、192.168.137.63にpingできるようにしたいと思います。しかし、それは現在失敗しています。

トラブルシューティングを試みる際に、データベースサーバー側からアプローチして、内部サーバー(172.20.1.1)のVPNトンネルにpingを実行できるかどうかを確認することにしました。 172.20.1.0/24ネットワーク宛てのパケットの送信先をデータベースサーバーに指示する必要があることに気づいたので、次のようにしました。

root@nix03:~# ip route add 172.20.1.0/24 via 192.168.137.64 root@nix03:~# ip route list default via 173.230.140.1 dev eth0
172.20.1.0/24 via 192.168.137.64 dev eth0
173.230.140.0/24 dev eth0  proto kernel  scope link  src 173.230.140.52
192.168.128.0/17 dev eth0  proto kernel  scope link  src 192.168.137.63 root@nix03:~# ip route get 172.20.1.1
172.20.1.1 via 192.168.137.64 dev eth0  src 192.168.137.63
    cache     

したがって、上記に基づいてと思います。172.20.1.1にpingを実行すると、サーバーはパケットを192.168.137.64(内部サーバー)に送信する必要があります。そのサーバーは、IP転送のため、eth0:1からパケットを受け取り、それをtun0(172.20.1.1)にルーティングする必要があります。

しかし、ご想像のとおり、nix03(dbサーバー)からの172.20.1.1へのpingは機能しません。

ICMPパケットが送信されるMACアドレスを確認するために、いくつかのパケットキャプチャを行いました。

root @ nix03:〜#tcpdump -i eth0 -e icmp tcpdump:詳細な出力を抑制し、eth0でフルプロトコルデコードをリスンするには、リンクタイプEN10MB(イーサネット)、キャプチャサイズ65535バイト16:41:39.623759 f2:3c:91:73:d2:cc(oui不明)> f2:3c:91:db:68:b4(oui不明)、ethertype IPv4(0x0800)、長さ98:192.168.137.63> 172.20.1.1:ICMP echo request、id 3324、seq 33653、length 64 root @ nix03:〜#arp Address HWtype HWaddress Flags Mask Iface 192.168.137.64 ether f2:3c:91:db:68:b4 C eth0

これは、パケットが内部サーバーに到達する必要があることを示しています。少なくとも、それらは正しいNICに送信されています。ただし、内部サーバーのeth0およびeth0:1でtcpdumpを実行すると、dbサーバーから受信するicmpパケットが表示されません。

他に何を試すことができますか?前もって感謝します。

更新#1

「内部」サーバーのルーティングテーブル:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gw-li686.linode 0.0.0.0         UG    0      0        0 eth0
23.239.17.0     *               255.255.255.0   U     0      0        0 eth0
172.20.1.0      172.20.1.2      255.255.255.0   UG    0      0        0 tun0
172.20.1.2      *               255.255.255.255 UH    0      0        0 tun0
192.168.128.0   *               255.255.128.0   U     0      0        0 eth0
5
Randy Syring

最終的にNATルールを内部サーバーに追加する必要がありました。必要かどうかはわかりませんが、それが機能しました。

*nat
:PREROUTING ACCEPT [21:1248]
:INPUT ACCEPT [21:1248]
:OUTPUT ACCEPT [21:1529]
:POSTROUTING ACCEPT [21:1529]
# enable NAT for VPN clients so they can hit the private network
-A POSTROUTING -s 172.20.1.0/24 -o eth0 -j MASQUERADE
COMMIT
2
Randy Syring

私は同じ問題に遭遇し、Linodeはこの種のVPN構成にはあまり適していないという結論に達しました。

まず最初に:192.168.137.63(nix03ではeth0:1)から172.20.1.1(内部ではtun0)まで(ルートをセットアップ)しようとしたことは実際に正しく、非Linodeセットアップで機能します。私は Linodeフォーラムで同じ設定元Linodeの従業員から、Linodeはその種の設定を禁止しているとの返信を受け取りました について説明しました。

さらに、VPNトラフィックを内部ネットワークにNATするのが実際に別の正しいアプローチである場合でも、192.168.128.0/24サブネットは非公開ではなく、VMが同じデータセンターにあるすべてのLinode顧客に対して非公開であることに注意してください。 。 nmapを試して、私が言っていることを確認してください。

nmap -sP 192.168.128.0/17

したがって、Linodeの場合、本当に必要な場合は次のようにします。

その場合、プライベートサービス(SSHなど)へのパブリックアクセスは、VPNアクセスを持つユーザーのみに制限されます。

サブネットはLinodeデータセンターの顧客の言葉の意味でのみプライベートであるため、ファイアウォールを注意深く設定して、正確なIPアドレスのアクセスのみを許可する必要があります。

1
Diego