사이트 간 VPN 응답이 터널을 통과하지 않습니다
터널을 건너뛰는 응답은 반대편의 라우팅 결정입니다. 호스트 테이블과 셀렉터, rp_filter를 확인한 뒤 경로나 NAT를 고르십시오.
어느 아침을, 깔끔하게 올라오며 트래픽을 정확히 한 방향으로만 옮기는 터널에 썼는데, 지사는 본사의 파일 서버에 닿았고 본사에서 지사로 여는 모든 연결은 첫 SYN에서 죽었습니다. SA는 올라와 있었고 터널 카운터는 늘고 있었으며, 핸드셰이크가 문제였던 적은 없습니다. 응답은 터널이 덮지 않는 곳으로 라우팅되고 있었고, 그 선택은 반대편의 몫입니다. 사이트 간 VPN은 호스트가 게이트웨이에 넘긴 패킷만 실어 나르며, 각 호스트는 그 선택을 따로, 각 방향으로, 자기 라우팅 테이블에서 합니다.
두 방향은 따로 라우팅됩니다
IP는 대화의 방향을 기억하지 않습니다. 패킷을 보내는 각 호스트는 자기 최장 프리픽스 조회를 수행하고, 다음 홉 하나를 고르고, 그 결정을 잊습니다. 요청과 응답은 같은 연결에 우연히 속한 무관한 두 패킷이며, 터널은 둘 중 어느 쪽이 쓰거나 쓰지 않을 수 있는 한 홉입니다. IKE 교환은 원격 서버에 당신의 서브넷에 도달하는 법을 가르치지 않으며, 협상이 합의하는 것은 어느 프리픽스를 암호화해도 되는지뿐입니다.
그 합의가 두 번째 관문입니다. strongSwan에서 트래픽 셀렉터는 leftsubnet 와 rightsubnet 이고, 출발지나 목적지가 협상된 쌍을 벗어나는 패킷은 라우팅 테이블이 뭐라든 암호화되지 않습니다. 터널로 라우팅되지만 셀렉터에 없는 프리픽스는, 경로는 맞아 보이는데 패킷은 여전히 평문으로 나가거나 버려지고 charon 로그만 불평하는 조용한 단방향 실패입니다.
원격 호스트는 당신의 터널에 대해 아무것도 모릅니다
원격 LAN 안에서 응답은 당신의 클라이언트로 향한 평범한 패킷입니다. 목적지 호스트는 IPsec 헤더를 보지 못하고 VPN 게이트웨이를 선호할 이유도 없어, 당신의 프리픽스를 조회하고 기본 경로보다 구체적인 것을 찾지 못해 그것을 따릅니다. 기본 경로가 핵심 방화벽을 가리키면, 그 방화벽에는 터널로 돌아가는 경로가 있거나 없습니다. 없으면 조용한 폐기, ICMP unreachable, 혹은 인터넷 쪽 인터페이스로 나가 죽는 응답을 받습니다.
경로가 있어도 두 번째 인터페이스 하나면 이것이 깨집니다. 다른 VLAN의 관리 링크를 가진 NAS, 백업 uplink가 있는 서버, 한 출발지 범위를 두 번째 테이블로 보내는 정책 규칙, 이 가운데 무엇이든 응답을 가로챌 수 있습니다. Linux에서는 ip rule show 와 ip route show table all 이 기본 목록이 숨기는 규칙과 테이블을 보여 줍니다.
응답을 보내는 기계에서 결정을 읽으십시오
출발지에 의존하는 규칙이 답을 바꾸므로, 무엇이든 바꾸기 전에 커널에 물어보고 출발지 주소를 주십시오.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"출력은 나가는 인터페이스와 다음 홉을 알려 줍니다. 그 인터페이스가 VPN 게이트웨이 쪽이 아니라면 결함을 찾은 것이고, 남은 일은 경로가 어디에 속하는지 고르는 것입니다. 게이트웨이에서 보낸 ping은 원격 호스트가 위치를 잡을 수 있는 주소로 답할 뿐 당신의 노트북 주소가 아니므로 여기서 거의 증명하지 못합니다.
Windows에서는 결정에 Find-NetRoute -RemoteIPAddress 10.10.5.10, 테이블에 Get-NetRoute 이 해당합니다. 기본보다 높은 메트릭을 지닌 New-NetRoute 로 추가한 경로는 조용히 지므로, 항목이 아니라 메트릭 열을 읽으십시오. 그다음 패킷으로 확인하면, 원격 LAN 인터페이스에서 tcpdump -ni any "host 10.10.5.10 and tcp port 445" 이 요청을 보여 주고 터널 쪽에서 같은 필터가 응답이 돌아왔는지 보여 줍니다. 요청은 보이는데 응답이 없으면 응답이 다른 곳으로 라우팅되었거나 버려진 것이고, 엉뚱한 인터페이스의 응답은 경로를 건드리기 전에 범인을 알려 줍니다.
서버의 게이트웨이가 VPN 종단이 아닐 때
많은 사이트가 서버와 집선 장치 사이에 방화벽을 둡니다. 그 방화벽은 응답을 전달하므로, 당신의 클라이언트 프리픽스에 대해 VPN 게이트웨이를 가리키는 경로와 양방향 전달 정책이 필요합니다. 상태를 지닌 장비는 상황을 더 나쁘게 만들어, 요청은 그 장비가 허용한 LAN 호스트에서 방화벽을 지나갔고, 응답은 이제 다른 방향에서 오며, 연결 추적 항목이 더는 맞지 않으므로 패킷은 거부되는 대신 무효로 버려집니다. 트래픽이 사라지는데 정책 로그가 비어 보이는 이유입니다.
게이트웨이에는 자체적인 두 번째 필터가 있습니다. Linux의 역경로 필터링은 패킷이 도착한 인터페이스로 출발지에 닿을 수 없으면 그 패킷을 버리며, 이것이 정당한 비대칭 반환 경로의 바로 그 모양입니다. strongSwan의 전달 안내서 가 바로 그 이유로 net.ipv4.ip_forward 와 완화된 net.ipv4.conf.all.rp_filter 를 요구합니다. 어느 한 게이트웨이에서든 엄격한 값 1은 올바른 경로를 조용히 깨뜨리고, 어디를 봐야 할지 안다면 nstat -az 이 폐기를 보여 줍니다.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
라우팅하거나 변환한 뒤 양방향으로 검증하십시오
두 수리는 동등하지 않습니다. 경로를 더하면 클라이언트 주소가 그대로 남으므로 출발지 기반 규칙과 감사 로그, 호출자를 기록하는 애플리케이션이 계속 동작하지만, 대가는 결정을 내리는 모든 홉에 경로가 필요하다는 것이고 이는 틀릴 곳이 더 많다는 뜻입니다. 원격 게이트웨이에서의 마스커레이드 는 응답이 이제 게이트웨이 자신을 향하기 때문에 반환 경로를 한 홉으로 줄이고, 어느 클라이언트가 무엇을 했는지 감춥니다.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE클라이언트가 게이트웨이 주소로 보이기 시작하면 출발지 기반 ACL은 이들을 구분하지 못하고 응답이 터널로 다시 쓰이도록 conntrack 이 매핑을 유지해야 하므로, 의도적으로 고르십시오. 셀렉터가 여전히 클라이언트 프리픽스를 제외한다면, 요청이 터널에 들어간 적이 없으므로 NAT는 아무것도 바꾸지 못합니다.
고쳐졌다고 말하기 전에 응답을 보내는 호스트의 경로, 그것을 전달하는 모든 홉의 경로, 두 프리픽스를 덮는 셀렉터, 그리고 응답이 기대한 출발지로 터널에 들어가는 것을 보여 주는 캡처, 이 네 가지를 차례로 확인하십시오. 그다음 다른 사이트에서 시험을 반복하십시오. 한 방향이 통과하는 것은 반쯤 열린 설계이고, 두 번째 방향은 보통 방금 고친 것과 다른 이유로 실패합니다.