사이트 간 VPN 에 두 번째 서브넷 추가하기: 두 가지 경로

작동 중인 사이트 간 터널에 두 번째 서브넷을 추가하는 일은 한 설계에서는 오 분, 다른 설계에서는 거의 반나절이 걸립니다. 터널이 지정한 프리픽스에 경로를 설치하면 경로를 하나 추가하는 것으로 트래픽이 따라옵니다. 고정된 선택자 쌍 하나를 협상하면, 양쪽이 일치하는 쌍에 합의할 때까지 새 프리픽스는 보호되지 않습니다. 세 가지가 판단을 가릅니다. 각 측 구성이 실제로 무엇을 기술하는지, 협상된 트래픽이 가장 작은 일치 쌍으로 좁혀지는지, 새 대역의 반환 경로를 누가 갖는지입니다.

상태 라벨이 아니라 커널을 읽으십시오

연결됨을 보고하는 터널도 자식 연결을 하나 이상 설치했을 뿐이며, 기대한 것이 아닐 수 있습니다. Linux 에서 커널은 적용된 내용을 보여 줍니다. ip xfrm policy 은 선택자 쌍을 나열하고, swanctl --list-sas (또는 오래된 ipsec statusall) 은 양쪽이 협상한 내용을 방향별 트래픽 선택자와 함께 보여 줍니다. 새 프리픽스가 둘 다에 없으면 구성 파일이 무엇이라 해도 보호되지 않습니다.

경로 테이블과 비교해 보십시오. 경로 기반 구성에서 터널 장치는 보호된 프리픽스의 다음 홉입니다. 정책 기반 구성은 원격 서브넷에 대한 전용 경로가 없는 경우가 많고 기본 경로만 있으며, 트래픽을 고르는 것은 테이블이 아니라 정책입니다.

정책 기반 터널: 양쪽이 새 프리픽스를 나열해야 합니다

strongSwan 용어로 선택자는 자식 구성의 local_ts 과 remote_ts 에 있고, leftsubnet 와 rightsubnet 의 후속입니다. 새 프리픽스는 양쪽에 거울처럼 나타나야 하며, 사이트 A 가 로컬이라 부르는 것을 사이트 B 는 원격이라 부릅니다. 불일치는 깨끗한 오류를 거의 내지 않습니다. 양쪽은 교집합으로 좁혀지고, 이전 프리픽스는 계속 동작하며 새 것만 조용히 실패합니다.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

pfSense 나 OPNsense 에서는 새 로컬 서브넷과 새 원격 서브넷을 짝지은 두 번째 Phase 2 항목을 추가한 뒤 적용하는 것입니다. 이전 항목은 남겨 두십시오. 교체하면 원래 서브넷이 추가되는 대신 옮겨집니다. 기존 Phase 2 가 0.0.0.0/0 같은 상위망이나 요약 대역을 이미 덮으면 그 옆에 더 좁은 항목을 더하지 마십시오. 겹치는 선택자는 경쟁 정책을 설치하고 평가 순서가 승자를 정합니다.

IKEv1 은 서브넷 쌍마다 별도 Phase 2 를 만들고, 교환마다 한 쌍만 받는 측은 나머지를 버립니다. IKEv2 는 한 자식에 여러 선택자 쌍을 실을 수 있지만 두 구현이 모두 받아들여야 합니다. swanctl --list-sas 의 목록이 진실이고, 입력한 내용은 요청입니다.

경로 기반 터널: 경로가 정책입니다

XFRM 인터페이스나 VTI 장치는 경로 테이블에 따라 트래픽을 나릅니다. 새 프리픽스를 두 사이트에서 장치로 향하게 하면 인터페이스 변환에 묶인 상태가 적용됩니다. 동기화할 선택자 쌍이 없으므로 서브넷이 늘어날 때 이 설계가 더 잘 확장됩니다. strongSwan 전달 안내서 가 커널 쪽을 자세히 다룹니다.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

