☰

호스트로 가는 경로는 없지만, 특정 포트에 대한 인터페이스로 가는 경로는 있습니다.

tag-icon • tag-icon iproute wireguard
호스트로 가는 경로는 없지만, 특정 포트에 대한 인터페이스로 가는 경로는 있습니다.

서버 A가 다른 서버 B에 대한 VPN으로 구성되어 있습니다. 현재 서버 A는 VPN 주소를 사용하여 서버 10.12.0.1B를 ping할 수 있습니다.

모든 HTTPS 트래픽을 서버 B를 통해 라우팅하고 다른 트래픽이 기본 인터페이스를 사용하도록 하고 싶습니다.

이를 위해 나는 영감을 받았습니다.이 유닉스 스택 교환 답변그리고 다음 명령을 실행하세요:

# define route
echo "200 myroute" >> /etc/iproute2/rt_tables
# seems necessary
sysctl -w net.ipv4.conf.wg1.rp_filter=2
# actual routing
ip route add table 200 10.12.0.0/24 dev wg1 src 10.12.0.10
ip route add table 200 default via 10.12.0.1
# actual rule telling HTTPS traffic to use table 200
ip rule add iif lo ipproto tcp dport 443 lookup 200

curl https://1.1.1.1그런 다음 (또는 다른 호스트를) 실행하면 오류가 발생합니다 Failed to connect to 1.1.1.1 port 443: No route to host. 규칙을 제거하면 모든 것이 정상으로 돌아갑니다.

테이블 200에 대한 내 경로가 잘못된 것 같지만 원래 답변의 경로와 기본 인터페이스의 경로가 일치하는 것 같습니다.

이 문제를 조사하고 디버깅할 수 있는 방법을 알고 계십니까?

감사해요

추가 정보:

$ ip route show table 200
default via 10.12.0.1 dev wg1 
10.12.0.0/24 dev wg1 scope link src 10.12.0.10 

$ ip route show dev wg1
10.12.0.0/24 proto kernel scope link src 10.12.0.10

$ ip route get 1.1.1.1 ipproto tcp dport 443
1.1.1.1 via 10.12.0.1 dev wg1 table 200 src 10.12.0.10 uid 1001 
    cache 

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
10.12.0.0/24 dev wg1 proto kernel scope link src 10.12.0.10 
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202

VPN은 Wireguard VPN입니다. VPN을 통해 모든 트래픽을 라우팅하도록 구성하면 모든 것이 잘 작동합니다.

답변1

1.1.1.1WireGuard 설정에 포함되지 않은 호스트() 에 연결을 시도하면 "호스트에 대한 경로 없음" 오류가 발생할 수 있습니다 AllowedIPs. wg-quick을 사용한다고 가정하고 다음을 수행하십시오.

~처럼1 단계, 서버 A의 WireGuard 구성에서 연결하려는 IP 주소(또는 IP 주소 블록)를 포함하도록 서버 B 섹션 AllowedIPs의 설정을 조정합니다.[Peer]

서버 A에서 블록의 모든 HTTPS 서버(특히 테스트 중인 서버) 1.1.1.1에 연결할 수 있다고 가정해 보겠습니다 . 또한 이 블록을 포함하는 서버 B에 대해 서버 A에서 초기 설정을 구성했다고 가정합니다 . 이 설정을 다음으로 변경합니다.192.0.2.0/24192.0.2.123AllowedIPs10.12.0.0/24

AllowedIPs = 10.12.0.0/24, 192.0.2.0/24

테이블 200에 대해 서버 A에서 이전에 설정한 경로와 규칙을 삭제하고 WireGuard를 다시 시작한 후(예: sudo wg-quick down wg1; sudo wg-quick up wg1) 다음 명령을 실행하여 이 변경 사항을 테스트합니다.

$ curl -k https://192.0.2.123

최소한 "호스트에 대한 경로 없음" 오류를 제거해야 합니다. 여전히 오류가 발생하는 경우 서버 B에서 방화벽/라우팅 규칙을 조정하여 서버 A에서 로 패킷을 전달할 수 있도록 해야 할 수 있습니다 192.0.2.0/24.

~처럼2 단계[Interface], 서버 A의 WireGuard 구성 섹션 에서 다음 설정을 추가합니다.

Table = 200

그러면 wg-quick이 자동으로 생성한 경로를 기본 200테이블 대신 사용자 지정 경로 테이블에 추가하도록 지시합니다. WireGuard를 다시 시작하고 라우팅 테이블을 확인하세요.

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.51 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.51 metric 202
$ ip route show table 200
10.12.0.0/24 dev wg1 scope link
192.0.2.0/24 dev wg1 scope link

이제 특별한 HTTPS 정책 규칙을 추가하세요.

$ sudo ip rule add iif lo ipproto tcp dport 443 lookup 200

테스트해 보세요.

$ curl -k https://192.0.2.123

~처럼3단계, HTTPS 이외의 서비스(예: SSH 등)에 대해 WireGuard를 통해 서버 A에서 서버 B로 직접 연결할 수 있다고 가정하면 블록에 대한 모든 연결에 대해 서버 A에 다른 정책 규칙을 추가합니다 10.12.0.0/24.

$ sudo ip rule add to 10.12.0.0/24 table 200 priority 201

이제 WireGuard를 사용하여 서버 A에서 서버 B로 다시 연결할 수 있습니다.

$ ssh 10.12.0.1

관련 정보