tun0이 없나요? nftables에서 복호화된 IPsec을 meta ipsec으로 일치시키기

터널 인터페이스를 기대하고 찾아봐도 방화벽에는 일치시킬 것이 없습니다. 정책 기반 게이트웨이에서는 이것이 정상입니다. 암호화된 교환은 물리 인터페이스로 도착하고, 이후 전달되는 복호화된 내부 패킷도 같은 인터페이스로 도착하는 것으로 관측됩니다. 아무것도 만들지 않았으므로 tun0은 없습니다.

내부 요청은 여전히 자체 출발지, 목적지, 서비스를 가진 별개의 패킷이며, 커널은 그것이 어느 보안 연관에서 나왔는지 압니다. 방화벽 규칙이 일치시킬 수 있는 것은 바로 이 지식입니다.

두 패킷, 하나의 인터페이스

인바운드 방향을 상상해 보세요. ESP 또는 UDP로 캡슐화된 패킷이 도착하면 커널이 일치하는 정책을 찾아 복호화하고 평문 패킷을 포워딩 경로에 넘깁니다. 인터페이스 이름만 보는 규칙은 그 패킷을 같은 회선으로 도착하는 다른 트래픽과 구분할 수 없습니다.

그것을 구분하는 것은 패킷에 붙은 인바운드 보안 경로 컨텍스트입니다. nftables는 이를 meta ipsec exists 로 노출하며, 패킷이 IPsec 보안 경로를 통해 도착했을 때 참입니다. 클라이언트 풀, 목적지, 서비스와 결합하면 규칙은 안전할 만큼 구체적이 됩니다.

컨텍스트를 빼는 것이 흔한 실수이며, 이는 미관이 아니라 보안의 실수입니다. 클라이언트 풀에서 오는 모든 것을 허용하는 규칙은 로컬 네트워크에서 온 위조 패킷도 똑같이 반갑게 허용합니다. 출발지 주소만으로는 아무것도 증명하지 못하기 때문입니다. 보안 경로 컨텍스트는 출발지를 의미 있게 만드는 가장 저렴한 방법입니다. 감사 후에 덧붙이지 말고 처음부터 그것으로 규칙을 작성하세요.

포워딩 규칙 작성하기

10.90.0.0/24 에 클라이언트를 둔 인증된 IPv4 원격 접속 서비스와 203.0.113.40 에 승인된 목적지 하나가 있다고 합시다. 그 흐름에 대한 규칙 조각은 다음과 같습니다.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

주소와 인터페이스는 교체할 예시입니다. 검토된 등가물을 흐름을 거부할 규칙보다 앞서 포워딩 정책에 두고, 설치를 위해 기존 규칙 집합을 비우지 마세요. 게이트웨이는 클린룸 실험이 아닙니다.

oifname 조건은 유지할 가치가 있습니다. 송신 결정을 기록하고 규칙이 의도하지 않은 방향에서 일치하지 않게 하며, 인터넷으로 가는 경로가 여러 개인 게이트웨이에서 중요합니다. 업링크가 하나뿐인 테스트 장비에서는 이 조건이 불필요해 보이고, 바로 그래서 두 번째 업링크가 생기기 전에 제거됩니다.

외부 교환에 대한 권한은 별개입니다. 게이트웨이의 입력 경로에는 실제로 사용하는 IKE와 ESP 또는 UDP 캡슐화 포트가 필요하며, 그 권한은 내부의 복호화된 패킷에 대해 아무것도 허용하지 않습니다. 둘을 섞는 것이 동작하는 터널이 모든 것을 전달하는 방화벽과 함께 끝나는 방식입니다.

인바운드 컨텍스트는 아웃바운드 컨텍스트가 아니다

같은 표현 계열이 rt ipsec 으로 반대 방향을 다루며, 이는 패킷이 사용할 아웃바운드 보안 연관을 설명합니다. 다른 질문에 답합니다. 이 패킷이 어디서 왔는지가 아니라 다음 구간에서 보호될지 여부입니다.

이 구분은 하나의 터널을 종료하면서 다른 터널로 전달하는 게이트웨이에서 중요합니다. 패킷은 복호화되어 도착하더라도 암호화되어 나가야 할 수 있으며, 인바운드 컨텍스트만을 위해 작성된 허용은 아웃바운드 요구 사항에 대해 아무 말도 하지 않습니다. 정책이 그 보호를 요구한다면 라우팅이 처리하리라 가정하지 말고 규칙 집합이 이를 표현해야 합니다.

두 질문을 별도 규칙에 두어 독자가 어느 것이 적용되는지 볼 수 있게 하세요. 둘 다 검사하는 하나의 영리한 규칙은 검토하기 어렵고, 한쪽이 일치를 멈출 때 디버깅은 훨씬 어렵습니다. 카운터가 있는 두 규칙은 어느 요구 사항이 실패하는지도 알려 주지만, 하나로 합친 규칙은 결코 그렇게 하지 못합니다.

NAT는 방화벽 결정이 아니다

사설 클라이언트 풀에서 인터넷으로 가는 트래픽은 보통 응답이 돌아올 길을 찾도록 출발지 변환이 필요합니다. 하지만 다른 아웃바운드 IPsec 정책을 위해 선택된 트래픽은 필요한 예외를 유지해야 하며, 다음 보호 결정을 생각하지 않고 모든 사설 출발지를 마스커레이드하면 그것이 깨집니다.

NAT 체인 내부의 허용도 일반적인 허용이 아닙니다. NAT와 필터링은 하는 일이 다르고, NAT 체인은 설정된 흐름의 이후 패킷을 모두 검사하지 않으므로, 보안을 위해 그것에 의존하면 시험에서는 동작하는 듯 보이고 부하에서 실패하는 규칙이 생깁니다.

반대도 사실이며 사람들을 놀라게 합니다. 한 필터 기본 체인의 어딘가에 있는 허용은 다른 적용 가능한 체인의 이후 폐기 앞에서 아무 무게도 없습니다. 결과를 결정하는 것은 순서와 체인의 범위이지, 파일에 허용이 있는지 여부가 아닙니다.

정확한 내부 서비스 확인하기

승인한 특정 목적지와 포트를 실제 클라이언트에서 시험하고 응답이 돌아오는지 확인하세요. 그다음 승인하지 않은 것을 시험해 통과하지 않는지 확인하세요. 너무 넓은 규칙도 올바른 규칙만큼 첫 시험을 잘 통과하기 때문입니다. 클라이언트를 떠나지 않는 요청 역시 방화벽의 결과가 아니므로, 카운터를 읽어 패킷이 평가되기는 했는지 보세요. 두 번의 시험과 한 번의 카운터 확인은 규칙 집합을 읽는 반나절보다 많은 것을 알려 줍니다.

nftables 참조는 meta ipsec, rt ipsec 과 방향별 표현을 문서화하며, 설치된 버전과 구문을 대조할 곳이 바로 거기입니다. 범위도 분명히 하세요. 이것은 IPv4 예시이며 IPv6에 대해서는 아무 말도 하지 않고, 임의의 공용 포트 포워딩을 VPN 서비스의 일부로 만들지도 않습니다.