불편 포인트: «가끔 안 된다»가 더 어려운 이유
1) 간헐 지연을 인증 탓으로 돌리기. 듀얼 스택에서는 같은 이름에 IPv6를 먼저 시도했다 IPv4로 돌아오는 흐름이 흔합니다. 한쪽 경로가 중간 장비에서 버려지면 TCP 핸드셰이크에서 멈춘 것처럼 보이며 authorized_keys와 무관합니다.
2) DNS 분할. 사내와 사외의 A／AAAA가 다르면 VPN 안팎에서 «같은 이름»이 다른 대기 주소로 갑니다. 원격 Mac의 sshd 로그에는 출발 스택이 바뀌고 known_hosts 기대와 어긋납니다.
3) 방화벽이 반쪽. 22/tcp만 적어도 IPv4와 IPv6 규칙은 따로입니다. 보안 그룹이 IPv4만 열려 있으면 IPv6 세션은 조용히 떨어집니다.
4) CGNAT과 큐. IPv4가 CGNAT이고 IPv6가 더 직접일 때 동시 전송·keepalive를 안 보면 지연이 키 문제처럼 보입니다.
위협 모델과 관측: 네트워크와 세션을 분리
관측은 네 가지로 나누는 편이 좋습니다. DNS의 A／AAAA, TCP RTT, SSH 키 교환 시간, SFTP 첫 지연입니다. 원격 Mac 로그 필터는 방화벽 카운터와 같은 세션으로 맞춥니다. Tailscale／Headscale이 있으면 먼저 «사설 IP만 도달»로 위협을 줄이고 ListenAddress를 단순화합니다.
숫자로 끝내기: 느낌 대신 분포
대륙 간에서는 v4와 v6의 RTT가 20~80ms 차이 나는 일이 흔합니다. Happy Eyeballs 병렬은 수백 ms에서 수 초의 실패 대기를 더합니다. ConnectTimeout과 ServerAliveInterval을 기준선에 두고 이상은 DNS·라우팅 변경과 먼저 대조합니다. CI 쪽 IPv4 NAT 출구가 흔들리면 TCP 도달을 먼저 고친 뒤 MaxAuthTries 논의로 넘어갑니다.
의사결정표: IPv4만, IPv6만, 듀얼 스택
| 상황 | 우선 전략 | 이점 | 리스크 |
|---|---|---|---|
| AAAA만 공개 | 클라이언트 AddressFamily inet6, 서버 v6 대기+v6 방화벽 | 경로가 단순 | 구형 클라이언트는 점프 필요 |
| 듀얼이지만 v6 품질 낮음 | 해당 호스트만 inet 고정 또는 별칭 분리 | 익숙한 경로 유지 | 이후 AAAA 전환과 충돌 가능 |
| 공인·사설 둘 다 있음 | 운영은 사설·mesh, 공인은 유지보수만 | 공격 면 축소 | DNS·라우팅 설계 증가 |
| CI와 사람이 공존 | 계정·포트·주소군 정책 분리 | 디버깅이 CI 한도를 밟지 않음 | 대시보드가 늘어남 |
실행 절차: 해석부터 대기·방화벽까지
# 1) DNS: A와 AAAA가 함께 오는지 (예시 호스트명으로 교체)
# dig +short A your.remote.mac.example
# dig +short AAAA your.remote.mac.example
# 2) 클라이언트: IPv4 고정 예
# Host rm-prod
# HostName your.remote.mac.example
# AddressFamily inet
# ServerAliveInterval 30
# ServerAliveCountMax 6
# 3) 클라이언트: IPv6만
# Host rm-prod-v6
# HostName your.remote.mac.example
# AddressFamily inet6
# 4) 서버: sshd 대기 확인
# sudo sshd -T | egrep 'listenaddress|addressfamily|port'
# 5) 포트 도달 빠른 확인 (v4·v6 각각 가능한 호스트에서)
# nc -vz <host> 22
# nc -6vz <host-v6> 22
1단계: 변경 창에서 DNS를 고정하고 TTL과 권한을 기록합니다.
2단계: 사람과 CI에 Host 별칭을 나누고 CI는 UserKnownHostsFile 정책을 박습니다. known_hosts 고정 글의 형식을 재사용합니다.
3단계: ListenAddress가 ::를 포함하는지, IPv4만 아닌지 확인합니다.
4단계: IPv4·IPv6 방화벽을 나누고 한쪽 적중이 0이면 SSH보다 네트워크를 먼저 봅니다.
5단계: 동시 SFTP와 MaxSessions, ClientAliveInterval을 같은 부하 테스트에 올립니다.
읽기 순서·FAQ·SFTPMAC 호스팅 원격 Mac
예시 순서: 본문→known_hosts→동시 SFTP→시도 제한→ProxyJump→홈.
사내에서 AAAA를 끄면 되나요
장기 해법으로는 비추천입니다. Host를 나누고 AddressFamily를 문서화하며 각자 hosts 파일로 갈라지지 않게 하는 편이 낫습니다.
macOS 클라이언트와 Linux CI가 다릅니다
OpenSSH 버전과 설정 로드 순서를 맞추고 CI에는 ssh -G 출력을 기준선으로 두세요. 차이는 대개 해석과 기본 스택에 있습니다.
rsync에도 같나요
-e ssh이면 동일합니다. Runbook을 공유합니다.
요약: «핑 된다»와 «안정 전송» 사이에는 DNS·스택·대기·방화벽이 있습니다. 인증 전에 네트워크 층을 분리하면 수습이 짧아집니다.
한계: 통신사나 사내 DNS의 AAAA 변경은 조용히 증상을 되돌립니다.
비교: SFTPMAC 호스팅 원격 Mac은 대기와 전송 운용을 제품처럼 맞추기 쉬워, 듀얼 스택 반쪽 조사에 시간을 쓰는 일을 줄이는 데 유리합니다.
스택과 known_hosts를 같은 Runbook에 두고 회귀를 짧게 유지하세요.