☰

iptables / 원래 인터페이스(eth0)에서 들어오는 트래픽을 반환하기 위한 경로

tag-icon • tag-icon linux iptables raspberry-pi firewall vpn
iptables / 원래 인터페이스(eth0)에서 들어오는 트래픽을 반환하기 위한 경로

방금 Linux/IPTABLES를 다루기 시작했고 이 훌륭한 튜토리얼을 따랐습니다.여기RaspBerry Pi 장치(RaspBerryPi OS/Debian 실행)를 VPN 게이트웨이로 성공적으로 설정했습니다. 동일한 네트워크에 있는 모든 장치는 수동으로 네트워크 설정을 구성하고 해당 장치의 IP 주소로 라우팅을 설정할 수 있습니다. 그러면 장치는 VPN을 통해 정보를 처리하고 다시 보냅니다(모두 동일한 네트워크에서).이더넷 0상호 작용).

내가 가진 문제는 VPN 소프트웨어에 있습니다.Linux용 NordVPN삭제Tun0VPN 연결을 끊거나 로그아웃하면 인터페이스가 자동으로 연결되어 노트북의 인터넷이 더 이상 작동하지 않게 됩니다. 내가 이해한 바에 따르면 이는 패킷이 여전히 전달하라는 지시를 받고 있기 때문입니다.Tun0인터페이스가 없으면 이러한 패킷은 랩톱으로 반환될 수 없습니다.

들어오는 모든 트래픽을 단순히 반환하는 이상적인 프로그램은 무엇입니까?이더넷 0로 돌아가이더넷 0언제Tun0존재하지 않는다?

구조:

예를 들어:노트북 → raspBerry pi(eth0 > tun0 > eth0) → 노트북

RaspBerry Pi의 iptables는 다음과 같습니다.

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

sudo iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

sudo iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

sudo iptables -A INPUT -i lo -j ACCEPT

sudo iptables -A INPUT -i eth0 -p icmp -j ACCEPT

sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

sudo iptables -P FORWARD DROP
sudo iptables -P INPUT DROP

지금까지의 연구를 통해 다음과 같은 몇 가지 답변을 얻을 수 있었습니다.

https://unix.stackexchange.com/a/322386

항상 트래픽이 시작된 인터페이스 밖으로 트래픽을 전달합니다.

아마도 다음과 같을 것입니다: ( ip route add table 2 default via 192.168.0.1내 메인 라우터의 IP 주소?) 하지만 아직 시도하지 않았으며 이것이 내가 가야 할 방향인지 완전히 확신할 수 없습니다.

답변1

일반적인 오해를 바로잡으세요:iptables라우팅되지 않았습니다. 라우팅 흐름이 계속되도록 허용되는지 여부만 제어할 뿐 방향은 변경하지 않습니다(변경할 수 있는 NAT와 같은 것을 사용하지 않는 한).라우팅운명은 여전히 ​​라우팅 스택에 의해 수행됩니다. 그렇기 때문에 질문에서 가장 중요한 것은 경로와 라우팅 테이블을 제공하는 것입니다(이 경우에는 라우팅 규칙도 제공해야 하는 것처럼 보입니다).

터널 인터페이스가 사라지면 이를 사용하는 모든 경로도 사라집니다. 단일 인터페이스에서 라우터 경로를 얻을 수 있습니다. 수신 인터페이스는 송신 인터페이스이기도 합니다.이더넷 0.

기본 정책은 전달된 패킷을 삭제하는 것이므로 iptables를 사용하여 이 흐름을 활성화하면 됩니다.

sudo iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT

그게 당신이 필요한 전부입니다. 일반적으로 RPi에는 192.168.0.1 라우터를 사용하도록 기본 경로가 설정되어 있으므로 추가 작업이 필요하지 않습니다. 경로가 표준이 아닌 경우 질문에 추가하고 이 답변을 업데이트해야 합니다.

다음은작은 글씨:

  • 호스트 노드가 RPi를 통해 패킷을 보내면 RPi는 이것이 최선의 경로가 아님을 감지하고 일부 패킷을 다시 보냅니다.ICMP 리디렉션패킷은 192.168.0.1을 통해 직접적으로 더 직접적인 경로를 사용할 수 있음을 클라이언트에게 경고합니다. 노드는 정보를 캐시하고 다음 패킷을 해당 라우터로 직접 보내도록 선택하거나 RPi를 계속 사용할 수 있으며 RPi는 관계없이 계속해서 패킷을 전달할 수 있습니다. 실제 라우터는 응답을 호스트 노드로 직접 다시 보내 비대칭 라우팅을 생성합니다. 이 모든 작업은 동일한 LAN에서 발생하므로 동일한 인터페이스이므로 문제가 없으며 이와 같은 현상이 발생하지 않습니다.엄격한 역방향 경로 전달어딘가에.

  • 따라서 이 경우 추가 conntrack 규칙을 사용하면 안 됩니다(기존 규칙으로 충분함). -m conntrack --ctstate NEW,ESTABLISHED모든 패킷과 동일하지 않습니다.연결하다RPi를 우회하는 패킷으로 인해 창 밖 TCP 패킷이 발생하며 이러한 패킷은 INVALID로 표시됩니다(그러나 전달이 허용되어야 함).

답변2

나는 이 대답을 싫어하지만 여기 있습니다. 보다 "클래식" openVPN 기반 NordVPN 연결을 사용하고 있는 것으로 보입니다. wireguard터널 형식이 가능하다는 사실을 알고 계셨나요 ?

귀하의 연결은 ethertap이 아닌 터널이므로 연결이 아마도 좋은 선택일 것입니다.

혜택:

  • 터널이 닫혀도 터널 장치(여기서는 wg0)가 떨어지지 않을 것 같습니다.
  • "이것을 할 것인지, 아니면 이것을 사용할 것인지" 유형의 라우팅(및 DNS) 결정은 와이어가드 설정의 일부로 간단하게 구성될 수 있습니다.

저는 '그 사람'이 되고 싶지 않아서 그렇게 보일 수도 있어서 미안해요. NordVPN을 새로운 연결로 시작하는 경우, 이는 다른 옵션을 살펴보고 여전히 openVPN 설정이 최선의 옵션이라고 결정했는지 확인할 수 있는 좋은 기회입니다. VTun(James가 openVPN에서 구현한 것을 구현하고 싶지 않았기 때문에 떠난 상위 프로젝트) 대신 WG를 사용하기 시작한 지 얼마 지나지 않아 WG가 OpenVPN만큼 구성하기 쉽다는 것을 알았습니다. 빠르고 신뢰할 수 있는 터널 세트를 제공합니다.

그렇긴 하지만, 저는 멀티홈 에이전트 봇이 "자신들이 들어온 것과 동일한 인터페이스에서 반환 패킷을 보내도록" 구성을 설정했습니다. 이는 기본적으로 이 작업을 수행하는 Windows와 달리 커널 자체에서는 일반적으로 그렇지 않기 때문에 Linux에서는 어려운 일이었습니다. 패킷이 어떻게 들어왔는지 기억이 나지 않습니다. iproute 트릭을 사용하여 패킷을 속여야 합니다. 약 10년 전(CentOS6 초기)에 처음으로 상자를 설정했을 때의 메모를 찾을 수 있는지 살펴보겠습니다.

관련 정보