Linux iptables ssh 포트 전달(화성 거부)

Linux iptables ssh 포트 전달(화성 거부)

홈 네트워크에 대해 NAT를 수행하는 Linux 게이트웨이가 있습니다. 패킷을 특정 IP/포트(즉, VPN이 아님)로만 투명하게 전달하려는 다른 네트워크가 있습니다. 다음은 사용할 수 있는 IP 및 포트의 몇 가지 예입니다.

Source          Router          Remote Gateway     Remote Target
192.168.1.10 -> 192.168.1.1 ->  1.2.3.4        ->  192.168.50.50:5000

나는 소스 머신이 마치 라우터에서 직접 라우팅될 수 있는 것처럼 원격 대상의 특정 포트와 통신할 수 있기를 원합니다. 라우터에서 eth0은 개인 네트워크이고 eth1은 인터넷 연결입니다. 원격 게이트웨이는 SSH를 통해 연결할 수 있는 또 다른 Linux 시스템이며 원격 대상으로 직접 라우팅할 수 있습니다.

제가 시도한 간단한 해결책은 라우터에서 SSH 포트 전달을 설정하는 것이었습니다. 예를 들면 다음과 같습니다.

ssh -L 5000:192.168.50.50:5000 1.2.3.4

이는 이제 포트 5000에 로컬로 연결할 수 있는 라우터에 적합합니다. 따라서 "telnet localhost 5000"은 예상대로 192.168.50.50:5000에 연결됩니다.

이제 현재 설정된 SSH 터널을 통해 소스 및 유입경로의 트래픽을 리디렉션하고 싶습니다. 이에 대해 NAT 규칙을 시도했습니다.

iptables -t nat -D PREROUTING -i eth0 -p tcp -s 192.168.1.10 --dport 5000 -d 1.2.3.4 -j DNAT --to-destination 127.0.0.1:5000

라우터는 이미 내 NAT 게이트웨이이므로 필수 라우팅 후 규칙이 이미 있습니다.

-A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE

이 사이트나 다른 곳의 대부분의 Q&A에는 서버 포트 전달이나 헤어핀 NAT가 포함된 것 같습니다. 두 가지 모두 다른 곳에서는 잘 작동하는 것으로 보았지만 이 상황에는 적용되지 않습니다. 원격 게이트웨이를 통해 원격 대상 포트를 전달할 수는 있지만 인터넷에서 해당 포트에 액세스할 수 없도록 하고 보안 SSH 터널을 통해서만 액세스할 수 있기를 바랍니다.

내가 찾을 수 있는 가장 좋은 대답은 Linux 커널의 Martian 패킷 거부와 관련이 있습니다.

iptables, 루프백에서 포트를 리디렉션하는 방법은 무엇입니까?

Martian 로깅을 활성화했으며 커널이 이러한 패킷을 Martian으로 거부하고 있음을 확인했습니다. 하지만 그렇지 않습니다. 나는 이 패킷이 무엇을 위한 것인지, 어디서 왔고 어디로 가는지 정확히 알고 있습니다(내 SSH 터널).

거기에서 제안된 "로터리" 솔루션은 원래 문제에는 효과가 있었지만 제 경우에는 그렇지 않았습니다.

그러나 이 질문을 작성/조사하는 동안 다음과 같이 SSH 소스 IP 바인딩을 사용하여 문제를 해결했습니다.

ssh -L 192.168.1.1:5000:192.168.50.50:5000 1.2.3.4
iptables -t nat -D PREROUTING -i eth0 -p tcp -s 192.168.1.10 --dport 5000 -d 1.2.3.4 -j DNAT --to-destination 192.168.1.1:5000

루프백을 사용하지 않기 때문에 화성 거부를 피할 수 있습니다.

제가 이 질문을 여기에 게시하는 이유는 두 가지입니다.

  1. 나중에 비슷한 일을 하려는 사람이 검색에서 이를 찾을 수 있기를 바라며 이 해결 방법이 도움이 될 수 있습니다.
  2. 나는 여전히 ssh 포트 전달 연결을 루프백에만 바인딩하고 iptables를 통해 라우팅할 수 있다는 아이디어를 선호합니다. 이제 이 패킷이 무엇인지, 어디로 가는지 정확히 알았으니 Linux 화성 필터링이 거부하지 않도록 표시할 수 있는 방법이 있어야 합니까? 이 주제에 대한 모든 검색은 rp_filter로 이어지며 이는 테스트에 도움이 되지 않습니다. 작동하더라도 허용하려는 정확한 패킷에만 국한되는 것은 아닙니다.

나는 다른 사람들의 검색 시간을 절약하기 위해 일반 검색에 내 문제와 해결책을 제공하는 데 관심이 있습니다. 내가 한 일은 막다른 골목에 도달한 것 뿐이며 누군가 내 질문의 루프/화성 부분에 대답하기를 바랍니다. 머리 책.

답변1

DNATing 127.0.0.1:5000의 문제점은 원격 측이 응답할 때 이러한 패킷이 마치 로컬에서(127.0.0.1에서) 시작된 것처럼 라우팅 엔진으로 반환되지만 외부 대상 주소가 있다는 것입니다. 외부 인터페이스와 일치하는 SNAT/MASQUERADE는 이를 포착하여 다시 작성하지만, 먼저 해당 인터페이스로 패킷을 가져오도록 라우팅 결정을 내려야 하며 기본적으로 이러한 위조된 패킷을 허용하지 않습니다. 라우팅 엔진은 나중에 다시 작성해야 한다는 것을 보장할 수 없습니다.

당신이 할 수 있어야 하는 것은 !소스 주소 지정 앞의 매개변수를 사용하여 192.168.1.10으로부터의 연결을 제외하고 iptables INPUT에서 192.168.1.1:5000으로의 모든 외부 연결을 거부하는 것입니다. -s거부 메커니즘으로 TCP 재설정을 사용하는 경우( -j REJECT --reject-with tcp-reset기본 ICMP 대상에 연결할 수 없는 대신) 외부 세계에 관한 한 이는 해당 주소:포트 조합에서 아무것도 수신하지 않는 것과 거의 동일합니다.

답변2

openVPN을 사용하여 라우터에서 RemoteGateway까지의 터널을 생성하겠습니다.

그런 다음 라우터에 경로를 추가합니다.

경로 추가 호스트 RemoteTarget gw RemoteGateway-VPN 주소

간단한 iptables 규칙을 사용하여 소스가 액세스할 수 있는 포트를 제한하세요.

관련 정보