3.0 KiB
3.0 KiB
tags
| tags | ||||||
|---|---|---|---|---|---|---|
|
260311 51123 포트경계 복잡성 및 진입구조불일치 이슈
상위 원칙
관련 문서
- 51123 포트 진입점 프로젝트 경계 리서치
- 23서버 워크스페이스 SSOT 구조전환 리서치
- 23 gateway MONITOR_URL 구주소 잔존으로 24 monitor 프록시 실패 복구
문제
- 51123의 현재 포트 상태는 단순히 “포트가 많다”가 아니라,
공용 진입면,프로젝트 내부 제어면,직접 프록시,직접 외부노출이 섞여 있어 운영 판단 기준이 흐려진 상태다. - 실제로
80/443nginx 외에도8000,8100,8200,8505,9000,9200,9600,5432,7687이 외부 접근 가능한 형태로 보이며, 이 중 무엇이 공식 진입면이고 무엇이 내부용인지 한 문서에서 바로 닫히지 않는다. robeing만 봐도ro-being.com/api/* -> 8100 gateway,ro-being.com/rb8001/* -> 24서버 8001 직접으로 ingress 기준이 이중화돼 있다.
원인
- 프로젝트 수가 늘었지만 포트 관리 기준이
프로젝트별,서버별,ingress별3축으로 아직 고정되지 않았다. - 특히
8100은 현재 사실상robeing 전용 제어면인데, 운영상 공용 API 게이트웨이처럼 읽힐 여지가 남아 있다. goosefarminvesting,starsandi,gitea,auth,robeing이 서로 다른 진입 방식을 쓰지만, 이 차이가 포트 문서나 정책 문서로 아직 승격되지 않아 구조 복잡성이 누적됐다.
영향
- 포트 개방/차단, nginx 경로 변경, health 확인, 장애 판단에서 “어느 경로가 기준인가”를 잘못 읽을 위험이 높다.
- 일부 경로는 정상이어도 다른 경로는 실패하는
부분 정상상태를 운영자가 늦게 인지할 수 있다. - gateway 성격을 잘못 이해하면 멀티프로젝트 공용 변경처럼 건드려 불필요한 영향 범위를 만들 수 있다.
현재 판단
- 이 이슈는 아직
원칙단계보다인프라 트러블슈팅단계다. - 먼저
포트별 책임,공식 ingress,직접노출 허용 여부,23/24 서버 경계를 실행 기준으로 닫아야 한다. - 그 다음에만
포트맵 SSOT나차단/허용 원칙으로 승격할 수 있다.
결론
- 지금의 핵심 문제는 “포트 수”가 아니라 “포트 책임 경계와 진입 구조가 문서 SSOT로 아직 닫히지 않았다”는 점이다.
- 직접 원인은
프로젝트별 진입 방식 차이와gateway 역할의 애매한 해석 가능성이다.