WireGuard 는 한 걸음 더 나아갑니다. AllowedIPs 은 암호 허용 목록이면서 wg-quick 을 통해 경로 테이블 항목이기도 합니다. 한쪽에만 프리픽스를 더하면 핸드셰이크와 나가는 패킷은 되지만 응답이 없습니다. 반대쪽이 출발지가 목록에 없는 패킷을 버리기 때문입니다. wg set 형식은 목록을 통째로 바꾸므로 이미 동작하던 프리픽스를 다시 적어야 합니다. 그렇지 않으면 끊깁니다:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

wg-quick 대신 wg set 을 썼다면 그 두 번째 명령은 선택이 아닙니다. 커널은 새 허용 목록을 곧바로 받아들이지만 아무도 그에 대한 경로를 더하지 않아, 로컬에서 만든 트래픽은 여전히 기본 게이트웨이로 나갑니다. 새 WireGuard 서브넷이 터널 호스트에서는 되고 노트북에서는 되지 않는 가장 흔한 이유입니다.

반환 경로가 터널보다 자주 깨집니다

새 원격 서브넷의 호스트는 응답을 VPN 게이트웨이로 되돌려 보내야 합니다. 그 게이트웨이가 기본 라우터가 아니면 응답은 LAN 라우터로 가고, 그 라우터는 버리거나 사설 출발지 주소로 인터넷에 넘깁니다. 게이트웨이가 아니라 반대쪽 호스트에서 시험하십시오. Linux 의 ip route get 10.30.20.15 이나 PowerShell 의 Find-NetRoute -RemoteIPAddress 10.30.20.15 이 호스트가 실제로 쓸 다음 홉을 보여 줍니다. 응답이 터널 끝점이 아니면 그곳에 새 프리픽스용 정적 경로를 추가하십시오.

반환 경로가 없는 사이트에서 출발지 NAT 를 쓰는 것은 정당한 대안이며, 많은 허브 앤 스포크 구성이 모든 서버를 건드리지 않고 해결하는 방법입니다. 목적지 쪽 게이트웨이에서도 새 프리픽스에 적용하십시오:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

대가는 실제입니다. 원격 로그는 개별 출발지 주소를 더 이상 보여 주지 않고, 원래 서브넷을 기준으로 한 방화벽 규칙은 게이트웨이용 한 규칙으로 접힙니다. 경로가 없어서가 아니라 의도적으로 고르십시오.

방화벽은 반환 경로의 나머지 절반입니다. 영역 기반 장비는 기존 터널 인터페이스의 영역을 새 서브넷으로 자동 확장하지 않고, 이전 프리픽스에 맞춰 쓴 규칙은 일치하지 않습니다. IPsec 을 탓하기 전에 새 서브넷을 영역이나 양방향 규칙 쌍에 추가하십시오.

세 가지 질문으로 정하고 트래픽으로 검증하십시오

짧게 말하면, 측 구성이 프리픽스를 지목하는가(정책 기반), 아니면 트래픽이 인터페이스로 라우팅되는가(경로 기반)입니다. 양 끝이 새 프리픽스를 나열하는가. 새 서브넷에서 원래 출발지 대역으로 돌아가는 길이 있는가.

검증은 대부분의 변경이 너무 일찍 닫히는 지점입니다. 게이트웨이에서 보내는 ping 은 증명이 적습니다. 게이트웨이는 자기 자신을 출발지로 삼고 호스트와 다른 정책에 맞는 경우가 많습니다. 새 서브넷의 호스트에서 ping 하고, 변경을 이끈 애플리케이션을 실행하며, 상태 아이콘이 아니라 카운터를 보십시오.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

정책 기반 터널에서는 ip xfrm state 의 카운터가 양방향으로 올라야 합니다. 평평하면 패킷이 라우팅되었지만 선택되지 않은 것입니다. WireGuard 에서 wg show 은 측별 전송량을 보여 주고, 수신 바이트가 없는 핸드셰이크는 반대쪽 목록이나 그 반환 경로를 가리킵니다.

마지막으로 프리픽스, 측의 선택자나 경로, 반환 경로 결정, 방화벽 항목을 나머지 터널 목록과 함께 기록하십시오. 그런 뒤 게이트웨이 하나를 재부팅하고 다시 시험하십시오. 손으로 더한 경로는 사라지며, 다음 사람이 그것을 다시 발견할 필요가 없어야 합니다.