☰

질문

tag-icon • tag-icon iptables routing gateway
질문

내 홈 네트워크 설정을 설명하겠습니다.

          ┌────────────────────┐
          │      Internet      │
          │ Public IP: 1.2.3.4 │
          └──────────┬─────────┘
                     │
  ┌──────────────────┴─────────────────┐
  │             ISP Modem              │
  │  Forward everything to AP Router   │
  │            192.168.1.1             │
  └──────────────────┬─────────────────┘
                     │
   ┌─────────────────┴───────────────┐
   │             AP Router           │
   │         DHCP happens here       │
   │ Forward 1122 to 192.168.10.2:22 ├─────────────┐
   │           192.168.10.1          │             │
   └─────────────────┬───────────────┘             │
                     │                             │
                     │                             │
                     │                     ┌───────┴───────┐
                     │                     │ NUC (Ubuntu)  │
                     │                     │ PiHole + VPN  │
                     │                     │ 192.168.10.50 │
                     │                     └───────────────┘
                     │                             ▲
                     │                             │
┌────────────────────┴──────────────────┐          │
│            Desktop (Ubuntu)           │          │ Default routing
│              192.168.10.2             │          │
│    Default gateway: 192.168.10.50     ├──────────┘
│          DNS: 192.168.10.50           │
└───────────────────────────────────────┘

예를 들어 데스크톱이 192.168.10.1기본 게이트웨이로 사용되는 경우 SSH가 1.2.3.4:1122작동하며 SSH를 통해 데스크톱에 연결할 수 있습니다. 하지만 데스크톱을 192.168.10.50기본 게이트웨이 로 사용하고 싶습니다 . 이 경우 포트 전달이 작동하지 않습니다.

약간의 조사 후에 이것은 IP 테이블/정책 기반 라우팅으로 수행될 수 있지만 나는 그것에 대해 아무것도 모릅니다. 가장 쉬운 방법은 무엇입니까?

답변1

TL;DR(첫 번째 방법만 해당)

데스크탑에서:

ip route add 192.168.10.0/24 dev eth0 table 1000
ip route add default via 192.168.10.1 dev eth0 table 1000
ip rule add iif lo ipproto tcp sport 22 lookup 1000

질문

여기서 문제는 데스크탑에서 발생합니다.

다양한 레이아웃을 통해 NUC는 모든 트래픽을 안정적으로 차단할 수 있으므로 더 간단한 방법을 사용할 수 있습니다. 동일한 이더넷 LAN에 두 개의 IP LAN을 라우팅해도 DHCP와 같은 문제가 방지되지 않으므로 이를 위해서는 NUC에 두 개의 네트워크 장치가 있어야 합니다. NUC를 상태 저장 브리지로 사용하는 것도 두 개의 NIC가 필요한 또 다른 솔루션입니다.

현재 레이아웃에서는 NUC가 AP와 데스크톱 사이의 모든 트래픽을 가로챌 수 없습니다.

...해결책은 데스크탑에서 수행되어야 합니다.

리눅스를 사용할 수 있다정책 라우팅선택기는 패킷에 대해 다른 결과를 제공하는 데 사용됩니다(다른 라우팅 테이블을 사용하여). 명백하게 동일한 대상에 대해 여러 경로를 사용하는 것과 관련된 모든 문제에는 주로 소스를 기반으로 분리할 수 있는 선택기를 사용하는 정책 라우팅을 사용해야 합니다(여기서는 라우팅 테이블이 이미 대상을 구분하는 데 사용되었기 때문입니다).

데스크탑에 대한 SSH 연결과 관련하여 다른 결과(예: 다른 경로)를 생성할 수 있도록 AP에서 직접 들어오는 패킷과 NUC에서 들어오는 패킷을 어떻게든 분리해야 합니다.

사용할 수 없는 것으로 보이는 것은 ip rule해당 경로가 사용된 게이트웨이와만 다른 경우 두 경로를 통해 도착하는 두 패킷을 구별할 수 있는 선택기입니다. Linux의 정책 규칙은 이를 포착하지 못하는 것 같습니다. 동일한 인터페이스에서 나오는 한 동일합니다.

나는 다음과 같이 가정한다:

  • 데스크톱 네트워크 인터페이스는 다음과 같습니다.이더넷 0.
  • 데스크탑은 라우터(예: libvirt, LXC, Docker)가 아닙니다. 라우팅에는 수행해야 할 작업에 대한 더 많은 구성과 선택이 필요합니다(VM이 NUC 또는 AP에서 SSH를 수신해야 합니까?). 아래 답변에서는 라우팅 사례에 대한 예외를 올바르게 생성하기 위해 약간의 조정이 필요합니다. 그렇지 않으면 컨테이너/VM이 기본 경로(예: NUC를 통해)를 따릅니다.

여기에는 두 가지 방법이 있습니다.

정책 라우팅은 레이어 4 프로토콜(TCP 포트 22)과 일치합니다.

