원격 사용자가 VPN 허브를 거쳐 두 번째 사이트에 도달하지 못하는 이유

원격 사용자가 허브에 연결해 허브 자체 LAN의 파일 서버에는 도달하고, 모든 것이 정상으로 보입니다. 그다음 본사의 10.20.0.50 공유를 열면 허브는 별도의 사이트 간 터널로 거기에 도달해야 하는데 시간이 초과됩니다. 두 터널 모두 올라와 있고 두 카운터 모두 증가하므로 어느 터널도 고장 나지 않았습니다. 허브를 지나는 것은 세 장치에서의 세 가지 라우팅 결정이며, 터널은 자신이 구축된 대상 프리픽스만 전달합니다. 제가 확인하는 순서와 각 단계가 성립하는지 보여 주는 명령은 다음과 같습니다.

통과에는 세 번의 조회가 필요하며 터널 하나로는 부족합니다

모든 장치는 스스로 최장 프리픽스 일치를 수행하고 그 결과를 잊습니다. 노트북은 10.20.0.50을 로컬 라우터가 아니라 터널로 보내야 합니다. 허브는 원격 접속 인터페이스로 들어온 패킷을 받아 사이트 간 인터페이스로 넘겨야 합니다. 본사는 사용자 주소에 대한 응답을 터널을 통해 되돌려 보내야 합니다. 세 가지 중 하나만 실패해도 브라우저에서는 똑같이 보입니다. 침묵입니다.

그래서 각 터널을 따로 시험하는 것으로는 증명되는 것이 거의 없습니다. 허브의 LAN 주소로 핑을 하면 첫 번째 결정을 시험하고, 본사에서 허브로 핑을 하면 세 번째를 시험합니다. 실패하는 패킷은 출발지가 사용자 풀이고 목적지가 두 번째 사이트이므로, 먼저 그 프리픽스를 적어 두십시오. 여기서 풀은 10.80.0.0/24, 허브 LAN은 10.10.0.0/24, 본사는 10.20.0.0/24입니다.

원격 프리픽스를 원격 클라이언트로 밀어 넣기

하나의 OpenVPN 원격 접속 서버에서는 클라이언트가 연결할 때 경로를 학습합니다. push가 없으면 분할 터널 클라이언트는 10.20.0.50을 자기 게이트웨이로 보내고 패킷은 터널에 들어가지 않습니다.

push "route 10.20.0.0 255.255.255.0"

밀어 넣은 경로는 클라이언트가 연결할 때 적용되므로, 온라인 상태를 유지하는 사용자는 다시 연결할 때까지 아무것도 보지 못합니다. 클라이언트에서 확인하십시오. Linux에서는 ip route get 10.20.0.50, Windows에서는 route print입니다. 출력에는 터널 인터페이스 이름이 있어야 합니다.

push는 허브에 도움이 되지 않습니다. 이것은 클라이언트에 보내는 메시지이며 서버의 경로도, 전달 허가도 아니므로 완벽한 push 줄을 가진 허브도 한 홉 뒤에서 흐름을 떨어뜨립니다. 사람들이 push가 실패했다고 결론짓는 흔한 이유가 이것입니다.

허브에 실제 출구 경로를 주기

허브에는 본사 프리픽스에 대한 자체 다음 홉이 필요합니다. 라우팅된 터널에서는 사이트 간 인터페이스를 지나는 평범한 경로이고, 명령 하나가 선택된 경로와 선택된 출발지를 함께 보여 줍니다.

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

사이트 간 구간 자체가 OpenVPN이면 경로는 그 구성 안에 피어의 터널 주소를 게이트웨이로 두고 살 수 있습니다. route 10.20.0.0 255.255.255.0 172.30.0.2. 게이트웨이는 선택 사항이 아닙니다. 생략하면 다음 홉이 구현의 기본값으로 떨어지는데, 단일 원격 클라이언트와 다중 피어 허브에서 서로 다릅니다.

정책 기반 IPsec은 다릅니다. 허브의 커널은 패킷을 평소 LAN 게이트웨이로 보내고 정책이 나가는 길에 그것을 잡으므로, 터널 경로는 아무것도 하지 않거나 정책을 우회해 트래픽을 보냅니다. 위 명령의 출발지를 보십시오. 풀 주소 대신 10.10.0.1이면 커널이 원격 측이 거부할 주소를 고른 것입니다. iroute도 답이 아닙니다. 이것은 서버에 어느 클라이언트가 자기 터널 뒤의 서브넷을 소유하는지 알려 줄 뿐, 세 번째 사이트로 트래픽을 어디로 보낼지는 알려 주지 않습니다.

