왜 Fedora에서는 Ubuntu 튜토리얼만으로는 부족할까요
Fedora 워크스테이션은 데스크톱 사용자에게 친숙한 GNOME 경험을 주지만, 밑바닥에서는 dnf 패키지 관리, SELinux 강제 모드, firewalld, 그리고 최신 커널을 빠르게 따라가는 릴리스 정책이 한데 얽혀 있습니다. Clash Meta(Mihomo)를 단일 바이너리로 /usr/local/bin에 두고 systemd로 띄우는 패턴 자체는 Ubuntu와 크게 다르지 않습니다. 그러나 동일한 유닛 파일을 복사해 왔는데도 「실행은 되는데 TUN만 켜면 조용히 죽는다」「재부팅 후 DNS만 이상하다」「감사 로그에 SELinux 거부가 찍힌다」처럼 배포판 특유의 마찰에서 시간을 쓰는 경우가 많습니다.
이 글의 목표는 세 가지입니다. 첫째, Fedora Clash Meta 설치를 dnf로 보강할 수 있는 최소 도구와 바이너리 배치 관례까지 포함해 한 흐름으로 정리합니다. 둘째, Linux systemd 자동 시작을 유저 유닛과 시스템 유닛 관점에서 나누고, Fedora에서 흔한 systemctl --user·linger 이슈를 짚습니다. 셋째, Linux TUN 권한을 capability와 실행 주체에 맞춰 연결하고, SELinux·systemd-resolved·라우팅을 켜는 순서로 분리해 디버깅 비용을 줄입니다. Ubuntu 절차와의 대조가 필요하면 Ubuntu용 Clash Meta·systemd·TUN 글을 함께 열어 두고 읽으면 차이가 빨리 정렬됩니다.
사전 준비: 버전 확인, dnf 패키지, 커널 모듈
Fedora 40·41 등 최신 워크스테이션을 가정합니다. 먼저 아키텍처가 릴리스 아티팩트와 맞는지 확인하고, 서버가 아닌 노트북이라면 보안 부팅·펌웨어 정책이 바이너리 실행에 영향을 주지 않는지 점검합니다. 최소한 다음 범주의 패키지는 미리 깔아 두면 라우팅·DNS 진단이 수월합니다. 예시는 설명용이며, 환경에 맞게 그룹을 줄여도 됩니다.
# Example only — run with sudo where your site policy requires it
sudo dnf install -y iproute bind-utils curl ca-certificatesip route·ss·dig가 없으면 TUN 전환 직후의 증상을 「느리다」로만 느끼게 되어 원인 분리가 늦어집니다. 커널에 TUN 디바이스가 있는지는 대부분 기본 모듈로 충분하지만, 커스텀 커널이나 특수 이미지를 쓴다면 /dev/net/tun 존재 여부를 직접 확인하세요. Silverblue·Kinoite처럼 불변 베이스를 쓰는 변형 Fedora라면 rpm-ostree 레이어에 도구를 넣거나 툴박스 컨테이너에서 진단하는 편이 안전합니다. 이 글은 전통적인 패키지 기반 워크스테이션을 주 무대로 합니다.
바이너리 출처는 조직 정책을 따릅니다. 개인 장비라면 공식 다운로드 페이지에서 플랫폼별 패키지 정책을 먼저 확인하고, 체크섬·릴리스 노트는 신뢰 검증을 위해 별도로 열람하는 흐름이 혼선이 적습니다. 코어 버전을 올릴 계획이 있다면 Mihomo 업그레이드 가이드의 백업·호환성 절차를 같은 스프린트에 넣어 두면 YAML 스키마 차이로 인한 재기동 루프를 줄일 수 있습니다.
디렉터리·실행 사용자: 홈 대비 /etc, 퍼미션
개인 워크스테이션에서는 ~/.config/mihomo 아래에 config.yaml과 캐시를 두고 systemd 유저 유닛으로 실행하는 구성이 단순합니다. 팀 표준으로 구성을 고정하려면 /etc/mihomo에 두고 전용 Unix 계정과 시스템 유닛을 쓰는 편이 감사·백업에 유리합니다. 어떤 쪽이든 config.yaml에는 민감한 구독 정보가 들어가므로 퍼미션을 600 또는 640으로 제한하고, 저장소에 예제를 올릴 때는 반드시 익명화한 스텁만 공유하세요.
바이너리는 /usr/local/bin/mihomo에 두면 셸 어디서나 동일한 이름으로 호출할 수 있습니다. Fedora는 패키지 관리자가 관리하는 /usr/bin과 관리자가 올리는 /usr/local/bin의 경계가 비교적 명확하므로, 업스트림 zip을 풀어 넣는 워크플로에는 후자가 충돌이 적습니다. 실행 파일 소유자는 배포 정책에 맞추되, SELinux 맥락에서 실행 파일 타입이 기본값에서 벗어나면 추가 단계가 필요할 수 있습니다. 다음 절에서 다룹니다.
SELinux와 바이너리: 거부 로그를 먼저 읽기
Fedora 기본은 SELinux enforcing입니다. 임의 경로의 바이너리를 systemd가 실행할 때 execmem·name_connect 같은 권한이 막히는 사례가 있습니다. 증상이 「프로세스가 바로 종료된다」처럼 막연하면 ausearch -m avc -ts recent나 그래픽 도구로 거부 로그를 먼저 확인하세요. 원인이 확인되기 전에 광범위하게 permissive 모드로 내리는 것은 운영 환경에서 권장되지 않습니다.
해결책은 보통 세 갈래입니다. 첫째, 바이너리와 설정 디렉터리를 배포판이 기대하는 라벨 아래로 옮기거나 restorecon으로 맞춥니다. 둘째, 정책 모듈을 작성해 최소 권한만 허용합니다. 셋째, 애플리케이션을 컨테이너나 별도 네임스페이스로 격리합니다. Clash 계열은 네트워크 스택을 넓게 건드리므로, 보안 팀이 있다면 허용할 capability 목록을 문서에 적어 두고 변경을 PR로 관리하는 편이 안전합니다. 개인 장비에서도 「임시로 permissive」보다는 AVC 한 줄을 근거로 조치하는 습관이 장기적으로 이득입니다.
firewalld와 로컬 리스너: TUN 이전에 충돌 제거
Fedora 워크스테이션은 firewalld가 켜져 있는 경우가 많습니다. Mihomo가 mixed-port로 로컬에 바인딩할 때는 기본적으로 루프백 접근이 중심이지만, allow-lan을 켠 상태에서 다른 존으로부터 붙게 만들면 존 규칙과의 관계를 이해해야 합니다. TUN은 방화벽 존과 별개로 라우팅 테이블을 바꾸므로, 증상이 「특정 앱만 안 된다」일 때는 firewalld보다 DNS·정책 라우팅을 먼저 의심하는 편이 일반적입니다.
그럼에도 불구하고 재현 환경에 따라 rich rule이 간섭할 수 있으니, 문제를 좁힐 때는 firewall-cmd --list-all 스냅샷을 정상 시점과 비교해 보세요. 서버 역할을 겸하는 워크스테이션이라면 관리 구간과 클라이언트 구간을 네트워크 관점에서 분리해 문서화하는 것이 이후 장애 대응을 빠르게 합니다.
TUN은 나중에: mixed 포트로 규칙·노드를 먼저 검증
Ubuntu 글과 동일하게, systemd에 넣기 전에 포그라운드에서 한 번 기동해 로그를 직접 보는 순서를 권합니다. config.yaml에서 tun.enable은 false로 두고, mixed-port 또는 port·socks-port 조합으로 HTTP/SOCKS 경로에서 노드와 규칙 매칭을 먼저 확인합니다. 이렇게 하면 Linux TUN 권한 이슈와 무관하게 구독 갱신 실패나 MATCH 폴백 오류를 분리할 수 있습니다.
회사 프록시 뒤에서 구독 URL이 막히면 초기 기동만 실패하는 경우가 흔합니다. 같은 셸에서 curl로 URL 응답 코드를 확인하고, DNS가 사내 리졸버를 가리키는지 resolvectl status로 교차 검증하세요. Fedora는 systemd-resolved 스텁 리스너가 기본인 경우가 많아, fake-ip와의 조합에서 Ubuntu와 비슷한 루프 증상이 나타나기도 합니다. 개념 정리는 TUN 모드 가이드를 함께 참고하면 Windows·macOS와의 차이를 빠르게 맞출 수 있습니다.
systemd 유저 유닛으로 자동 시작
개인 계정으로만 쓸 때는 ~/.config/systemd/user/mihomo.service를 만듭니다. After=network-online.target와 Wants=network-online.target를 함께 쓰면 유선·무선이 올라온 뒤 기동하기 쉽습니다. 저장 후 systemctl --user daemon-reload, systemctl --user enable --now mihomo.service 순으로 적용합니다. 로그인 전에도 유저 서비스를 띄우려면 loginctl enable-linger가 필요할 수 있는데, 이는 조직 정책과 충돌할 수 있으니 회사 장비에서는 시스템 유닛을 검토하세요.
[Unit]
Description=Clash Meta (Mihomo) for Fedora user session
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
WorkingDirectory=%h/.config/mihomo
ExecStart=/usr/local/bin/mihomo -d %h/.config/mihomo
Restart=on-failure
RestartSec=3
[Install]
WantedBy=default.target재부팅 후에는 systemctl --user status mihomo.service와 journalctl --user -u mihomo.service -b로 동일 커맨드 라인이 재현되는지 확인합니다. 실패가 반복될 때 RestartSec을 지나치게 짧게 두면 로그 폭주가 생길 수 있으니 운영 값으로 조정하세요.
시스템 유닛, 전용 계정, capability 경계
게이트웨이나 항상 켜 두는 소형 PC라면 /etc/systemd/system/mihomo.service에 두고 User·Group을 전용 계정으로 고정합니다. CapabilityBoundingSet·AmbientCapabilities·NoNewPrivileges는 보안 가이드에 맞춰 조정하고, TUN을 시스템 서비스로 켤 때는 CAP_NET_ADMIN 요구와 실제 유닛 설정이 일치하는지 리뷰합니다. 유닛 안에서 불필요하게 root를 유지하지 않도록 분리하는 것이 좋습니다.
Fedora에서 라우팅 스냅샷은 ip rule·ip route show table all로 남겨 두면 TUN 전환 직후의 「전부 끊김」과 「일부 앱만 끊김」을 빠르게 구분할 수 있습니다. 운영 문서에 정상 시 출력을 붙여 두는 습관은 팀 온보딩에도 도움이 됩니다.
TUN 켜기 순서: capability → 설정 → 재기동 → 라우팅
가장 흔한 실패는 권한입니다. 바이너리에 cap_net_admin을 부여하는 패턴은 배포판마다 문법이 조금씩 다르지만, Fedora에서는 패키지로 제공되는 libcap 도구를 사용하는 예가 많습니다. 조직에서 setcap 사용을 제한한다면 시스템 유닛의 AmbientCapabilities로 한정하는 타협도 있습니다. 어떤 방식이든 최소 권한과 변경 사유를 문서에 남기세요.
# Example only — verify path and policy before running
sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo
getcap /usr/local/bin/mihomo그다음 config.yaml에서 tun.enable: true와 스택(system·gvisor 등)을 문서에 맞게 설정하고, 한 번에 모든 실험 옵션을 켜지 말고 단계적으로 적용합니다. 재기동 후에는 가상 인터페이스가 생겼는지, 기본 라우트와 충돌하지 않는지, DNS가 루프에 빠지지 않았는지 순서로 확인합니다. 중간에 막히면 TUN을 다시 끄고 mixed 경로로 되돌린 뒤 로그의 rule hit부터 다시 보는 것이 정신 건강에 이롭습니다.
systemd-resolved와 DNS 섹션 정렬
Fedora 워크스테이션은 로컬 스텁(127.0.0.53 등)을 경유하는 구성이 흔합니다. Mihomo의 DNS 모드가 fake-ip라면 도메인 규칙과의 상호작용을 로그로 꼭 확인하세요. 사내 분할 DNS를 쓰는 경우에는 업스트림 고정과 예외 도메인을 프로필에 명시적으로 적어 두는 편이 안정적입니다. 테스트는 dig·resolvectl query로 분리해, 애플리케이션이 실제로 보는 응답을 교차 검증합니다.
증상이 「브라우저만 이상하고 터미널은 정상」처럼 갈리면 데스크톱 프록시 UI·브라우저 확장·컨테이너 내부 DNS를 각각 의심합니다. TUN이 켜진 뒤에는 일부 앱이 이미 터널 경로를 타므로 UI 설정이 중복되어 보일 수 있습니다. 한 가지 주 경로를 정하고 나머지를 정리하는 편이 덜 혼란스럽습니다.
환경 변수, GNOME 프록시, Wayland 메모
TUN이 모든 앱을 완벽히 가로채지 못하는 예외가 있거나, 개발 도구에만 명시적 프록시를 주고 싶다면 http_proxy·HTTPS_PROXY·ALL_PROXY·no_proxy를 셸 프로필에 넣습니다. 값은 mixed 포트의 스킴과 일치해야 하며, HTTP로 연 포트를 socks5://로 적는 실수가 잦습니다. 컨테이너·언어별 패키지 매니저는 각자 프록시 설정을 따로 두는 경우가 많으니 팀 문서에 최소 예제를 남기세요.
Wayland·Xorg 차이 자체가 프록시를 바꾸지는 않지만, IDE가 내장 터미널에서 별도 네임스페이스를 쓰는 경우 루프백 경로가 달라질 수 있습니다. 증상이 특정 터미널에서만 재현되면 프로세스 트리를 분리해 보세요.
점검 순서: 재부팅, 포트, TUN, SELinux, DNS
첫째, 재부팅 후 유저 유닛이 비활성이면 linger와 default.target 의존성을 확인합니다. 둘째, 기동 실패가 포트 충돌이면 ss -lntp로 리스너를 봅니다. 셋째, TUN 직후 전면 단절이면 라우팅과 DNS 루프를 우선 봅니다. 넷째, 프로세스는 떠 있는데 일부 연결만 실패하면 SELinux AVC와 노드 품질을 병행합니다. 다섯째, 커스텀 보안 모듈이나 회사 에이전트가 가상 인터페이스 생성을 막는지 journalctl -k와 사용자 로그를 함께 봅니다.
원인을 좁힌 뒤에는 정상 시의 라우팅·DNS·리스너 스냅샷을 비공개 위키에 남겨 다음 장애 때 비교할 수 있게 합니다. 작은 셸 스크립트로 수집해 두면 Fedora처럼 커널 업데이트가 잦은 환경에서 특히 이득입니다.
정리
Fedora 워크스테이션에서 Clash Meta(Mihomo)를 안정적으로 쓰려면 Ubuntu 때와 마찬가지로 「바이너리·구성 디렉터리·실행 사용자」를 먼저 고정하는 것이 출발점입니다. 여기에 dnf로 진단 도구를 갖추고, SELinux 거부 로그를 습관적으로 읽으며, systemd 유닛으로 재부팅 후에도 같은 커맨드 라인이 재현되게 만든 뒤, 마지막으로 TUN을 capability·DNS·라우팅 순으로 켜면 막힘을 빠르게 통과할 수 있습니다. 장기적으로는 코어 버전과 프로필 스키마를 팀 표준으로 묶어 두면 커널 업데이트가 잦은 Fedora에서도 회귀 비용이 줄어듭니다.
비슷한 범주의 도구들 가운데에서도 Clash 계열은 규칙 기반 분기와 프로바이더 패턴이 성숙해 있어, 데스크톱과 소형 게이트웨이를 오가는 사용자에게 특히 잘 맞습니다. 고급 규칙 설계는 문서 허브의 관련 챕터를 함께 참고하면 좋습니다. 다른 배포판에서 이미 익숙한 GUI 클라이언트가 있다면, Linux 서버나 워크스테이션에서는 오늘 정리한 순서를 온보딩 체크리스트로 그대로 써도 무방합니다.