StrongSwan이 Mac이 닿을 수 없는 DNS 주소를 보냅니다

누군가 MacBook을 열기 전까지는 모든 것이 작동합니다. 터널이 맺어지고 내부 호스트는 주소로 응답하지만 이름 해석이 죽습니다. iPhone에서도 같은 프로파일이 똑같이 동작하는 반면 Windows와 Linux 클라이언트는 괜찮습니다. 보통은 보내는 DNS 속성이 원인입니다. 서버가 자기 공용 인터페이스 주소를 배포하고, Apple의 IKEv2 클라이언트는 터널을 통해 그곳으로 질의를 보내지 않습니다. 리졸버를 풀 안으로 옮기면 클라이언트를 건드리지 않고 증상이 사라집니다.

증상은 보내는 주소를 가리킵니다

일부 플랫폼만 실패한다면 터널과 자격 증명은 거의 확실히 정상입니다. 그것들은 공통이기 때문입니다. 다른 점은 각 클라이언트가 받은 구성 페이로드를, 내부 DNS 서버를 포함해, 어떻게 적용하느냐입니다. 주소는 받아들이지만 질의를 터널 밖으로 돌리는 클라이언트는 볼 수는 있지만 쓸 수는 없는 리졸버를 갖게 됩니다.

공용 주소가 흔한 선택인 이유는 관리자가 이미 아는 유일한 주소이기 때문입니다. 또한 터널 자체의 프리픽스 밖에 있다고 보장되는 유일한 주소이며, 바로 그 성질이 Apple 클라이언트를 깨뜨립니다.

무엇이든 바꾸기 전에 값을 보세요. 보내는 리졸버가 서버의 WAN 주소라면 문제의 형태를 찾은 것이므로 나머지 추측은 건너뛸 수 있습니다. 풀 프리픽스와도 비교하세요. 풀 안이지만 임대 범위 밖에 있는 주소가 바로 수정 후의 모습이기 때문입니다. 구성 파일을 두 분 들여다보는 것이 클라이언트에서 반나절 패킷을 잡는 것보다 낫습니다.

임대 범위에서 리졸버를 떼어내기

리졸버가 풀 자체의 서브넷 구성원이 되도록 터널에 주소 계획을 주고, 그 주소를 예약해 어떤 클라이언트에도 임대되지 않게 하세요. 이 예에서 풀은 10.180.7.0/24이고 서버는 10.180.7.1을 보유하며 임대는 10.180.7.2에서 시작합니다.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

풀 프리픽스와 리졸버가 같은 서브넷을 공유하므로 이미 터널 트래픽을 나르는 경로가 질의도 나릅니다. 바로 이 한 가지 성질이 수정을 클라이언트 간에 옮길 수 있게 합니다. swanctl 구성에서는 같은 두 사실이 ipsec.conf 문법이 아니라 풀 정의와 연결의 DNS 설정으로 나타납니다.

서버에 새 물리 인터페이스는 필요하지 않습니다. 루프백 인터페이스에 10.180.7.1을 더하면 리졸버가 바인딩해 응답할 수 있습니다. 클라이언트가 이미 있는 풀 경로로 그곳에 닿기 때문입니다. 주소를 임대 범위 밖에 두어 어떤 클라이언트도 실수로 가져가지 않게 하세요. 풀이 외부 DHCP나 RADIUS 서비스로 관리된다면 거기에도 주소를 예약하세요. 그렇지 않으면 처음 묻는 클라이언트가 가져갑니다.

리졸버를 바인딩하고 포트 53을 닫기

주소를 할당하는 것과 그 위에서 듣는 것은 다릅니다. LAN 주소에서만 듣는 리졸버는 풀 주소로 보낸 질의를 거부하거나 무시하고, 클라이언트는 라우팅 장애처럼 보이는 타임아웃을 봅니다.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

이 unbound 조각은 터널 풀에서 오는 질의를 받아들이고 나머지는 모두 거부합니다. 대부분의 기업 리졸버가 원하는 정책입니다. 같은 인스턴스가 LAN 클라이언트에도 응답한다면 리스너를 모든 출처로 넓히는 대신 LAN 프리픽스를 명시적으로 추가하세요.

그다음 방화벽 규칙이 리졸버 자체의 접근 제어와 맞아야 합니다. 풀에서 오는 포트 53을 허용하고 다른 모든 곳에서는 버리되, 먼저 체인의 순서를 확인하세요.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

앞쪽의 더 넓은 허용 규칙이 있으면 마지막 두 줄은 장식이 되고 리졸버는 인터넷에서 도달 가능한 채로 남습니다. 의도한 순서를 믿는 대신 카운터와 함께 실제 규칙 집합을 읽으세요. 다른 정책, 즉 공용 주소를 보내고 어느 출처에서든 질의를 허용하는 방식은 많은 클라이언트에서 작동하지만 리졸버를 인터넷에 두게 되고 자체 속도 제한과 모니터링이 필요합니다.

클라이언트가 실제로 무엇을 받았는지 확인하기

먼저 서버의 시야를, 다음으로 클라이언트의 시야를 확인하세요. 둘이 유익하게 어긋나기 때문입니다. 풀 목록은 어느 주소가 임대되었는지 보여 주고, 보안 연관 목록은 연결이 기대한 ID로 올라와 있는지 보여 줍니다.

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

직접 질의는 리졸버가 풀 주소에서 그곳에 닿을 수 있는 호스트로부터 응답한다는 것을 증명합니다. Mac이 그 서버를 골랐다는 것은 증명하지 못합니다. macOS에서는 scutil --dns가 범위가 지정된 서비스별로 리졸버를 나열하며 요약 패널보다 정보가 많습니다. Windows에서는 Get-DnsClientServerAddress가 터널 어댑터가 보낸 값을 받아들였는지 보여 줍니다.

클라이언트가 풀 주소를 보여 주는데도 질의가 계속 타임아웃되면, 터널 경로나 방화벽 체인이 원인입니다. 리졸버를 전혀 보고하지 않는 클라이언트는 구성 페이로드가 도착하지 않았다는 뜻이므로 네트워크가 아니라 그 플랫폼이 보낸 설정을 어떻게 적용하는지 보세요. 다른 무엇을 바꾸기 전에 두 경우 중 어느 것을 보았는지 적어 두세요. 이 두 장애는 지원 티켓에서는 똑같아 보이고 반대 방향의 수리로 이어집니다.