포트 25만 터널로 보내고 호스트는 보내지 마십시오

Linux 호스트가 자신의 SMTP만 터널을 통해 내보내려면 네 가지가 맞아야 합니다: 전용 테이블의 경로, 트래픽을 선택하는 정책 규칙, 피어가 받아들일 소스 주소, 그리고 비대칭성을 견디는 반환 경로입니다. 각각은 고유한 실패 방식을 가진 별도의 구성입니다. 아래 순서는 실패가 실제로 잘못된 부분을 가리키게 합니다. 이것은 포트별 라우팅 작업이지 VPN 기본 경로 요청이 아닙니다.

포트 규칙은 기본 경로가 아닙니다

로컬에서 생성된 TCP를 목적지 포트 25와 일치시키는 규칙은 해당 트래픽을 지정한 테이블로 보냅니다. 규칙 자체는 아무것도 만들지 않습니다: 규칙은 선택하고, 테이블에는 패킷을 운반할 경로가 있어야 합니다. 둘을 합쳐도 한 프로토콜의 아웃바운드 방향만 다루므로 다른 호스트로의 포워딩, 인바운드 메일 연결, IPv6은 이 구성 밖에 남습니다. VPN 기본값이 아니라 포트별 정책이라고 부르는 것이 그 경계를 정직하게 유지합니다.

wg-quick의 두 설정은 전제 조건이며 정책의 일부가 아닙니다. AllowedIPs = 0.0.0.0/0은 피어가 임의의 IPv4 목적지를 운반하게 하고, Table = off는 wg-quick이 해당 프리픽스에 자체 기본 경로를 설치하지 못하게 합니다. 이 지침을 자체 경로 정책을 적용하는 관리자와 섞지 마십시오, 둘은 기본 테이블의 소유권에 대해 합의하지 못할 것입니다.

경로, 선택기, 보호를 작성하십시오

다른 무엇도 사용하지 않는 테이블 번호와 우선순위 쌍을 고른 뒤 경로, 선택기, 보호를 그 순서대로 적용하십시오. 아래 숫자는 예시이며 예약된 값이 아닙니다:

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo는 규칙을 로컬에서 발생한 트래픽으로 제한하고, ipproto tcp dport 25는 연결 방향을 식별하고, ip-rule 참조에 두 선택기가 모두 문서화되어 있습니다. 이것들은 현재 커널과 iproute2 릴리스에 존재하며, 더 오래된 시스템에서는 규칙이 아예 거부되고, 로드되지만 아무것도 일치하지 않는 규칙보다 명확한 실패입니다.

다음 우선순위의 unreachable 규칙이 보호입니다. 그것이 없으면 테이블 51825에 없는 경로가 일반 기본값으로 떨어지고, 터널 장애 중에 메일이 물리 링크로 나가는데, 정책이 막으려던 바로 그 경우입니다.

소스 주소가 일치해야 합니다

경로의 src 기본 설정은 자체 소스를 바인딩하지 않은 연결에만 소스를 채웁니다. 이것은 변환이 아니며 명시적 바인딩을 덮어쓰지 않으므로 물리 주소에 바인딩된 데몬은 계속 그 주소에서 보냅니다. 만약 그렇다면, 늦은 전면 masquerade는 다른 결과를 가진 다른 해결책이므로, 데몬 자체 설정을 바꾸거나 의도적인 변환 정책을 설계하십시오.

게이트웨이에서는 클라이언트의 피어가 실제로 받는 소스를 승인해야 하며, 그것은 넓은 목적지 프리픽스가 아니라 10.77.0.2/32입니다. 클라이언트의 0.0.0.0/0을 모든 게이트웨이 피어에 복사하면 어느 피어가 어느 트래픽을 소유하는지 혼란스러워집니다. 게이트웨이에는 포워딩, 흐름을 허용하는 방화벽 정책, 반환 경로도 필요하며, 업스트림이 사설 터널 주소를 라우팅할 수 없을 때는 이그레스 변환도 포함됩니다.

반환 경로를 확인하고, 그다음 지속성

무엇이든 믿기 전에 조회 결과를 읽으십시오(각 방향이 어떤 테이블과 어떤 소스를 받는지 보여줍니다). 포트 25의 목적지 하나와 포트 443의 같은 목적지면 충분합니다:

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

첫 번째 조회는 wg0와 의도한 소스를 지정해야 하고, 두 번째는 일반 업링크를 유지해야 합니다. 애플리케이션이 자체 주소를 바인딩하면 조회에 해당 주소와 함께 from을 추가하십시오. wg0에 도달한 뒤 로컬에서 버려지는 응답 방향은 아웃바운드 포트만 다루는 규칙이 역방향 조회에 터널을 선택하게 만들지 않기 때문에 IPv4 역방향 경로 필터링을 가리킵니다.

비대칭 라우팅이 허용되는 곳에서는 net.ipv4.conf.wg0.rp_filter=2를 통한 인터페이스 범위의 느슨한 모드가 적절할 수 있으며, 먼저 all과 인터페이스 값의 실효 최댓값을 확인할 가치가 있습니다. 검증을 지름길로 전역 비활성화하지 마십시오. 그런 다음 테이블, 우선순위, 보호를 구성 소유자에게 넘기고, 재연결 후 새 연결을 열어 선택이 여전히 유지되는지 확인하십시오. 로컬 SMTP 리스너의 응답은 목적지 포트 25가 아니라 소스 포트 25를 운반한다는 점을 기억하십시오(이는 별도의 정책 질문입니다).