~부터리눅스 4.17선택기를 사용하여 TCP 포트 22의 정책 라우팅을 일치시킬 수 있습니다. 그러면 다른 경로를 이용하는 것이 쉽습니다. 패킷 소스를 다르게 처리하는 대신 이 특정 포트를 다르게 처리하십시오.

ip route add 192.168.10.0/24 dev eth0 table 1000
ip route add default via 192.168.10.1 dev eth0 table 1000
ip rule add iif lo ipproto tcp sport 22 lookup 1000

iif lo실제로는 그렇지 않습니다루오인터페이스이지만 특정 문법적 의미로컬 시스템에서. LAN 경로도 복제되어야 합니다. 예를 들어 NUC 자체의 SSH 연결은 AP를 통해 응답하고 구성 오류를 알리기 위해 ICMP 리디렉션을 발행합니다. 이 특정한 경우에는 동일한 인터페이스이므로 수신된 패킷에 대한 대체 경로를 지정하는 규칙이 필요하지 않습니다. 다른 인터페이스인 경우SRPF할 수 있게 하다 (rp_filter=1)은 규칙의 실제 다른 인터페이스로 ip rule add iif eth0 ipproto tcp dport 22 lookup 1000대체되며 기본 경로도 필요합니다.eth0

이것은 목표를 달성하는 데 3개의 명령만 필요한 매우 간단한 방법입니다.

VPN이 들어오는 트래픽을 허용하는 경우 일부 특정 LAN에서 SSH를 수신하거나 NUC에서 주소 블록을 수신하도록 조정할 수 있지만 어떤 경우에도 두 IP를 사용하는 동일한 공용 IP에서 허용되지 않습니다. 소스는 대상을 지정하는 동안 SSH 연결을 허용합니다. /노선.

AP의 MAC 주소와 태그를 이용한 정책 라우팅

이전 방법과 달리 들어오는 패킷을 NUC가 아닌 AP 게이트웨이에서 오는 것으로 식별하는 간접적인 방법, 즉 이더넷 소스 MAC 주소가 있습니다.

이는 정책 라우팅에서 직접 사용할 수 없지만 방화벽 태그를 사용하여 들어오는 패킷을 표시할 수 있습니다. 표시할 수 있는정책 라우팅에 사용되며 응답 패킷에 이 표시를 설정하는 방법에는 여러 가지가 있습니다.

들어오는 부분과 응답하는 부분을 분리하겠습니다. 이는 특정 유형의 수신 트래픽에 종속되지 않으므로 나중에 AP에서 데스크탑으로 전달되는 다른 포트를 처리하기 위해 변경할 필요가 없습니다.

나는 다음을 가정할 것이다:

  • AP의 MAC 주소(ping 후 데스크탑에 표시됨 ip neigh show 192.168.10.1)의 값은 02:00:00:ac:ce:55입니다. 아래에서 이 값을 바꾸세요.

수신 및 공통 설정

사람들은 Netfilter가 어떻게 작동하는지 봐야 합니다.iptables라우팅과 상호작용이 다이어그램:

일반 네트워크의 Netfilter 및 패킷 흐름

하나iptablesraw/PREROUTING의 규칙은 패킷을 표시합니다. 그런 다음 이전과 비슷한 방식으로 정책 라우팅을 통해 수행됩니다.

iptables -t raw -A PREROUTING -i eth0 -m mac --mac-source 02:00:00:ac:ce:55 -j MARK --set-mark 1

ip route add default via 192.168.10.1 table 1000 
ip rule add fwmark 1 lookup 1000

회신하다

답글을 처리하는 방법에는 두 가지가 있습니다.

  • 간단하고 자동적입니다., TCP 전용

    TCP에서만 사용할 수 있으며 UDP를 포함한 다른 프로토콜에서는 사용할 수 없습니다.

    대상은 TCP 포트 22이므로 OP의 경우에는 이것으로 충분합니다. 그냥 완료들어오는부분:

    sysctl -w net.ipv4.tcp_fwmark_accept=1
sysctl -w net.ipv4.fwmark_reflect=1

    설명하다:

    • tcp_fwmark_accept

      TCP당소켓SO_MARK새 연결을 수락할 때 생성된 소켓 옵션은 이 연결에만 소켓 옵션이 사용된 것처럼 첫 번째 패킷의 플래그를 상속합니다 . 특히 여기에서 플래그가 설정되면 라우팅 테이블 1000을 사용하여 모든 응답 트래픽이 들어오는 트래픽이 도착한 동일한 게이트웨이를 통해 다시 라우팅됩니다.

    • fwmark_반사

      비슷한 방식으로 커널에서 직접 처리되는 응답 패킷(예: ICMP 에코 응답 또는 TCP RST 및 일부 TCP FIN 경우)은 들어오는 패킷의 태그를 상속합니다. 예를 들어 TCP 소켓 수신이 없는 경우(예: 데스크톱의 SSH 서버가 중지된 경우) 이런 일이 발생할 수 있습니다. 이 플래그가 없으면 AP를 통한 SSH 연결 시도가 연결되는 대신 시간 초과됩니다.연결이 거부되었습니다.TCP RST는 NUC를 통해 라우팅되고 원격 클라이언트에서는 무시되기 때문입니다.

    혹은 그 반대로도...

  • 일반가공환승으로표시패킷과연결하다답글 입력 및 반환가방

    ㅏ표시로 기록될 수 있다코맥안에연결하다이를 mangle/OUTPUT에 다시 복사하여 스트림의 다른 모든 패킷(응답 패킷 포함)에 영향을 미치도록 합니다.연결하다도착하다표시. 마치다들어오는부분:

    iptables -t mangle -A PREROUTING -m mark --mark 1 -j CONNMARK --set-mark 1
