Asymmetric Routing 해결을 통한 Let's Encrypt 인증 장애 복구

The Hidden Linux Routing Issue That Broke My Deployment

Mohamed Hussain S2026년 6월 17일7분intermediate

AI 요약

Context

Public(ens3) 및 Private(ens4) 인터페이스를 동시 보유한 Multi-interface 서버 환경에서 Reverse Proxy인 Caddy를 통한 TLS 인증 시도. 외부 요청은 Public 인터페이스로 유입되나 응답 패킷이 Private 인터페이스로 라우팅되는 Asymmetric Routing 현상으로 인해 인증 타임아웃 발생.

Technical Solution

tcpdump를 통한 패킷 캡처로 외부 요청이 Public 인터페이스(ens3)에 정상 도달함을 확인하여 DNS 및 Firewall 설정 정상 검증
ip route 및 ip route get 명령어를 통한 Outbound 트래픽 경로 분석으로 기본 게이트웨이가 Private 인터페이스(ens4)로 설정된 병목 지점 식별
요청 유입 인터페이스와 응답 송신 인터페이스가 불일치함에 따른 커널 레벨의 Reverse Path Filtering(rp_filter)에 의한 패킷 드롭 가능성 파악
Linux Routing Table 수정을 통해 외부 목적지 트래픽이 Public 인터페이스(ens3)를 통해 송신되도록 경로 최적화
라우팅 경로 정정 후 Let's Encrypt Validation 요청의 정상적인 Round-trip 통신 경로 확보

실천 포인트

1. Multi-interface 서버 구성 시 ip route get [외부IP] 명령어로 실제 Outbound 경로 확인

2. 네트워크 장애 발생 시 로그 기반 추측보다 tcpdump를 통한 실제 패킷 흐름 분석 우선 수행

3. 외부 인증 서비스(Let's Encrypt 등) 이용 시 Rate Limit 도달 전 근본 원인 분석 단계 선행

태그

#Asymmetric Routing #Linux Networking #tcpdump #Reverse Path Filtering #Caddy

원문 읽기