pfSense에서 FastDDNS를 실행하는 두 가지 방법
호스트 이름 패널에는 두 가지 설정이 있습니다. 방법 2는 FastDDNS를 내장Services > Dynamic DNS 클라이언트에 Custom 사용자 지정 제공업체로 추가합니다 — pfSense가 이를 구성에 저장하고 백업하므로 이 방법을 유지하는 것이 좋습니다. 방법 1은 셸에 한 줄 스크립트를 붙여 넣어 2분마다 실행되는 크론 작업을 설치합니다. 즉시 작동하지만 pfSense는 해당 작업을 관리하지 않습니다.
아래 번호는 권장 순서가 아니라 패널의 레이블을 따릅니다. 장기적으로는 방법 2를 설정하고, 양식을 작성하지 않고 지금 바로 업데이트를 보내려면 방법 1을 사용하세요.
| 방법 2 — 내장 DDNS 클라이언트 | 방법 1 — crontab 스크립트 | |
|---|---|---|
| 작업하는 위치 | 웹 UI에서Services > Dynamic DNS | Diagnostics > Command Prompt, 또는 SSH |
| pfSense 구성에 저장됨 | 예 | 아니요 — 아래 한도 참조 |
| 구성 복원 또는 재설치 후에도 유지됨 | 예 | 아니요 |
| 업데이트를 보낼 때 | 모니터링하는 인터페이스 주소가 변경될 때와 매일 한 번 재확인할 때 | 2분마다, 변경 여부와 관계없이 |
| 설정에 드는 노력 | 7개의 필드, 그 중 4개는 패널에서 복사됨 | 한 번 붙여넣기 |
| 적합한 용도 | 영구적인 설정 | 즉시 첫 업데이트를 보내거나 빠르게 테스트할 때 |
시작하기 전에
4가지 사항, 그 중 2가지는 원격 액세스가 작동할지 여부를 결정
- FastDDNS hostname. FastDDNS에서 무료로 하나 만든 다음 열고 DDNS Configuration Parameters > Firewall pfSense까지 스크롤하세요.
- pfSense 웹 인터페이스의 관리자 access, Method 1을 사용할 계획이라면 셸 access도 필요합니다.
- WAN 인터페이스에 실제 공인 IP. ISP가 사용자를 Carrier-Grade NAT 뒤에 두고 있다면 DDNS로는 해결할 수 없습니다. hostname이 ISP 외부에서는 누구도 접근할 수 없는 주소를 가리키게 되기 때문입니다. pfSense 대시보드에서 WAN 주소를 확인하거나 FastDDNS 모바일 앱에서 CGNAT Checker를 실행하세요.
- 접속하려는 대상에 필요한 Firewall 및 NAT 규칙. DDNS는 이름이 올바른 주소를 가리키도록 유지할 뿐이며, 접속 방법은 직접 설정해야 합니다. 이후 포트 체크로 확인하세요.
pfSense 대시보드에서 WAN 인터페이스의 주소가 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 또는 100.64.0.0/10 범위에 있으면 상위 네트워크에서 NAT를 수행하고 있다는 뜻입니다. 100.64.0.0/10 범위는 캐리어 그레이드 NAT용으로 예약된 범위입니다.
방법 2 — FastDDNS를 커스텀 동적 DNS 클라이언트로 추가
이 방식은 계속 사용할 만한 설정입니다. pfSense는 이를 config.xml에 저장하므로, 구성을 복원하면 다시 적용되고 재설치 후에도 유지됩니다.
1단계 — 호스트 이름 패널에서 업데이트 URL 복사
호스트 이름을 열고 DDNS Configuration Parameters까지 스크롤한 다음 Firewall pfSense을 펼치세요. 두 방법에 필요한 모든 정보가 이 패널 하나에 있습니다:
업데이트 URL 상자를 Method 2 아래에서 복사합니다. 이미 호스트 이름과 자격 증명이 포함되어 있습니다:
https://client.fastddns.net/?hostname=myhome.fastddns.net&user_name=YOUR-USERNAME&user_pass=YOUR-UPDATE-PASSWORD대문자로 된 세 값은 계정에 공개되지 않는 정보를 나타내며, 패널이 자동으로 입력해 줍니다.
2단계 — 다이내믹 DNS 클라이언트 열기
pfSense 웹 인터페이스에서 Services > Dynamic DNS로 이동한 후 + 추가를 클릭합니다.
3단계 — 필드 입력
| 필드 | 값 | 이유 |
|---|---|---|
| Service Type | Custom |
FastDDNS는 기본 제공업체 목록에 없으며, 목록에 없어도 됩니다. |
| Interface to Monitor | WAN |
주소 변경 시 업데이트를 트리거할 인터페이스 |
| Hostname | 당신의 FastDDNS 호스트명 | 업데이트 URL에 이미 포함되어 있으므로, Custom 유형에서는 주로 목록에 표시될 레이블입니다. |
| Update URL | 1단계의 URL | 전체를 붙여넣으세요. 대체할 %IP%항목은 없습니다. FastDDNS는 요청이 들어온 주소를 기록합니다 |
| Force IPv4 DNS Resolution | 선택됨 | 업데이트 호스트를 IPv4로만 확인하므로 FastDDNS가 기록하는 주소는 IPv6 주소가 아니라 IPv4 WAN 주소입니다 |
| Result Match | 비워 둠 | pfSense는 이 값을 전체 응답과 비교합니다. FastDDNS는 변경 후 good성공을, 변경이 없을 때는 nochg변경 없음을 응답하므로 단일한 고정 문자열이 두 경우에 모두 일치하지 않습니다. 패널의 안내에서도 하나를 설정하지 않습니다 |
| Description | FastDDNS.net |
본인만 참고할 수 있도록 자유롭게 입력 |
4단계 — 저장한 후 상태 열 확인
클릭 저장 및 강제 업데이트. Services > Dynamic DNS 목록으로 돌아가면, 캐시된 IP 열이 현재 WAN 주소로 채워져야 합니다. 빈 항목이거나 강제 업데이트 후에도 오래된 상태로 남아 있다면 업데이트가 완료되지 않은 것입니다. 아래 문제 해결 표에서 원인을 확인할 수 있습니다.
이 방법에 대해 알아둘 점이 하나 있습니다. 2분마다 실행되는 하트비트가 아니라 이벤트 기반으로 작동합니다. Netgate는 서비스를 다음과 같이 문서화합니다:인터페이스 주소가 변경될 때
또한 pfSense는 안전 장치로 기본 cron 항목을 제공하여 하루에 한 번 01:01에 /etc/rc.dyndns.update를 실행합니다. 따라서 업데이트에 실패하면 다시 시도하지만 몇 분 안에는 재시도하지 않습니다. 즉시 업데이트해야 할 때는 저장 및 강제 업데이트를 사용하십시오.
직접 작성한 스크립트로 동일한 엔드포인트를 호출하려면 매개변수가 FastDDNS 클라이언트 API 페이지에 문서화되어 있습니다.
아래 안내는 이전에 녹화된 내용이므로 패널이 여기의 스크린샷과 다르게 보일 수 있습니다. 필드와 단계 순서는 동일합니다.
방법 1 — 한 줄 크론탭 스크립트
1단계 — 호스트네임 패널에서 스크립트 복사
같은 Firewall pfSense 패널에서 Method 1 아래 상자에 있는 스크립트를 복사합니다. 동일한 업데이트 URL을 기반으로 한 한 줄 스크립트입니다:
((crontab -l >/dev/null && crontab -l | grep -i "client.fastddns.net") || ((crontab -l; echo '*/2 * * * * fetch "URL" -o /dev/null || curl -s "URL"') | crontab -; fetch "URL" -o /dev/null || curl -s "URL"; printf "\n\nAdded Dynamic DNS Script to crontab successfully\n\n"; exit 1;)) && printf "\n\nFastDDNS is available \n\n";실제 줄에서는 각 URL이 방법 2의 1단계에서 복사한 전체 업데이트 URL입니다. 직접 조합하지 말고 패널에서 복사하십시오.
2단계 — 실행
한 줄을 셸 명령 실행 상자에 Diagnostics > Command Prompt붙여넣은 다음 실행를 누르십시오. SSH 세션이나 콘솔에서 옵션 8을 사용해도 됩니다.
Netgate의 자체 경고는 이 페이지 전반에 적용됩니다. 붙여넣은 내용은 무엇이든 전체 권한으로 실행되며, 잘못된 명령은 방화벽을 사용할 수 없게 만들 수 있습니다. 패널에서 복사한 줄만 붙여넣으십시오. 명령은 완료된 후 반환되어야 합니다. 이 명령은 그렇게 작동하므로 여기에서 실행해도 안전합니다.
3단계 — 두 메시지의 의미
출력 마지막에 다음 두 줄 중 하나가 표시되는지 확인하십시오. 두 줄은 서로 다른 의미를 가집니다:
| 메시지 | 무슨 일이 있었는지 |
|---|---|
| Added Dynamic DNS Script to crontab successfully | crontab에 FastDDNS 항목이 없었기 때문에 하나를 추가하고 즉시 업데이트를 보냈습니다 |
| FastDDNS is available | 항목이 이미 있었으므로 아무것도 변경되지 않았습니다 |
확인은 전체 crontab에서 client.fastddns.net에 대한 단순한 grep입니다. 이렇게 하면 작업을 두 번 설치하는 것을 막을 수 있습니다. 하지만 같은 방화벽에 두 번째 호스트명을 추가하면 스크립트가 첫 번째 호스트명을 보고 아무 것도 추가하지 않음을 의미하기도 합니다. 두 번째 호스트명은 cron 라인을 수동으로 추가해야 합니다.
그 grep 때문에 두 번째 실행에서 한 줄만이 아니라 여러 줄이 출력됩니다. 일치 항목이 출력되고, 일치하는 줄은 cron 항목이므로 업데이트 URL 전체가 표시됩니다. 사용자 이름과 비밀번호도 포함됩니다. 다른 사람에게 화면을 보여 주면서 실행하거나 출력을 티켓에 붙여넣는다면, 해당 줄은 잘라내야 합니다.
예약된 줄 자체는 fetch을 실행하며, fetch은 pfSense가 제공하는 FreeBSD 다운로드 도구이고, 실패할 경우 curl으로 대체됩니다.
4단계 — 의존하기 전에 알아야 할 제한
pfSense는 자체 예약 작업을 config.xml에 보관하고, 여기에서 시스템 crontab을 다시 작성합니다. crontab -로 추가한 작업은 대신 root 사용자의 crontab에 저장됩니다. pfSense는 이를 관리하지 않으며 설정 백업에도 포함하지 않습니다. 결과는 두 가지입니다.
- 설정을 복원하거나 방화벽을 다시 설치하면 이 작업은 사라집니다. 방법 2의 Dynamic DNS client는 남아 있습니다.
- 만약 System > Advanced > Miscellaneous가
/tmp와/var용 RAM 디스크를 활성화했다면 root crontab은 RAM에 저장됩니다. Netgate 문서에 따르면 이러한 RAM 디스크에서 재부팅 후 보존되는 것은 RRD 데이터, DHCP 임대, 로그 및 Captive Portal 데이터뿐입니다. crontab은 목록에 없습니다.
그렇다고 방법 1이 잘못된 것은 아닙니다. 업데이트를 지금 받는 좋은 방법이지만, 1년 동안 계속 유지하기에는 적합하지 않습니다. pfSense가 실제로 유지하는 cron 작업을 원한다면 Cron 패키지를 설치하고 같은 줄을 그 패키지를 통해 추가하십시오.
이전 패널 디자인에서 스크립트 방식을 보여 주는 또 다른 오래된 기록입니다.
호스트명이 실제로 업데이트되고 있는지 확인하십시오.
어떤 방법을 사용했든 세 가지 관점에서 확인하십시오.
pfSense에서 Services > Dynamic DNS각 항목에 대해 캐시된 IP를 보여줍니다 — WAN 주소와 일치해야 합니다. 대신 방법 1을 사용했다면 작업이 존재하는지 확인하고 셸에서 한 번 수동으로 실행하세요:
crontab -l
fetch -o - "PASTE-YOUR-UPDATE-URL-HERE"두 번째 명령은 서버의 응답을 출력합니다. 주소가 방금 변경된 경우 good로 시작해야 하고, 이미 올바른 경우 nochg로 시작해야 하고, 이미 올바른 경우 badauth는 문제를 정확히 지적하는 유일한 응답입니다: 사용자 이름 또는 업데이트 암호가 잘못되었습니다. 다른 응답이 오거나 응답이 전혀 없으면 자체적으로 설명되지 않으므로 — 실제로 돌아온 내용을 읽고 시스템 로그를 확인하세요.
로 시작해야 합니다 — FastDDNS는 기록된 주소를 덧붙일 수 있습니다.
nslookup myhome.fastddns.net마지막으로, 호스트 이름 패널에 마지막 업데이트외부에서 hostname을 확인하고 공용 주소와 비교하세요:Not yet updated에서 변경됩니다. FastDDNS는 60초 이내에 새로운 주소를 적용하지만, 로컬 DNS 캐시는 이전 주소를 조금 더 오래 유지할 수 있습니다.
Last Updated
| 타임스탬프가 표시됩니다. 방화벽이 처음 보고한 시점부터 | 시간이 지나면 | 대처 방법 |
|---|---|---|
응답은 badauth확인되는 현상 |
원인 | 해결 방법No-IP 또는 DynDNS 서버 주소 교체응답이 |
| Cached IP가 저장 후에도 비어 있음 | 입니다 | 패널에서 Update URL을 다시 복사하세요. 다른 제공업체에서 이전했다면 관련 가이드를 참조하세요.Status > System Logs > System > General저장 후에도 Verbose Logging가 비어 있습니다 |
| 업데이트 호스트에 연결하지 못했거나 URL이 붙여넣는 과정에서 잘렸을 수 있습니다 | 업데이트 호스트가 IPv6를 통해 연결되었으므로 기록된 주소는 해당 주소입니다 | Dynamic DNS 항목의 확인란을 Force IPv4 DNS Resolution선택하고 업데이트를 강제로 수행하십시오 |
| hostname이 올바르더라도 모든 업데이트가 실패로 기록됩니다 | Result Match는 고정 문자열로 설정되어 있으며, 응답은 good와 nochg 사이에서 번갈아 나타납니다 |
결과 확인을 끄려면 Result Match 필드를 지우십시오 |
| 방법 1은 작동했지만 재부팅이나 설정 복원 후 중지되었습니다 | 크론 작업은 config.xml 외부에 있으며, RAM 디스크에 둘 수 있습니다 |
대신 방법 2를 설정하거나 Cron 패키지를 통해 줄을 추가하십시오 |
| 호스트 이름이 확인되지만 포트에서 아무 것도 응답하지 않습니다 | DDNS는 작동하지만 네트워크로 들어오는 경로가 작동하지 않습니다 | NAT 및 방화벽 규칙을 추가한 후 포트 확인을 사용해 외부에서 테스트하십시오 |
| hostname이 확인되지만 공개 IP가 아닌 주소로 확인됩니다 | 방화벽은 또 다른 NAT 계층 뒤에 있으며, 흔히 CGNAT이 그 예입니다 | 대시보드의 WAN 주소를 공용 IP 조회 결과와 비교하세요. 다르면 ISP에 공용 IP를 요청하세요 |
| 모든 것이 잘 작동하다가 몇 달 후 중단되었습니다 | 무료 호스트 이름은 1년에 한 번 갱신되며, 임시 호스트 이름은 30일 동안 유효합니다 | 계정에서 갱신하거나, 호스트 이름이 만료되지 않는 플랜으로 이동하세요 |
업데이트 URL은 비공개로 유지하세요
업데이트 URL에는 hostname, 사용자 이름 및 업데이트 비밀번호가 일반 쿼리 매개변수로 포함되어 있습니다. 이 정보는 pfSense 구성에 그대로 저장되며, 방법 1을 사용하면 crontab에도 저장됩니다. 구성 백업을 읽을 수 있는 사람은 누구나 이 자격 증명을 볼 수 있습니다. pfSense 구성 내보내기는 비밀번호 파일과 동일하게 취급하고, 편집하지 않은 업데이트 URL을 포럼 게시물이나 지원 티켓에 절대 붙여넣지 마세요. 이미 붙여넣었다면 계정에서 업데이트 비밀번호를 변경하고 항목을 다시 구성하세요.
자주 묻는 질문
Dynamic DNS 클라이언트를 사용해야 하나요, 아니면 cron 스크립트를 사용해야 하나요?
계속 사용할 항목에는 Services > Dynamic DNS에서 Dynamic DNS 클라이언트를 사용하세요. pfSense는 이를 구성에 저장하므로 백업에 포함되며 재설치 후에도 복원됩니다. cron 스크립트는 첫 업데이트를 빠르게 전송하는 방법이지만, pfSense가 해당 작업을 관리하지 않으므로 재부팅이나 구성 복원 후 사라질 수 있습니다.
DDNS 업데이트 자체를 위해 port를 열어야 하나요?
아니요. pfSense는 FastDDNS로 아웃바운드 HTTPS 연결을 열기 때문에 업데이트에 인바운드 규칙이 필요하지 않습니다. 호스트 이름을 통해 연결하려는 서비스에는 여전히 port forwarding과 방화벽 규칙이 필요합니다. 예를 들어 RTSP에는 554 port를, 카메라에는 웹 port를 설정해야 합니다.
패널에서 IPv4 해석을 강제하라고 하는 이유는 무엇인가요?
FastDDNS는 요청이 도착한 주소를 기록하기 때문입니다. pfSense가 업데이트 호스트를 IPv6 주소로 해석하고 IPv6로 연결하면 해당 주소가 기록되므로 A record가 잘못되거나 비어 있게 됩니다. IPv4 해석을 강제하면 게시하려는 주소와 동일한 프로토콜로 업데이트할 수 있습니다.
ISP가 CGNAT를 사용하는 경우에도 작동하나요?
아니요. Carrier-Grade NAT 뒤에서는 방화벽에 자체 공용 IP가 없으므로 hostname이 유용하게 가리킬 주소가 없고, ISP가 인바운드 연결을 차단합니다. Dynamic DNS는 주소 변경 문제를 해결할 뿐, 주소가 없는 문제를 해결하지는 않습니다. ISP에 공용 IP 주소를 요청하거나 아웃바운드 터널링을 사용하는 서비스를 이용하세요.
엣지에서 다른 장치를 실행 중인가요? 동일한 업데이트 URL은 예약된 HTTPS 요청을 보낼 수 있는 모든 곳에서 작동하며, MikroTik RouterOS 설정도 포함됩니다.
