사이트 간 VPN: 실제로 어느 방향에 규칙이 필요한가?

양쪽 끝 모두 터널이 설정되었다고 보고하고 원격 지사는 게이트웨이에서 응답하는데, 한쪽 사용자에게는 애플리케이션이 계속 시간 초과됩니다. 흔한 조언은 양방향에 방화벽 규칙을 추가하라는 것입니다. 때로는 맞고, 때로는 이미 있는 규칙을 중복하며, 때로는 두 번째 규칙이 상태를 깨뜨립니다. 어떤 경우인지는 방화벽이 패킷을 어디에서 보는지에 달려 있습니다.

상태 저장 반환 트래픽은 개수를 바꾼다

상태 저장 방화벽은 요청을 기록하고 두 번째 규칙 없이 응답을 통과시키므로 규칙 하나만 필요한 설계는 정상입니다. 상태 비저장 접근 목록에는 그런 기억이 없고 응답을 명시적으로 허용해야 합니다. 둘 다 각자의 플랫폼에서는 맞기 때문에 조언이 충돌합니다.

앞에 있는 플랫폼의 전달 문서를 읽고, 편집하는 정책이 패킷을 보는 지점에서 상태 저장인지 확인하십시오. 설정된 트래픽에 대한 명시적 거부나 상태 테이블보다 먼저 응답을 평가하는 규칙 순서는 작동하는 설계를 이해하기 어렵게 만듭니다. 규칙 수는 구현 세부 사항이고, 요구 사항은 허용된 대화의 양방향이 완료될 수 있어야 한다는 것입니다.

방화벽이 복호화된 패킷을 보는 곳

정책 기반 터널에서 방화벽은 암호화된 패킷을 복호화 전에, 복호화된 패킷을 그 후에 서로 다른 인터페이스에서 평가할 수 있습니다. 잘못된 인터페이스용으로 작성된 규칙은 존재하고 올바르지만 절대 일치하지 않습니다. 이렇게 작동하는 배포에서 복사한 규칙 집합이 동일한 하드웨어에서 실패할 수 있습니다.

경로 기반 IPsec과 대부분의 최신 구현은 터널 인터페이스를 제공하므로 복호화된 패킷이 그곳에 도착하고 일반 인터페이스 규칙이 적용됩니다. 다른 모델용으로 작성된 안내서에서 규칙 집합을 복사하기 전에 배포가 어느 모델을 쓰는지 확인하십시오. 터널 인터페이스는 패킷이 애초에 복호화되었는지 알아야 할 때 살펴볼 곳이기도 합니다.

비대칭 라우팅이 가정을 깨뜨린다

상태 저장 방화벽은 대화의 양쪽 절반을 본다고 가정합니다. 응답이 다른 게이트웨이를 통해 돌아오면 그 장치는 요청에 대한 상태를 보유하지 않으므로 자체 정책에 따라 버립니다. 증상은 송신 측의 어떤 규칙으로도 고칠 수 없는 단방향 실패입니다. 응답 경로를 추적하십시오 무엇이든 편집하기 전에.

양쪽에 광범위한 허용 규칙을 추가하기 전에 응답 경로를 확인하십시오. 모든 인터페이스에서 모든 것을 허용하면 라우팅 오류를 숨기고 동시에 접근을 넓히는데, 이는 가능한 최악의 조합입니다.

실제 원본 주소로 양방향을 확인하십시오

원격 측이 실제로 관찰하는 주소로 테스트하십시오, 변환 때문에 원본 규칙이 아무것도 일치하지 않을 수 있기 때문입니다. 두 게이트웨이에서 동시에 캡처를 실행하십시오.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

원격 게이트웨이에 예상치 못한 원본 주소로 나타나는 요청은 절대 일치하지 않는 규칙을 설명하고, 잘못된 인터페이스에 도착하는 응답은 상태 불일치를 설명합니다. 그런 다음 승인된 범위 안의 대상 하나와 범위 밖의 대상 하나를 테스트하여 경계를 가정하지 않고 입증하십시오.

변환 후의 원본 주소, 복호화된 패킷이 사용한 인터페이스, 일치한 규칙을 기록하십시오. 그 세 가지 사실이 전체 조사를 반복하지 않고 다음 티켓에 답합니다.