원격 측을 사용자 풀까지 확장하기

본사는 이미 허브 LAN인 10.10.0.0/24를 포함합니다. 사용자 풀은 두 번째 프리픽스이며 선택자에도 있어야 합니다. 그렇지 않으면 10.80.0.25로 보내는 응답을 포함하는 정책이 없습니다. 각 피어는 같은 쌍의 프리픽스 집합을 자기 측에서 지정합니다.

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

한 장치의 local_ts는 다른 장치의 remote_ts입니다. 허브 블록을 본사에 복사하면 쌍이 뒤집히므로 자식 SA는 결코 올라오지 않습니다.

더 오래된 ipsec.conf 구문은 쉼표로 구분된 leftsubnet을 사용합니다. 실행 중인 보안 연합은 협상한 선택자를 유지하므로 편집 후 터널을 다시 설정하십시오. 10:00에 바꾼 선택자를 09:40에 올라온 SA에 대해 시험해도 여전히 실패하며, 그동안 구성 파일은 계속 올바르게 보입니다.

다음으로 마지막 홉을 확인하십시오. 원격 엔드포인트에서 ip route get 10.80.0.25이 터널을 가리켜야 합니다. 서비스가 LAN 라우터를 기본 게이트웨이로 쓰면 그 라우터에도 반환 경로가 필요하고, 없으면 응답은 거기서 죽습니다. 그 세그먼트에서 tcpdump -ni eth1 host 10.80.0.25을 실행하면 응답이 엔드포인트를 떠났는지 알 수 있습니다.

허브에서 흐름 허용하기

전달이 켜져 있고 경로가 허용되어야 합니다. 인터페이스 사이의 모든 것을 받아들이는 대신 규칙을 두 프리픽스로 좁히십시오.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

역경로 필터링은 그 옆의 조용한 실패입니다. 두 구간이 서로 다른 인터페이스에 있으면 rp_filter=1이 응답을 떨어뜨릴 수 있는데 허용 규칙의 카운터는 전혀 움직이지 않습니다. 시도 전후로 iptables -vnL FORWARD을 비교하십시오. 전혀 늘지 않는 규칙에는 도달하지 못하는 것이므로, 다시 쓰는 대신 한 계층 아래를 보십시오.

한 그룹만 통과가 필요하면 전역 push를 넓히는 대신 client-config-dir 아래의 클라이언트별 파일에 경로를 두십시오. 허브의 출발지 NAT도 원격 측 반환 경로의 필요를 없애지만 사용자 주소를 숨기므로, 원격 사이트의 로그와 주소 기반 규칙은 사용자를 구분하지 못하게 됩니다.

클라이언트에서 확인한 뒤 역순으로 롤백하기

ICMP만이 아니라 TCP 포트를 시험하십시오. 핑은 통과해도 서비스는 막혀 있을 수 있습니다. 클라이언트에서 nc -vz 10.20.0.50 445과 traceroute -n 10.20.0.50은 두 번째 홉이 허브의 터널 주소인지 보여 줍니다. 허브에서는 tcpdump -ni tun0 host 10.20.0.50과 사이트 간 인터페이스의 같은 필터입니다. 양쪽에 요청이 있고 어느 쪽에도 응답이 없으면 문제는 원격 측으로 옮겨 갑니다.

다음으로 막힌 채로 남아야 하는 것을 시험하십시오. 풀이 결코 도달해서는 안 되는 호스트도 응답한다면 통과 이상으로 열어 둔 것이므로 규칙을 좁혀야 합니다. 모든 것을 모든 스포크로 전달하는 허브는 첫 시험을 통과하고 두 번째에서 실패합니다.

롤백 목록을 유지하십시오. 네 개의 객체가 바뀌었고 그중 셋은 잊기 쉽습니다. 밀어 넣은 경로, 허브의 경로, 선택자, 방화벽 규칙입니다. 역순으로 되돌리고 SA를 다시 설정하고 사용자 한 명이 다시 연결하게 하십시오. 부분 롤백은 더 이상 일치하지 않는 터널을 가리키는 경로를 남기며, 그것은 원래의 침묵보다 읽기 어렵습니다. OpenVPN 2.6 설명서 는 사용 중인 버전의 push, route, iroute을 문서화합니다.