☰

구성에서 발생하는 상황에 대한 설명입니다.

tag-icon • tag-icon iptables vpn openvpn
구성에서 발생하는 상황에 대한 설명입니다.

이 문제를 해결하는 데 도움을 주실 수 있나요? tun0 인터페이스(OpenVPN 터널)의 모든 트래픽을 eth1 인터페이스로 리디렉션해야 합니다. eth1은 이 시스템 뒤의 내부 네트워크이며 특수 방화벽으로 사용됩니다... 이 규칙을 사용하는 경우(지금은 테스트 목적으로만 사용 - 대상 포트 80):

iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.199.115.146

VPN의 트래픽이 올바르게 전달됩니다. iptables 통계(iptables -L -v)에서 볼 수 있지만 역방향 트래픽이 통과되지 않습니다. iptables에 다음 오류가 표시됩니다.

99689.703349 x_tables: ip_tables: tcp match: only valid for protocol 6

방화벽 뒤에 있는 컴퓨터의 모든 트래픽을 tun0 인터페이스를 통해서만 리디렉션해야 합니다. 나는 또한 이 규칙을 사용합니다:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

나는 그것을 활성화했습니다 . 규칙 없이 ip_forward규칙을 사용하면 규칙의 iptables 통계 활동에서 볼 수 있습니다.-p tcp-m tcpiptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

상호 작용

VPN 서버(A):

eth0      Link encap:Ethernet  HWaddr 00:...
          inet addr:MY_PUBLIC_IP  Bcast:MY_PUBLIC_IP.255  Mask:255.255.255.0
          inet6 addr: .../64 Scope:Global
          inet6 addr: .../64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:41909528 errors:0 dropped:0 overruns:0 frame:0
          TX packets:373639 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2150448064 (2.1 GB)  TX bytes:185713075 (185.7 MB)
          Interrupt:10

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.1.1  P-t-P:10.1.1.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:82014 errors:0 dropped:0 overruns:0 frame:0
          TX packets:164251 errors:0 dropped:24 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:5945388 (5.9 MB)  TX bytes:147587733 (147.5 MB)

방화벽 머신에서:

eth0      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:189399 errors:0 dropped:0 overruns:0 frame:0
          TX packets:103528 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:180399131 (180.3 MB)  TX bytes:14844868 (14.8 MB)


tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.1.1.2  P-t-P:10.1.1.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:153314 errors:0 dropped:0 overruns:0 frame:0
          TX packets:80986 errors:0 dropped:8 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:145341797 (145.3 MB)  TX bytes:5818996 (5.8 MB)

eth1      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.199.115.1  Bcast:10.199.115.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6890 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23022 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:710721 (710.7 KB)  TX bytes:43966879 (43.9 MB)

기계 B:

eth0      Link encap:Ethernet  HWaddr 08:...
          inet addr:10.199.115.146  Bcast:10.199.155.255  Mask:255.255.255.0
          inet6 addr: .../64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24185 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8044 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29645960 (28.2 MiB)  TX bytes:842414 (822.6 KiB)

건축학:

VPN server (A) /eth0 - public IP, tun0 VPN/ <-> Firewall (F) /tun0 VPN, eth1 - internal network/ <-> Server (B) (eth0 - internal network)

방화벽 뒤에 있는 컴퓨터에서 시작된 통신이 제대로 작동합니다. 도움을 주셔서 감사합니다.

라우팅 테이블:

VPN 서버 A: - VPS 서버입니다.

10.1.1.2 dev tun0  proto kernel  scope link  src 10.1.1.1
MY_PUBLIC_IP.0/24 dev eth0  proto kernel  scope link  src MY_PUBLIC_IP
10.199.115.0/24 via 10.1.1.2 dev tun0
default via MY_PUBLIC_IP.1 dev eth0  metric 100

///물리적 서버

방화벽 F: 가상 머신 VirtualBox Ubuntu - eth0은 VirtualBox NAT이지만 tun0을 사용해야 하며 eth1은 B의 로컬 네트워크입니다.

0.0.0.0/1 via 10.1.1.1 dev tun0
default via 10.0.2.2 dev eth0  metric 100
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
10.1.1.1 dev tun0  proto kernel  scope link  src 10.1.1.2
10.199.115.0/24 dev eth1  proto kernel  scope link  src 10.199.115.1
MY_PUBLIC_IP via 10.0.2.2 dev eth0
128.0.0.0/1 via 10.1.1.1 dev tun0

eth1 측의 머신 B(eth0 없음)는 가상 머신 Debian 7입니다.

default via 10.199.115.1 dev eth0 proto static
10.199.115.0/24 dev eth0 proto kernel scope link src 10.199.115.146

패킷 라우팅은 최대한 투명하거나 보이지 않아야 합니다.

iptables 규칙:

VPN 서버(A)에서:

테이블 NAT만 해당:

-P PREROUTING ACCEPT
-P POSTROUTING ACCEPT
-P OUTPUT ACCEPT
-A PREROUTING -i eth0 -p tcp -m tcp --dport 0:1192 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p tcp -m tcp --dport 1195:65535 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p udp -m udp --dport 0:1192 -j DNAT --to-destination 10.1.1.2
-A PREROUTING -i eth0 -p udp -m udp --dport 1195:65535 -j DNAT --to-destination 10.1.1.2
-A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE

필터 테이블

is empty

망겔 테이블

is empty

방화벽(F)에서:

현재 마지막 수정 후

NAT 테이블:

none

필터 테이블

contains many specific rules for mitigation etc...

