MTU, PMTUD, DF 비트: HK/JP/KR/SG/US 클라우드 Mac mini로의 세션 중간 SSH/SCP 정체(2026)
팀이 홍콩, 일본, 한국, 싱가포르, 미국에 있는 Mac mini M4를 빌리는 이유는 지리가 왕복 지연을 바꾸기 때문이지 마법이 아니다. 그런데도 많은 엔지니어는 ssh 배너까지는 멀쩡한데 SSH로 하는 SCP나 git push에서 처리량이 거의 0에 가깝게 떨어지고 양쪽 CPU는 놀고 있는 것을 본다. 과소 진단되는 원인 중 하나는 PPPoE, MPLS, GRE, IPsec 오버레이 사슬에서 경로 MTU 탐색(PMTUD)이 깨지는 경우다. 중간에서 ICMP Fragmentation Needed가 조용히 버려지고 TCP는 여전히 Don’t Fragment(DF)를 세운다. 이 2026 가이드는 손실 많은 WAN과 MTU 블랙홀을 분리하고, 증상 매트릭스, 터널 오버헤드 치트 시트, 운영 티켓에 붙일 7단계 런북을 제공한다. DNS 거짓이나 캡티브 포털이 아님이 확인되면 MTR 경로 진단, 기업 VPN 라우팅, 리전 간 지연 최적화와 교차 검증하라.
감정적 오진은 흔하다: 누군가 리전을 바꾼 뒤 증상이 나타났다고 「싱가포르 mini 탓」으로 몰아간다. 실제로는 노트북이 새 ZTNA 프로필로 바뀌어 MSS가 달라졌을 뿐일 수 있다. 에스컬레이션에는 리전 라벨과 캡슐화 스택을 함께 적어라—재무는 전자, 넷엔지는 후자를 본다.
클라우드 Mac 경로에서 MTU 블랙홀을 실제로 겪기 쉬운 사람
소비자 VPN + 기업 VPN + Wi‑Fi 통화 핸드오프를 겹치면 위험이 크다. 대화형 셸은 작게 유지되고 scp로 큰 아티팩트를 밀어넣는 개발자가 먼저 느낀다—키 입력은 작은 MSS 창에 들어가지만 벌크 TCP는 세그먼트를 키우려 한다. SRE가 HTTPS만 curl --range로 테스트하면 SSH를 놓칠 수 있다—TLS 스택이 다른 세그먼트 크기를 고르거나 미들박스가 TCP/22와 443을 다르게 다루기 때문이다.
- 상시 ZTNA: 유선과 무선을 비교하기 전까지 유효 MSS가 사용자에게 보이지 않는다.
- 셀룰러 테더링: 상·하행 베어러 간 MTU 비대칭.
- 레거시 방화벽: PMTUD에 필요한 ICMP까지 모두 버리도록 설정된 경우.
증상 매트릭스: MTU 블랙홀 vs 손실 vs DNS
| 관측 | 가능한 계층 | 빠른 증명 | 1차 완화 |
|---|---|---|---|
셸은 되는데 수 GB scp가 고정 %에서 멈춤 | 경로 MTU / DF | 작은 파일 vs 500 MB, 유선 우회 비교 | 터널 IF에서 MSS 클램프 또는 정책에 따른 DF 테스트 |
| MTR에서 마지막 홉 손실 증가 | WAN 혼잡 | MTR 가이드 | 데이터를 가진 뒤 시간대나 리전 변경 |
| TCP 연결이 완료되기 전에 실패 | DNS 또는 ACL | DNS 리졸버 글 | 리졸버나 SG ACL 수정—MTU 아님 |
| HTTPS는 되는데 게스트 SSID에서만 SSH 실패 | 캡티브 포털 | 게스트 Wi‑Fi 플레이북 | 먼저 포털 완료 |
터널 오버헤드 치트 시트(계획용 숫자, 보장 아님)
| 세그먼트 유형 | 전형적 추가 헤더 | IT에 물을 것 |
|---|---|---|
| PPPoE 라스트마일 | 순 이더넷 대비 약 8바이트 | CPE가 baby jumbo류 프레임을 강제하는지 |
| GRE 또는 IPIP 사이트 간 | 옵션에 따라 24바이트 이상 | 터널 끝에서 MSS 동기화 여부 |
| IPsec 터널 모드 | ESP/AH 후 흔히 50–90바이트 | UDP 캡슐이 바깥 IP를 한 겹 더 씌우는지 |
| WireGuard 오버레이 | 기준 32바이트 + 정렬 | 인터페이스 MTU와 언더레이 비교 |
리전을 탓하기 전 7단계 런북
- 크기로 재현: 같은 SSH 멀티플렉스로 1 KB, 10 MB, 1 GB를 전송하고 처리량이 무너지는 지점을 기록한다.
- 변수 제거: 보안 승인 하에 VPN을 한 번 끄고 재시도. 속도가 돌아오면 MSS 단서를 IT 티켓에 넣는다.
- 캡슐 로깅: 노트북 인터페이스 MTU와
ifconfig또는networksetup스냅샷의 utun을 남긴다. - TCP가 안정된 뒤 MTR로 단순 손실 위장이 아님을 증명—링크된 가이드를 따른다.
- 보수적 MSS: neteng가 ICMP 정책을 검증하는 동안
~/.ssh/config에서IPQoS throughput이나 TCP 윈도 상한을 임시로 내리는 팀도 있다. - 키프얼라이브: AutoSSH/Mosh 패턴과 결합해 유휴 세션이 전송 중 정체를 가리지 않게 한다.
- 위키 갱신: 「알려진 나쁜 VPN 프로필 + 리전 쌍」을 적어 다음 엔지니어가 주말에 물리를 다시 증명하지 않게 한다.
SCP, SSH 경유 Git, rsync: 왜 먼저 아픈가
벌크 전송은 TCP 창을 빨리 연다. 대화형 셸은 에코가 작아 사람을 속인다. git 팩과 컨테이너 레이어는 효과를 증폭한다. 부분 완화가 먹혔다면 압축(-C)이 도움이 됐는지 기록하라—압축은 세그먼트 크기를 바꿔 MTU 절벽을 우연히 피할 수 있어 분류에는 유용하지만 장기 정책은 아니다.
VPN 정책, DNS, 게스트 Wi‑Fi, 가격으로의 다리
MTU는 제로 트러스트 라우팅, DNS 리졸버 장애, 게스트 Wi‑Fi 포털 위가 아니라 옆에 있다. 경로가 정직해지면 측정 스토리에 맞는 리전을 가격 페이지로 고르고, 헬프 센터 SSH 레시피를 재무가 보는 Confluence와 같은 공간에 둔다.
FAQ
대화형 SSH는 괜찮은데 큰 SCP만 멈추는 이유? 작은 세그먼트는 경로 MTU 아래에 있다. ICMP가 필터되고 DF로 단편화가 막히면 벌크 TCP가 블랙홀에 부딪힌다.
캡티브 포털과 같나요? 아니요—포털은 보통 DNS를 먼저 깨뜨린다. 신뢰할 수 없는 SSID는 게스트 Wi‑Fi 전용 글을 쓴다.
MTU 때문에 리전을 바꿔야 하나요? 경로를 증명한 뒤에만. 노트북 VPN 캡슐이 종종 대양 거리보다 MSS를 더 지배한다.
MTU를 고친 뒤에도 ProxyMac 전용 Mac mini가 필요한 이유
MSS가 정상이어도 긴 scp 세션에는 예측 가능한 단일 테넌트 CPU, 네이티브 macOS 도구, 실제 사용자와 맞는 HK / JP / KR / SG / US 배치가 필요하다—단일 관측점에서 가장 싼 ping을 고르기 위해서가 아니다. ProxyMac 렌탈로 측정한 API 리전 옆에 mini를 박아 가격 옆에 문서화하고 스프린트가 끝나면 회수할 수 있다—WAN 논쟁을 증명하려고 노트북을 세관 넘겨 보낼 필요가 없다.
