작동하는 VPN인데도 응답에서 시간 초과가 나는 이유
요청이 사설 서버에 도착하는 것은 교환의 절반일 뿐입니다. 그 응답은 의도한 게이트웨이, 경로 또는 변환을 거쳐 터널 클라이언트를 찾아야 합니다.
요청이 도착하고 서버가 이를 기록하는데도 클라이언트는 여전히 시간 초과를 보고합니다. 이 조합이 뜻하는 것은 응답이 돌아갈 길을 찾지 못했다는 것입니다. 양쪽 끝에서 동시에 확인할 수 있는 몇 안 되는 고장 중 하나이며, 점검은 순서대로 하고 하나라도 실패하면 멈추십시오.
요청이 도착한 지점부터 시작하십시오
다른 무엇을 살펴보기 전에 패킷이 서비스에 도달했는지 확인하십시오. 서버 측 로그 기록, 연결 카운터, 원격 끝에서 허용된 캡처는 모두 같은 질문에 답하며, 그것이 없다면 응답이 아니라 터널로 되돌아가야 합니다. 이것이 전달 문제와 반환 경로 문제를 구분하는 점검입니다.
요청이 한 번도 도착하지 않았다면 여기서 멈추십시오. 터널, 사설 프리픽스로의 라우팅 또는 접근 규칙이 주제이며 반환 경로는 아직 관계없습니다. 서버가 본 출발지 주소도 기록하십시오. 그것은 클라이언트가 받은 풀 주소이거나 변환된 주소이며, 이 차이가 이후 어떤 점검이 적용되는지를 결정합니다.
응답에는 풀로 가는 경로가 필요합니다
원격 접속 클라이언트는 보통 풀에서 주소를 받고, 사설 네트워크는 그 풀로 돌아가는 경로가 필요합니다. 기본 경로가 자기 게이트웨이를 가리키는 서버는 패킷을 그 게이트웨이에 넘기는데, 그 게이트웨이는 풀이 어디 있는지 알지 못하므로 응답은 그곳에서 죽습니다. 아무것도 돌아오지 않았기에 클라이언트는 시간 초과를 보게 되며, 이는 한 번도 나가지 않은 요청과 구분되지 않습니다.
서버가 자기 서브넷에 쓰는 경로가 아니라 클라이언트 주소에 대해 고르는 경로를 확인하십시오. 이 두 조회는 다른 답을 낼 수 있고, 여기서 중요한 것은 두 번째입니다. 변환은 다른 설계이며 서버가 보는 것을 바꿉니다. 반환 경로를 단순하게 만들 수 있고, 원래 클라이언트 주소를 서버 로그에서 지우기 때문에 그 필드에 기반한 규칙이나 보고서에도 영향을 줍니다.
서버 캡처와 게이트웨이 캡처를 비교하십시오
서버를 떠나는 것과 게이트웨이에 도착하는 것을 비교하십시오. 서버의 나가는 인터페이스에서의 캡처와 터널 게이트웨이에서의 캡처는 질문의 서로 다른 절반에 답하며, 그 사이의 간격이 손실 위치를 알려 줍니다.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
게이트웨이 자체가 만든 요청은 다른 주소에서 나와 다른 규칙을 만나므로 클라이언트 시험의 대체물로 부적합합니다. 그래서 게이트웨이에서의 ping 성공과 클라이언트에서의 요청 실패가 동시에 참일 수 있습니다.
경로에 라우터가 여러 대 있다면 풀로 가는 경로가 필요한 각각을 확인하십시오. 사이트 간 설계는 원격 프리픽스를 둘 이상의 장비에서 알아야 하는 경우가 많고, 게이트웨이 자체가 터널과 LAN 사이를 전달해야 하며, strongSwan의 전달 관련 문서 가 그 sysctl과 방화벽 측면을 다룹니다.
풀, 프리픽스, 담당자를 기록하십시오
기록에 들어가야 할 사실은 네 가지입니다. 클라이언트가 받은 풀, 필요했던 사설 프리픽스, 응답을 책임지는 라우터, 그리고 있다면 변환 규칙이며, 이것이 있으면 나중의 게이트웨이 변경은 조사가 아니라 비교가 됩니다.
그다음 일반 클라이언트와 실제 애플리케이션 계정으로 다시 시험하십시오. 애플리케이션 권한을 넓힌다고 패킷의 반환 경로가 고쳐지지는 않으며, 이 진단 중에 계정을 바꾸면 다음 비교가 흐트러집니다. 설계가 변환에 의존한다면 서버 로그를 읽는 곳에 그것을 문서화하십시오. 감사 기록에서 낯선 출발지 주소를 본 사람이 티켓에서 대응 관계를 다시 찾아내야 해서는 안 됩니다.