망겔 테이블

is empty

머신 B에서

without iptables rules

답변1

서버 A에는 VPN을 통해 네트워크에 연결하기 위한 권장 경로가 없기 10.199.115.0/24때문에 기본 경로를 사용합니다(예: 공용 IP를 통해 B에 연결하려고 시도함).

작동하는지 확인해 보세요.

ip route add 10.199.115.0/24 via 10.1.1.2

A에서 B로의 연결은 서버 A에서 허용됩니다(방화벽 F에는 NAT 규칙이 없음).

이것이 작동하면 A에서 연결을 시작할 때 자동으로 경로를 생성하도록 openvpn을 설정할 수 있습니다.

구성에서 발생하는 상황에 대한 설명입니다.

세 가지 시나리오에서 라우팅/NAT가 발생하는 방식은 다음과 같습니다.

사례 1: B ping PUBLIC_IP

  • 패킷은 default일치하는 유일한 패킷이기 때문에 해당 경로를 사용하여 B를 떠납니다 PUBLIC_IP. 10.199.115.1최종 목적지 PUBLIC_IP와 소스 주소를 포함하여 라우팅을 위한 IP 주소로 전송됩니다 10.199.115.146.
  • 패킷은 F에 의해 라우팅됩니다. 많은 경로가 적용됩니다. 가장 구체적인 방법은 PUBLIC_IP/32머신 A(기본 openvpn 연결)인 머신에서 라우팅할 패킷을 보내는 것입니다.10.0.2.2eth0
  • 머신 A는 패킷을 수신하고 소스 주소로 응답합니다 10.199.115.146. 제가 보여드리는 규칙이 없으면 이는 인터넷 주소로 해석되어 응답이 인터넷을 통해 전송될 것입니다.
  • 내가 제안한 경로를 사용하여 패킷은 tun0시스템 F를 통해 반환됩니다. 머신 F는 이를 eth1머신 B가 응답 패킷을 받는 곳 으로 다시 라우팅합니다 . 그러나 10.1.1.1원본 패킷에 대한 응답으로 인식되지 않도록 원본이 태그되어 있습니다 . 핑에 실패했습니다.

사례 2: B 핑 10.1.1.1

  • 이전과 마찬가지로 패킷은 B를 떠나 F로 라우팅됩니다.
  • 이번에는 대상 주소가 규칙 10.1.1.1/32와 일치하므로 패킷이 통과됩니다.tun0
  • 규칙은 패킷이 전송될 때 적용 tun0되어 MASQUERADE패킷의 소스를 로 변경합니다 10.1.1.2. (제가 제안한 라우팅 규칙을 사용하는 경우에는 이 작업을 수행할 필요가 없습니다. 아래를 참조하세요.)
  • 머신 A는 패킷을 수신하고 응답합니다 10.1.1.2(머신 F). 이것이 없으면 MASQUERADE반송될 것입니다 10.199.115.146. 내가 제안한 경로 테이블 항목을 사용하면 패키지가 여전히 경로로 전송되므로 크게 변경되지 않지만 10.1.1.2항목이 없는 경우 대상은 10.199.115.146인터넷을 통해 라우팅됩니다.
  • 응답 패킷은 시스템 F에 의해 수신됩니다. 매스커레이딩이 수행되면 패킷은 응답으로 인식되고 대상 주소가 다시 변경됩니다 10.199.115.146. 패킷은 eth1최종 목적지로 라우팅됩니다.
  • 머신 B는 이를 응답 패킷으로 인식합니다. 핑 성공.

사례 3: 핑 10.199.115.146

  • 내가 제안한 규칙이 없으면 원본 패킷이 인터넷으로 전송되어 손실됩니다. 그렇지 않으면 10.1.1.2소스 주소 = 인 경로 로 전송됩니다 10.1.1.1.
  • F 머신은 패킷을 수신하고 이를 통해 라우팅합니다 eth1.
  • B는 패킷을 수신하고 에게 응답을 보냅니다 10.1.1.1.
  • 회신은 을(를) 통해 라우팅됩니다 tun0. 이 MASQUERADE규칙은 소스 주소를 로 변경합니다 10.1.1.2.
  • 10.1.1.2기계 A는 (원래 목적지가 아닌) 로부터 응답을 받고 관련 없는 것으로 간주하여 버립니다. 핑 실패

보시다시피, 내부 네트워크에서 VPN에 컴퓨터를 연결하는 방법에는 두 가지가 있습니다.

  • 공개 라우팅: 두 네트워크 모두 서로의 IP 주소를 알고 있으며 이를 조회하기 위한 특정 라우팅 테이블 항목이 있습니다(제가 보여드린 것처럼).
  • SNAT/MASQUERADE: 오직 하나의 네트워크만이 다른 네트워크에 도달하는 방법을 알고 있으며 방화벽은 해당 네트워크에서 나가는 패킷의 소스 IP 주소를 방화벽 자체 IP(다른 네트워크에 알려진)로 변경합니다.

둘 중 하나를 사용하지 마십시오. SNAT/MASQUERADE가 사용되는 경우 개인 네트워크의 패킷은 원래 주소를 소스로 사용하지 않으므로 외부 호스트의 라우팅 테이블이 적용되지 않습니다.

PUBLIC_IP10.1.1.1B 에서 시스템 A에 액세스할 수 있는지 여부를 사용하거나 선택할 수 있습니다 . 두 가지 모두 작동하도록 방화벽을 구성하는 것이 가능할 수도 있지만 노력할 가치는 없을 것입니다.

관련 정보