하드웨어 NAT 오프로드가 VPN 라우팅 규칙을 깨뜨릴까?

하드웨어 NAT 가속을 켜면 VPN 구성이 빨라질 수 있고, 오류를 전혀 내지 않은 채 라우팅 정책이 일부 패킷에 적용되지 않게 될 수도 있다. 둘 중 무엇이 일어나는지는 빠른 경로가 무엇을 건너뛰는지에 달려 있고, 그것은 펌웨어와 커널 버전, 사용하는 가속의 종류에 따라 다르다. 설정 메뉴는 방금 무엇을 켰는지 거의 알려주지 않는다.

가속기를 탓하기 전에 두 가지 주장을 분리할 필요가 있다. 규칙이 더 이상 적용되지 않게 되었다는 것과, 카운터가 더 이상 갱신되지 않게 되었다는 것이다. 이 둘은 같은 관찰이 아니다.

서로 다른 세 가지 가속이 뒤섞인다

포워딩 오프로드, 암호 가속, 터널 데이터 채널 오프로드는 흔히 하나의 스위치를 공유하는 별개의 메커니즘이다. 포워딩 오프로드는 확립된 플로가 정상 스택의 일부를 건너뛰게 하고, 암호 가속은 암호 연산을 저렴하게 만들며, 터널 오프로드는 캡슐화를 하드웨어로 옮긴다. 일반 라우팅 트래픽을 가속하는 라우터가 터널 트래픽을 전부 느린 경로에 남길 수도 있는데, 이는 정책 변경이 아니라 성능의 결과다. 반대 경우도 있어, 터널 트래픽은 오프로드되면서 주변 정책은 여전히 평가된다.

Linux의 flowtable은 확립된 플로를 빠른 경로로 넘길 수 있어 가장 읽을 만한 문서화된 사례다. 그러면 회계와 상태 처리가 고전적 포워딩과 달라지고, 그래서 카운터가 이상해 보이기 시작한다.

움직임을 멈춘 카운터는 거의 아무것도 증명하지 못한다

규칙 카운터는 그 규칙을 통과하는 패킷을 세는데, 오프로드된 플로는 첫 패킷 이후 다시는 그 규칙을 지나지 않을 수 있다. 그러면 트래픽이 계속되는데도 얼어붙은 카운터가 생기고, 숫자를 믿는다면 우회와 똑같이 보인다. 카운터를 지켜보는 것은 플로가 집계 경로를 떠났다는 단서로 여전히 쓸모가 있다. 나머지 진단은 패킷이 실제로 어디로 가는지에서 나와야 한다.

반대 추론도 똑같이 실패한다. 빠른 다운로드는 예외 규칙과 장애 처리가 여전히 적용된다는 것을 보여주지 않는다. 플로 하나를 시험할 뿐 정책을 시험하지는 않기 때문이다.

오프로드가 정책을 깨는지는 세 가지 조건이 결정한다

첫 번째 조건은 빠른 경로가 정책이 의존하는 훅을 참조하는지다. 마크와 경로로 표현된 정책은 패킷별 필터링으로 만든 정책보다 더 자주 살아남는다. 두 번째는 펌웨어가 그 조합을 아예 허용하는지로, 일부 빌드는 터널이나 방화벽 기능이 활성화되면 오프로드를 자동으로 끈다. 세 번째는 트래픽이 대상이 되는지로, 가속은 보통 확립된 플로에 묶여 있어 단편화되었거나 드문 패킷을 제외할 수 있다. 세 가지가 모두 가속에 유리하면 정책은 여전히 적용되고, 첫 번째가 무너지면 어떤 조정으로도 되살릴 수 없다.

라우터 모델 전반이 아니라 지금 돌리는 조합에 대한 벤더 문서를 읽어야 한다. 펌웨어 버전은 이런 답을 조용히 바꾼다.

측정할 것은 정책이지 처리량이 아니다

얼마나 빠른지 재기 전에 정책이 무엇을 보장해야 하는지부터 재라. 아래 명령은 flowtable이 설치되어 있는지, 연결 추적이 무엇을 보는지, 클라이언트가 어느 주소로 나가는지를 보여준다. 변경 후에는 새 연결로 비교하라. 확립된 연결은 옛 경로를 그대로 유지할 수 있다.

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

터널 트래픽을 덮는 flowtable 항목이 있으면 빠른 경로가 작동 중이고, 연결 표는 플로가 기대한 대로 추적되는지 보여준다. 주소 확인은 정책이 인터넷 이그레스에 관한 것일 때 출구를 확인해 주고, ping은 계속 도달 가능해야 하는 사설 목적지를 확인해 준다. 같은 조합을 가속을 끈 상태와 켠 상태로 실행하고, 시간이 아니라 결과를 비교하라.

이전 설정을 기록해 실험을 되돌릴 수 있게 하라. 어디서나 오프로드를 끄라는 일반적인 지침은 우회책이지 발견이 아니다.