iptables -t mangle -I OUTPUT -m connmark --mark 1 -j MARK --set-mark 1

    이는 모든 경우(TCP RST 및 UDP 포함)를 처리합니다. 따라서 들어오는 TCP 또는 UDP 트래픽을 데스크탑으로 전달하도록 AP를 구성할 수 있습니다.이 블로그의 다른 문서.

다양한 종류

지침

  • 주소가 제거된 후 다시 추가되거나 인터페이스가 중단된 후 활성화되면 수동으로 추가된 관련 경로가 제거되고 다시 나타나지 않습니다. 따라서 수동 ip route명령은 최소한 네트워크 연결이 설정될 때마다 추가되도록 데스크톱 네트워킹을 구성하는 도구와 통합되어야 합니다.

  • 각 도구에는 고급 네트워크 구성에 대한 서로 다른 접근 방식이 있으므로 완전하지 않을 수 있습니다. 예를 들어 우분투네트워크 계획routing-policy또는를 사용할 수 있는 경우 iif lo해당 설정에 문서화되지 않습니다 ipproto tcp sport 22. 사용할 수 없는 기능을 대체하기 위해 사용자 정의 스크립트를 사용할 수 있는 도구를 선호해야 합니다(예:ifupdown또는NetworkManager이것을 할 수 있습니다).

  • Nitpicking: VPN이 들어오는 트래픽을 허용하는 경우 단일 원격(공용) IP 주소가 두 개의 경로(두 개의 다른 공용 IP 주소로 간주됨)를 사용하여 동일한 데스크톱 서비스에 두 번 연결되는 마지막 방법을 사용하는 매우 복잡한 경우, 두 대상 모두에 동일한 소스 포트를 사용하면 데스크톱에 동일한 트래픽이 두 번만 표시되고 혼란스러워집니다(두 개의 UDP가 병합되고 두 번째 TCP가 실패함). 이는 일반적으로 라우팅 시간에 처리될 수 있습니다(다음을 사용).연결 영역및/또는 자동으로연결하다소스 포트 변경)은 여기 호스트 상황에서 이 문제를 처리하지 못할 수도 있습니다.

보너스

데스크탑이 실제로 라우터라면 태그와 CONNTRACK을 사용하는 마지막 방법을 변경해야 합니다. 컨테이너에 대한 경로는 테이블 1000에 복사되어야 합니다. 이는 작동하지만 Docker에서는 테스트되지 않았습니다(추가 문제가 발생할 수 있음).

여기서는 다음과 같이 가정합니다.

  • 데스크톱은 다음과 같은 인터페이스를 통해 LAN 172.17.0.0/16의 NATed 컨테이너를 라우팅합니다.br0(Docker는도커 0기본 네트워크의 경우) 로컬 IP 주소는 172.17.0.1/16입니다.
  • 데스크탑 DNAT는 특정 포트를 이러한 컨테이너로 연결합니다.

다양성:

  • 규칙과 경로

    컨테이너에 대한 경로는 기본 라우팅 테이블에서 테이블 1000으로 복사되어야 합니다. 컨테이너/가상화 도구가 새 인터페이스와 경로를 동적으로 추가하는 경우 테이블(1000)에도 추가하려면 새 경로를 수동으로 추가해야 합니다(또는 도구의 일부 API에 의해 트리거되는 일부 스크립트 메커니즘을 사용하여).

    ip route add 172.17.0.0/16 dev br0 table 1000

    이것이 없으면 AP를 통해 들어오는 연결과 표시된(다음 글머리 기호에 있음)이 라우팅됩니다.뒤쪽에AP 통신에.

  • MAC 주소에 대한 이전 규칙 유지날것의테이블.

  • 이전 규칙 삭제으깨다테이블

    iptables -t mangle -F

  • 이 규칙을 다음과 같이 변경하세요.

    iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j CONNMARK --save-mark
iptables -t mangle -A PREROUTING -m connmark ! --mark 0 -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -m connmark ! --mark 0 -j CONNMARK --restore-mark

    (이 단일 마커의 경우 더 많은 동작을 희생하면서 일부 최적화를 수행할 수 있습니다)

    첫 번째 PREROUTING 규칙은 conntrack 표시가 0 값의 패킷 표시로 덮어쓰여지지 않도록 보장합니다. 두 번째 PREROUTING 규칙은 원래 AP를 통해 설정된 흐름의 컨테이너(개별 패킷은 초기에 태그가 지정되지 않음) 부분에서 라우팅된 트래픽에 대한 표시를 설정합니다.

관련 정보