OpenVPN 클라이언트가 게이트웨이의 IPsec 선택자에 도달하지 못하는 이유

게이트웨이에서 원격 IPsec 터널 뒤의 호스트로 ping을 보내면 깔끔하게 응답하므로 터널은 정상으로 보이고 티켓은 넘어갑니다. 그러다 연결된 클라이언트가 같은 호스트를 시도하면 아무것도 돌아오지 않습니다. 그 ping은 게이트웨이 자신의 출발지 주소로 나갔고 다른 IPsec 선택자와 일치했기 때문에 클라이언트 흐름의 증거가 될 수 없었습니다. 두 경우가 왜 갈라지는지 이해하는 것이 수정의 대부분입니다.

게이트웨이의 ping은 클라이언트가 결코 쓰지 않는 흐름을 시험합니다

어떤 정책이 적용되는지는 출발지 주소가 결정합니다. 게이트웨이에서 생성된 패킷은 로컬 LAN이나 터널 끝점의 주소로 나가고, 그에 맞는 정책은 바로 그 경우를 위해 작성되었습니다. 클라이언트의 패킷은 클라이언트 풀의 주소를 지니고 OpenVPN 인터페이스로 도착하는데, 이것은 전혀 다른 선택자입니다.

그래서 장애는 라우팅 문제처럼 보이지만 실제로는 정책 범위의 문제입니다. 게이트웨이에서의 도달성은 상대가 살아 있고 제안이 협상되었음을 증명할 뿐, 풀이 보호되는지에 대해서는 아무것도 증명하지 않습니다.

애플리케이션이 실제로 필요로 하는 원격 프리픽스를 푸시하십시오

연결된 클라이언트용 10.8.0.0/24와 보호된 원격 네트워크용 172.30.239.0/25라는 예시 쌍을 봅니다. 클라이언트에게 필요한 것은 두 번째 프리픽스로 가는 경로이며, 게이트웨이의 LAN도 아니고 다른 터널 주소도 아닙니다. 풀에 푸시된 경로가 있어야 클라이언트가 그 트래픽을 게이트웨이에 넘깁니다. 그것이 없으면 패킷은 디버깅 중인 정책 결정에 결코 도달하지 않습니다.

푸시된 경로를 받아들이는 Community 서버에서는 지시문이 실제 마스크를 가집니다: push "route 172.30.239.0 255.255.255.128". Access Server는 설치된 버전의 사설 네트워크나 접근 규칙 설정으로 같은 목적지를 구성하며, 라우티드 또는 트랜슬레이티드 모드를 의도적으로 고릅니다. 소유 구성 대신 생성된 방화벽 체인을 편집하는 것이 동작하는 구성을 재현 불가능하게 만드는 길입니다.

연결한 뒤에는 서버의 의도가 아니라 클라이언트의 라우팅 테이블을 읽습니다. 풀만 덮는 경로는 푸시가 도착하지 않았다는 뜻이고, 터널을 통한 기본 경로는 이 요구보다 넓어 나중에 당황하게 합니다. 마스크와 프리픽스를 모두 확인하되, /25를 /24로 푸시하면 인접 주소의 트래픽이 감당할 수 없는 경로로 들어간다는 점을 기억하십시오. 그런 다음 클라이언트가 그 목적지에 터널 인터페이스를 선택했는지 확인합니다.

선택자가 클라이언트 풀을 포함하게 하십시오

클라이언트 주소를 보존하는 라우티드 접근에서는 IPsec 정책이 풀과 원격 프리픽스 사이의 트래픽을 보호해야 합니다. 게이트웨이 자체 LAN을 위해 작성된 선택자는 ping을 통과시키고 클라이언트의 요청을 버리는데, 이것이 바로 이 조사를 시작한 비대칭입니다.

구성된 제안뿐 아니라 협상된 정책도 strongSwan의 ipsec statusall이나 구현에 맞는 동등한 상태 명령으로 확인하십시오. 정책 기반 IPsec에서는 일반 경로가 물리 인터페이스를 가리켜도 일치하는 트래픽은 여전히 암호화되므로, 터널 장치가 없다는 것이 아무것도 증명하지 않습니다. 선택자 쌍을 기록해 둔 풀과 프리픽스와 비교하십시오.

게이트웨이의 일반 출발지 NAT도 일치를 깨뜨릴 수 있습니다. 정책 검사 전에 masquerade 규칙이 클라이언트의 출발지를 다시 쓰면 패킷은 더 이상 작성한 선택자처럼 보이지 않습니다. 넓은 masquerade 규칙이 두 번째 VPN의 나쁜 해결책인 이유 하나는 어떤 정책이 적용되고 원격 측이 어떤 주소를 기록하는지가 바뀌기 때문입니다. 라우팅하려는 트래픽을 예외로 두거나, 의도적으로 변환하고 선택자를 갱신하십시오.

라우팅인지 변환인지 의도적으로 고르십시오

라우팅은 클라이언트 주소를 원격 측에 보이게 유지하므로 원격 로그와 출발지별 규칙이 의미를 지니고, 원격 게이트웨이가 풀로 돌아가는 경로를 알아야 합니다. 변환은 풀을 하나의 주소 뒤에 숨기므로 반환 경로 문제를 없애는 대신 클라이언트별 정체성을 파괴합니다.

둘은 서로 다른 선택자와 다른 방화벽 순서를 필요로 하므로 설계를 하나 골라 적어 두십시오. 절반만 적용한 masquerade는 그 사이에 걸쳐 어느 쪽도 만족시키지 못합니다. 적어 둔 선택은 다음 엔지니어가 버그와 의도된 결정을 구분하게 해 줍니다.

포워딩과 응답에서 고리를 닫으십시오

게이트웨이는 의도한 프로토콜과 목적지를 포워딩해야 하며, 이는 IP 포워딩이 켜져 있고 그 쌍을 허용하는 포워드 체인이 있음을 뜻합니다. 그다음 원격 측이 IPsec 경로로 응답을 돌려보내야 하는데, 그것은 우리 게이트웨이가 아니라 상대 게이트웨이에서의 라우팅 결정입니다. 두 절반 모두 평범한 구성이고 둘 다 절반으로 남기기 쉽습니다. 따로 시험해 포워드 규칙 누락을 고장 난 터널로 오해하지 않도록 하십시오.

클라이언트에서 애플리케이션으로 가는 실제 요청 하나로 검증하고, 그것이 OpenVPN 인터페이스, IPsec 결정, 원격 호스트를 지나는 것을 지켜봅니다. 도착하는 요청과 결코 돌아오지 않는 응답은 클라이언트 자리에서 똑같이 보이므로 응답은 별도의 관찰로 살펴보십시오. 추적한 요청 하나가 게이트웨이 ping을 아무리 많이 해도 그보다 값집니다.

시험하는 동안 목적지 권한을 좁게 유지하고, 규칙이 없는 클라이언트가 서비스에 도달하지 못함을 확인하십시오. 설치된 경로와 성립된 연결은 부여된 접근과 같지 않습니다.