DNS가 채우는 nftables 세트에서 WireGuard까지: 인계가 작동하는 방식

이름은 주소로 해석되고, 그 주소는 나중에 라우팅에 영향을 주는 방화벽 세트에 들어갈 수 있어 프록시 없이 이름 기반 유도 가 가능해집니다. 함정은 네 구성 요소가 올바르게 인계해야 한다는 점입니다. 리졸버, 세트, 새 흐름을 표시하는 분류기, 그리고 그것을 나르는 피어입니다. 인계마다 실패 방식이 다르고 각자 자기 시간을 지킵니다.

설계를 구성이 아니라 사슬로 보십시오. 각 단계의 질문은 어느 구성 요소가 결정을 소유하는지, 그 입력이 없을 때 무슨 일이 일어나는지입니다.

DNS 응답이 할 수 있는 일과 없는 일

dnsmasq는 응답에서 주소를 nftables 세트로 복사할 수 있는데, 이는 채우기이지 라우팅 결정이 아닙니다. dnsmasq 설명서 에 문서화된 그 옵션은 주소 체계, 테이블, 세트를 지정하며 맨 앞의 4#는 A 레코드만 고르므로 v6 목적지에는 별도 장치가 필요합니다. 세트는 미리 존재해야 합니다. 리졸버는 방화벽 소유자가 만든 것에 요소를 더할 뿐이기 때문입니다. 그 단계에서는 인터페이스도 테이블도 피어도 고르지 않습니다.

클라이언트도 이름에 그 리졸버를 써야 합니다. 자체 암호화 DNS를 쓰는 앱이나 정책이 생기기 전의 캐시 응답은 세트에 항목을 하나도 만들지 않고 접속합니다.

세트는 입력이고 경로가 아니다

세트의 요소는 일치 조건입니다. 무언가가 그것을 보고, 이 패킷이 새 흐름을 시작한다고 판단하고, 흐름을 터널로 보내는 정책을 적용해야 합니다. Linux에서는 보통 표시를 설정할 수 있는 라우팅 가능한 출력 경로, 표시된 패킷을 전용 테이블로 보내는 규칙, 그 테이블에서 WireGuard 장치를 가리키는 경로를 뜻합니다. 소속만으로는 그중 아무것도 설치되지 않습니다.

nft add set inet vpn_select office_v4 { type ipv4_addr\; }
ip rule add fwmark 0x40 table 200
ip route add default dev wg0 table 200
wg show wg0 allowed-ips

피어는 사람들이 잊는 두 번째 적용 범위 검사를 합니다. WireGuard는 허용 주소에 목적지가 포함된 피어에게만 패킷을 암호화하므로, 피어 목록이 그 프리픽스를 제외하면 인터페이스로 가는 정책 경로만으로는 충분하지 않습니다. 목록은 관리자가 우연히 만드는 경로에 맡기지 말고 라우팅 소유자의 통제 아래 두십시오.

표시, 테이블, 피어 적용 범위

표시는 공유 이름 공간이므로 값과 마스크 모두 그것을 쓰는 다른 모든 것과 합의해야 합니다. 표시된 트래픽을 전용 테이블로 보내는 규칙은 그 테이블에 맞는 경로가 없을 때 정해진 결과가 필요합니다. 응답 없는 조회가 다음 규칙으로 넘어가 패킷을 물리 인터페이스 밖으로 내보낼 수 있기 때문입니다. 전용 테이블 안의 blackhole 기본 경로는 그 조용한 탈출을 보이는 폐기로 바꿉니다. 설계가 여전히 못 하는 것은 세트에 한 번도 들어오지 않은 목적지에 대해 닫힌 상태로 실패하는 것입니다.

터널 자체의 바깥 패킷은 분류기를 벗어나야 합니다. WireGuard 도구는 바로 그 목적을 위해 소켓 표시를 제공하며, 이를 쓰면 캡슐화가 자기가 만드는 인터페이스로 되돌아 라우팅되지 않습니다.

수명을 하나씩 시험하십시오

세 저장소가 세 일정으로 늙어 갑니다. 리졸버 캐시, 세트 요소, 추적되는 연결입니다. 이 순서로 시험하고 각각이 움직여야 할 때 움직이는지 보십시오. 아래 명령은 아무것도 바꾸지 않고 리졸버, 세트, 연결 테이블, 정책 규칙을 읽습니다.

dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show

요소를 더하는 새 조회는 채우기가 작동함을 증명하고, 자기 응답보다 오래 사는 낡은 요소는 적어 둘 가치가 있는 수명 불일치입니다. 연결 테이블에 기대한 표시로 새 연결이 나타나면 분류기가 돌았다는 뜻이고, 옛 연결이 원래 표시를 유지하는 것은 결함이 아니라 올바른 동작입니다. 규칙 목록은 정책 조회가 애초에 존재하는지 답하며, 이는 그것이 일치했는지와 다른 질문입니다. 네 출력을 이 순서로 읽으면 실패한 인계가 스스로 드러납니다.

특정 이름이 항상 한 경로를 쓰도록 요구한다면, DNS가 채우는 세트로는 증명할 수 없습니다. 공유 주소는 다른 이름도 나르기 때문입니다. 프록시나 응용 프로그램 수준의 장치가 그 보장을 위한 도구입니다.