Home Server on Joonlog

Obsidian Custom 설정

Tue, 19 May 2026 09:00:00 +0900

Obsidian으로 이관한 뒤, 실제 사용에 맞게 폴더 노트와 정렬 방식을 맞춘 기록

Notion에서 Obsidian으로 넘어온 이유는 이전 글에 따로 정리했다. 이 글은 그 다음 단계에 가깝다.

Obsidian으로 넘어온 뒤 실제로 쓰려면 노트 구조를 먼저 정해야 했다. 파일만 계속 쌓이면 시간이 지날수록 찾기 어렵고, 나중에 블로그 글로 옮길 때도 정리가 번거로워진다.

그래서 폴더 노트를 기본 단위로 잡고, 첨부 파일 위치와 파일 탐색기 정렬 방식까지 같이 맞췄다. 이 글에서는 동기화 설정이 아니라, Obsidian 안에서 노트를 어떤 구조로 관리할지에만 집중한다.

1. 구성 방향

전체 방향은 단순하다.

노트는 폴더 노트 구조로 관리한다.
첨부 파일은 각 노트의 attachments 폴더에 둔다.
상위 노트의 링크 순서를 하위 노트 정렬 순서로 사용한다.
정렬 파일은 자동으로 갱신한다.

노트는 오래 쌓일수록 처음 정한 구조의 영향을 크게 받는다. 그래서 처음에는 조금 번거롭더라도 구조를 일관되게 가져가는 편이 낫다고 판단했다.

2. 폴더 노트 구조

노트는 가능한 한 아래 형태로 만든다.

1
2
3


페이지명/
├── 페이지명.md
└── attachments/

예를 들어 홈서버라는 주제가 있으면 홈서버.md 파일만 하나 두는 것이 아니라, 홈서버/홈서버.md 형태로 둔다. 이미지나 캡처 파일은 같은 폴더의 attachments 아래에 저장한다.

이렇게 하면 한 주제에 대한 본문과 첨부 파일을 한 단위로 다룰 수 있다. 나중에 글로 옮기거나, 다른 주제로 분리하거나, 오래된 자료를 정리할 때도 판단 기준이 명확해진다.

3. 사용하는 플러그인

현재 구조에서 핵심이 되는 플러그인은 아래와 같다.

플러그인	용도
Folder Notes	폴더와 같은 이름의 대표 노트를 사용
Templater	새 폴더 노트 생성 자동화
Custom File Explorer Sorting	`sortspec.md` 기준으로 파일 탐색기 정렬
Dataview	메타데이터 기반 목록이나 대시보드 작성
Importer	외부 자료를 Obsidian으로 가져올 때 사용

목차는 별도 플러그인을 추가하지 않고, Obsidian 기본 기능인 개요(Outline)를 먼저 사용하기로 했다. 데스크톱에서는 떠 있는 목차가 편할 수 있지만, 모바일에서는 화면을 가릴 가능성이 있어서 기본 기능으로 시작하는 편이 더 안정적이다.

4. 새 폴더 노트 생성

새 노트를 만들 때마다 폴더, 본문 파일, 첨부 파일 폴더를 직접 만드는 것은 번거롭다. 그래서 Templater로 새 폴더 노트 생성 템플릿을 만들어 사용한다.

동작 흐름은 아래와 같다.

새 노트 이름 입력
현재 위치에 같은 이름의 폴더 생성
폴더 안에 같은 이름의 .md 파일 생성
attachments 폴더 생성
현재 노트에 새 노트 wikilink 삽입

결과적으로 아래 구조가 자동으로 만들어진다.

1
2
3


입력한 이름/
├── 입력한 이름.md
└── attachments/

이 방식의 장점은 상위 노트에서 하위 노트 링크를 먼저 만들고, 그 링크 순서를 그대로 정렬 기준으로 사용할 수 있다는 점이다.

5. 상위 노트의 링크 순서를 정렬 기준으로 사용

Obsidian에서 파일 탐색기 순서를 직접 관리하다 보면, 실제 글의 흐름과 파일 목록의 순서가 어긋나는 경우가 많다.

그래서 상위 노트에 적은 wikilink 순서를 기준으로 하위 노트의 탐색기 순서를 맞추도록 했다.

예를 들어 상위 노트에 아래처럼 적으면,

1
2
3
4
5


[[첫 번째 글]]

[[두 번째 글]]

[[세 번째 글]]

하위 폴더의 sortspec.md도 같은 순서로 만들어진다.

1
2
3
4
5
6


---
sorting-spec: |
 첫 번째 글
 두 번째 글
 세 번째 글
---

이렇게 하면 문서 안에서 보는 목차 순서와 파일 탐색기에서 보는 순서가 같아진다.

6. sortspec.md 자동 갱신

Custom File Explorer Sorting은 sortspec.md를 기준으로 파일 탐색기 순서를 바꿔준다. 문제는 이 파일을 매번 직접 관리하기 어렵다는 점이다.

그래서 서버에서 작은 자동화 스크립트를 돌려 폴더 노트가 수정될 때마다 sortspec.md를 자동으로 갱신하도록 했다.

동작 방식은 아래와 같다.

일정 주기로 vault의 폴더 노트를 확인한다.
폴더 이름과 같은 이름의 .md 파일을 폴더 노트로 판단한다.
폴더 노트 안의 wikilink를 읽는다.
실제 존재하는 하위 노트나 폴더만 정렬 대상에 넣는다.
링크에 없는 하위 항목은 알파벳순으로 뒤에 붙인다.
정렬할 하위 항목이 없으면 빈 sortspec.md를 남기지 않는다.

정렬 파일은 아래 형식을 사용한다.

1
2
3
4
5


---
sorting-spec: |
 항목1
 항목2
---

sorting-spec: |만 있고 아래 항목이 비어 있으면 플러그인에서 파싱 문제가 생길 수 있다. 그래서 하위 항목이 없는 폴더에는 sortspec.md를 만들지 않는 쪽으로 정리했다.

7. 정리 기준

Obsidian에는 정리된 글뿐 아니라 임시 메모, 복사해온 자료, 나중에 볼 링크도 같이 들어온다. 다만 모든 자료를 오래 보관할 필요는 없다.

복사해온 자료나 오래된 도구에 묶인 자료가 현재 작업 흐름과 맞지 않으면 정리 대상이다. 특히 다시 볼 가능성이 낮고 직접 정리한 내용도 아니라면 따로 보관하기보다 삭제하는 편이 낫다.

반대로 직접 작업하면서 얻은 설정, 문제 해결 과정, 운영 기준은 최대한 설명형 글로 남긴다. 나중에 블로그 글로 옮길 수 있도록 처음부터 공개 가능한 문장 구조에 가깝게 작성하는 편이 좋다.

8. 정리

이번 설정의 핵심은 Obsidian을 단순히 파일을 저장하는 공간으로 두지 않고, 오래 쓸 수 있는 노트 구조로 맞추는 것이다.

폴더 노트로 주제 단위를 만들고, 상위 노트의 링크 순서를 정렬 기준으로 사용하고, 반복되는 정렬 파일 관리는 자동화했다.

아직 완성된 구조라기보다는 계속 다듬어가는 운영 방식에 가깝다. 그래도 폴더 구조, 첨부 파일 위치, 정렬 기준이 정해져 있으니 노트가 늘어나도 덜 무너지는 형태가 됐다.

Syncthing으로 Obsidian vault 동기화하기

Sun, 03 May 2026 09:00:00 +0900

Syncthing으로 홈서버 LXC ↔ Windows ↔ 모바일 vault 동기화

0. 구조

1
2
3
4
5


Windows (SyncTrayzor)
 ↕
mgt LXC (Syncthing, 허브) ← Claude Code가 직접 접근
 ↕
모바일 (Syncthing-Fork)

모든 기기가 mgt LXC를 허브로 동기화한다. LXC는 항상 켜져 있기 때문에 각 기기가 켜지는 순간 동기화된다.

1. LXC에 Syncthing 설치

Rocky Linux 9는 EPEL 저장소를 통해 설치한다.

1
2
3


dnf install -y epel-release
dnf install -y syncthing
systemctl enable --now syncthing@root

2. LXC Syncthing 웹 UI 접근

Syncthing 웹 UI는 기본적으로 localhost:8384에서만 열린다. SSH 포트 포워딩으로 로컬에서 접근한다.

1

ssh -L 8384:localhost:8384 mgt

브라우저에서 http://localhost:8384 접속

3. Windows에 SyncTrayzor 설치

SyncTrayzor는 Windows용 Syncthing 래퍼로, 트레이 아이콘으로 백그라운드 실행된다.

설치 후 동작 → 기기 아이디 보기 에서 Windows Device ID 확인

4. 기기 페어링

LXC 웹 UI에서 다른 기기 추가 클릭 → Windows Device ID 입력 → 저장

Windows SyncTrayzor에 수락 요청이 뜨면 수락한다.

5. 폴더 공유 설정

LXC 웹 UI에서 폴더 추가 클릭

일반 탭: 폴더 경로 입력 (/root/obsidian)
공유 탭: Windows 기기 체크

저장하면 Windows SyncTrayzor에 폴더 수락 요청이 뜬다. 수락 시 Windows vault 경로를 지정한다.

6. 모바일 연동

Android: Syncthing-Fork 설치
동일하게 Device ID 교환 후 페어링
폴더 공유 설정에서 모바일 기기 추가 체크
Obsidian 모바일에서 동기화된 폴더를 vault로 열기

Notion에서 Obsidian으로 넘어온 이유

Sat, 02 May 2026 09:00:00 +0900

Notion을 쓰다가 Obsidian으로 넘어온 이유

홈서버가 이미 있었기 때문에 가능한 구조

0. 배경

노션을 꽤 오래 써왔다. 메모, 자료 정리, 파일 첨부까지 하나의 앱에서 다 됐기 때문에 불편함이 없었다.

바꾸게 된 계기는 AI를 더 적극적으로 활용하고 싶어서였다. 내가 쌓아온 데이터에 AI가 언제든지 접근할 수 있었으면 했다.

1. Notion에서 AI 접근이 어려운 이유

Notion에 AI가 접근하려면 Notion API를 써야 한다.

페이지마다 API 호출이 따로 필요
Rate limit: 초당 3건
수백 페이지를 실시간으로 뒤지는 건 현실적으로 불가능

Notion MCP도 결국 Notion API 위에 얹는 것이라 근본적인 제약은 동일하다.

원하는 건 단순했다. AI가 내 데이터에 언제든지, 비용 없이, 즉시 접근할 수 있는 구조.

2. Obsidian으로 넘어온 이유

Obsidian의 vault는 그냥 로컬 폴더다. 안에 있는 건 전부 마크다운 파일이다.

AI 입장에서는:

파일 직접 읽기
전체 검색
API 없음, Rate limit 없음, 비용 없음

파일이 로컬에 있는 한 AI는 즉시, 제한 없이 접근할 수 있다.

부가적으로 Notion 무료 플랜의 파일 첨부 5MB 제한도 없어지고, 오프라인에서도 쓸 수 있다.

3. 홈서버가 있었기 때문에 가능했다

Obsidian vault가 로컬 파일이라는 건 장점이지만, 그러려면 파일이 항상 어딘가에 있어야 한다.

AI가 언제든지 접근하려면 파일이 항상 살아있어야 함
PC나 모바일은 꺼질 수 있음

홈서버에 mgt LXC가 이미 구축돼 있었다. 항상 켜져 있고, 내 네트워크 안에 있고, Claude Code가 직접 파일에 접근할 수 있다. 따로 뭔가를 더 구축할 필요 없이 vault를 여기 두면 됐다.

홈서버가 없었다면 이 구조를 생각하지 않았을 것 같다.

4. 구성한 구조

1
2
3
4
5
6
7


외부 PC / 모바일
 └─ Obsidian + Syncthing
 ↕ 동기화
mgt LXC (홈서버, 항상 켜짐)
 ├─ /root/obsidian (vault 폴더)
 ├─ Syncthing (동기화 허브)
 └─ Claude Code (vault 직접 접근)

Syncthing이 모든 기기와 mgt LXC를 동기화한다. PC나 모바일에서 메모를 쓰면 즉시 LXC에 반영되고, AI는 LXC의 파일을 직접 읽는다.

동기화 도구로 Syncthing을 선택한 이유는 단순하다.

무료, 오픈소스
E2E 암호화
홈서버가 허브 역할을 하기 때문에 외부 릴레이 서버 없이 직접 연결 가능
기기 추가는 Device ID 교환으로 간단히 확장

실제 Syncthing 설정 방법은 다음 글에서 다룬다.

Proxmox에 관리용 LXC 구성하기

Thu, 30 Apr 2026 09:00:00 +0900

홈서버 작업 공간 분리를 위한 관리용 LXC 구성

PVE는 하이퍼바이저만, 작업은 mgt LXC에서

0. 관리용 LXC를 따로 만드는 이유

PVE는 VM과 LXC를 관리하는 하이퍼바이저다.

Claude Code, git, kubectl 같은 도구를 PVE에 직접 설치해서 쓰는 것도 가능은 하지만, PVE는 하이퍼바이저 역할만 하도록 두는 게 맞다.

PVE는 모든 VM/LXC의 상위 계층이기 때문에, PVE가 오염되면 모든 서비스에 영향
작업 도구 설치, 패키지 업데이트 등으로 하이퍼바이저 환경이 오염될 가능성이 있음
LXC는 가볍고 빠르게 생성/삭제 가능하기 때문에 작업 환경으로 적합

따라서 mgt라는 이름의 관리용 LXC를 별도로 만들어서, 이 LXC를 외부에서 SSH 접근하는 Bastion 겸 작업 공간으로 사용한다.

1. PVE에서 LXC 생성

PVE 웹 콘솔 우측 상단 Create CT 버튼으로 생성

General 탭

CT ID: 103 (순서대로 부여)
Hostname: mgt
Unprivileged container: 체크 (보안상 권장)
Nesting: 체크 (Docker 등 컨테이너 사용 시 필요)
Password: 설정

Template 탭

Storage: local
Template: 원하는 OS 선택
- 여기서는 Rocky Linux 9 사용

나머지 Disks / CPU / Memory / Network / DNS 탭은 용도에 맞게 설정 후 생성

2. Cloudflare SSH Route 변경

기존에 PVE에 설치된 cloudflared가 SSH 터널을 localhost:22로 라우팅하고 있었다.

즉, 외부에서 SSH 접속 시 PVE로 직접 붙는 구조였는데, 이를 mgt LXC로 변경한다.

기존: localhost:22 → PVE 루트 쉘
변경: 192.168.100.10:22 → mgt LXC 루트 쉘

Cloudflare 대시보드 → Networks → Tunnels → 해당 터널 → Public Hostname → SSH Route 편집

URL을 localhost:22 → 192.168.100.10:22 로 변경

변경 후 외부에서 SSH 접속 시 mgt LXC로 바로 접속된다.

Cloudflare를 사용한 서버 SSH 접근

Mon, 20 Apr 2026 09:00:00 +0900

Cloudflare Tunnel을 사용해 SSH 접근하기 위한 설정

Cloudflare WARP를 사용해도 서버에 통신 가능하긴 하지만, 목적이 SSH라면 WARP는 좋은 방안이 되지 못한다.

WARP는 UDP 기반 VPN 서비스이기 때문에 통신이 계속 끊어지기 때문

SSH용 Routing + cloudflared를 사용해서 서버에 접속한다.

0. 사전준비

Cloudflare Connectors 설정
- https://joonlog.github.io/p/cloudflare-tunnel을-사용한-홈서버-promox-pve-콘솔-접근-설정/#1-cloudflared-설치-및-연동

1. Cloudflared Routes 설정

연동한 tunnel을 통해서 연결할 도메인 경로 및 라우팅 경로 설정
- Hostname: 보유 도메인 기입
- Type: SSH
- URL: localhost:22
여기까지 설정 완료 시 기입한 서브도메인으로 SSH 접근 가능

2. Cloudflare Access 설정

서브도메인에 대한 인증 설정

Routes에 설정한 도메인 입력

Self-hosted 설명에 나와 있듯이 Policy 생성
- PVE 접속 도메인 접근 시 Email 인증하도록 Policy 설정

설정한 Policy 할당

3. Cloudflared 설치

windows

1

winget install Cloudflare.cloudflared

Rocky 8.10
1

dnf install -y cloudflared

4. SSH 접근

Cloudflared 로그인
1

cloudflared access login <SSH 접근 도메인>
- 이메일 인증 요구하는 화면 출력됨

SSH 접근

이메일 인증 완료 후 SSH 접근

1

cloudflared access ssh --hostname <SSH 접근 도메인>

접근 성공!

SSH alias

ssh 명령어로 접근하기 위한 alias
Windows
- C:\Users`<계정명>`.ssh\config
Linux
- ~/.ssh/config

1
2
3
4


Host pve
 HostName <SSH 접근 도메인>
 User root
 ProxyCommand cloudflared access ssh --hostname %h

접근 성공!

Cloudflare WARP를 사용한 Tunnel 접근

Tue, 24 Mar 2026 09:00:00 +0900

Cloudflare용 UDP VPN

Cloudflare WARP를 사용하면 Tunnel 내부 네트워크로 직접 접근이 가능하다.

다만 WARP는 UDP 통신이기 때문에 연결이 간헐적으로 끊어질 수 있다.

사전 준비

Cloudflare Tunnel 활성화

Cloudflare WARP

Cloudflare에서 제공하는 클라이언트 기반 WireGuard VPN 에이전트
디바이스에서 발생하는 트래픽을 Cloudflare 네트워크로 전달하여 보안 정책을 적용하거나 내부 네트워크에 접근할 수 있게 한다

1
2
3
4


클라이언트
→ WARP Client
→ Cloudflare Edge
→ 인터넷

일반적인 WARP는 이렇지만, Zero Trust WARP 환경에서는 다음과 같이 동작한다.

1
2
3
4
5
6


클라이언트
→ WARP Client
→ Cloudflare Edge
→ Cloudflare Zero Trust 정책(보안 인증)
→ Cloudflare Tunnel
→ Private Network

따라서 Cloudflare Tunnel을 뚫어서 Zero Trust를 사전에 구성한 경우에는 WARP로 Tunnel 내부망에 접근이 가능하다.

1. Private Network Route 등록

WARP가 접근할 내부망 CIDR을 등록

1
2
3
4


Zero Trust
→ Networks
→ Routes
→ Add route

설정

이 설정을 통해 Cloudflare는 다음 경로를 인식

1
2
3
4


WARP Client
→ Cloudflare Edge
→ Tunnel Connector
→ 192.168.100.0/24

2. WARP 클라이언트 설치

WARP 클라이언트를 설치하고 Zero Trust에 연결되면 자동으로 device가 등록된다.

Zero Trust WARP 접근 시
- 팀 이름 입력 후 사전 설정했던 인증 절차에 따라 연결 완료

확인 경로

1
2
3


Zero Trust
→ Team & Resources
→ Devices

3. Device Profile 설정

WARP 트래픽 정책은 Device profile에서 관리된다.
Split Tunnels 설정
- 현재 목적이 외부 장치에서 홈서버인 PVE 하위에 있는 노드로의 직접 접근이기 때문에, 192.168.100.x/24로의 라우팅만 설정
- Include IPs and domains
  - Manage
    - Type: Address
    - Value: 192.168.100.0/24
      - 해당 대역으로의 트래픽 전송 시에만 WARP를 사용하도록 설정

5. 정상 동작 확인

설정 적용 후 WARP 클라이언트를 설치한 장치에서 확인
- cmd에서: route print
- 정상이라면 다음 경로가 생성
  1 2 3 4 5
  
  인터페이스 목록 Cloudflare WARP Interface IPv4 테이블 192.168.100.0 255.255.255.0
이후 내부 노드 통신 가능

정리

Cloudflare Tunnel만으로는 내부망 접근이 되지 않는다.

WARP를 사용하려면 다음 설정이 필요하다.

1
2
3
4


1. Private Network Route 등록
2. WARP Device 등록
3. Device Profile 정책 적용
4. Split Tunnel에 내부망 CIDR 추가

특히 Split Tunnel 설정이 맞지 않으면 WARP routing이 정상 동작하지 않으므로 반드시 확인해야 한다.

Promox 네트워크 설정 및 VM 생성

Mon, 23 Feb 2026 09:00:00 +0900

Promox 내부 VM을 위한 사설 네트워크 인터페이스 생성 필요

Promox 네트워크 설정

현재 랜선이 그대로 미니 PC에 연결되어 있어 pve의 네트워크 인터페이스는 공인 IP만 존재한다

따라서 Promox 내부 VM을 사설 IP로 관리하기 위한 네트워크 인터페이스가 필요하다

NI 생성
1

vim /etc/network/interfaces
auto: 부팅 시 NI 활성
address: 고정 IP 설정
- 이 IP가 하위 VM들의 Gateway 역할
post-up: 인터넷 연결
- 내부 VM에서 외부 네트워크로의 라우팅 허용
- 출발지가 192.168.100.0/24 대역인 트래픽이 vmbr0으로 나갈 때 vmbr0 IP로 출발지 IP를 SNAT

post-down: 트래픽이 vmbr1으로 내려갈때는 위 NAT 규칙 삭제

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


auto vmbr1
iface vmbr1 inet static
 address 192.168.100.1/24
 bridge_ports none
 bridge_stp off
 bridge_fd 0

 post-up echo 1 > /proc/sys/net/ipv4/ip_forward
 post-up iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o vmbr0 -j MASQUERADE
 post-down iptables -t nat -D POSTROUTING -s 192.168.100.0/24 -o vmbr0 -j MASQUERADE

신규 생성한 NI 기동

1
2


systemctl restart networking
ifup vmbr1

VM에서 인터넷 통신 필요 시 pve에서 nftables 활성화 필수
- 기본 설정에선 vmbr1에서 vmbr0으로의 FORWARD를 막고 있음

Promox에서 VM 생성

rocky 8.10 이미지 다운로드

1
2


cd /var/lib/vz/template/iso/
wget https://download.rockylinux.org/pub/rocky/8.10/isos/x86_64/Rocky-8.10-x86_64-minimal.iso

VM 생성
- 좌측 pve 우클릭 - Create VM
q35 설정
Bridge에서 위에서 만든 NI 할당

Promox VM 설정

Start at boot를 활성화 해야지 promox 부팅될 때 해당 VM도 부팅

VM NI 설정

사설 IP 수동 할당 및 게이트웨이, dns 설정

1
2
3
4


nmcli con mod enp6s18 ipv4.method manual ipv4.addresses 192.168.100.11/24 ipv4.gateway 192.168.100.1 ipv4.dns 8.8.8.8
nmcli con mod enp6s18 connection.autoconnect yes
nmcli con down enp6s18
nmcli con up enp6s18

ping 8.8.8.8 성공 시 설정 완료

Cloudflare Tunnel을 사용한 홈서버 Promox PVE 콘솔 접근 설정

Fri, 06 Feb 2026 09:00:00 +0900

목표

현재 외부에서 홈서버 Promox PVE 콘솔에 접근 시 공인 IP로 직접 접근하는 중
PVE 접속용 도메인 설정
외부에서 도메인 접근 시 Cloudflare 인증을 요구하도록 설정하고, 인증 성공 시에만 PVE 콘솔에 접근하도록 설정

0. 사전 준비

Cloudflare에 등록할 도메인 준비
도메인 네임서버를 Cloudflare로 설정
- Cloudflare 회원가입 및 로그인
- 로그인 시 나오는 네임서버 도메인 2개를 도메인 등록기관의 네임서버 설정에 등록
- 초록색 체크 표시 뜨면 OK!

1. Cloudflared 설치 및 연동

Networks - Connectors - Add a tunnel

Cloudflared 선택

tunnel 이름 기입

OS 확인 및 Cloudflared 설치

Promox는 Debian 리눅스 64bit
- cat /etc/os-release + uname -m 명령어로 확인 가능
root 사용자로 진행
- Promox는 sudo가 설치되어 있지 않음

1
2
3
4
5
6
7
8
9


# Add cloudflare gpg key
mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-public-v2.gpg | tee /usr/share/keyrings/cloudflare-public-v2.gpg >/dev/null

# Add this repo to your apt repositories
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-public-v2.gpg] https://pkg.cloudflare.com/cloudflared any main' | tee /etc/apt/sources.list.d/cloudflared.list

# install cloudflared
apt-get update && apt-get install cloudflared

apt-get update 시 enterprise.proxmox.com 패키지 Unauthorized 오류가 나는 경우

Promox의 기본 패키지는 유료 구독형이기 때문에 비활성화 필요

1
2
3
4


cd /etc/apt/sources.list.d

mv -v pve-enterprise.sources pve-enterprise.sources.disabled
mv -v ceph.sources ceph.sources.disabled

일반 패키지 리포 추가

1
2
3
4
5
6
7


cat > /etc/apt/sources.list.d/pve-no-subscription.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

하단의 토큰 값 유출되지 않도록 유의
- 서버가 시작될때마다 Tunnel이 자동으로 기동되게 할 경우
  1
  
  cloudflared service install <토큰>
- 현재 터미널에서만 Tunnel 연결할 경우
  1
  
  cloudflared tunnel run --token <토큰>

2. Cloudflare Routes 설정

연동한 tunnel을 통해서 연결할 도메인 경로 및 라우팅 경로 설정
- Hostname: 보유 도메인 기입
- Type: HTTPS
- URL: localhost:8006
Promox 서버에서 https://localhost:8006로 접근 시 TLS 해제 필요
여기까지 설정 완료 시 기입한 서브도메인으로 PVE 접근 가능

3. Cloudflare Access 설정

서브도메인에 대한 인증 설정

Self-hosted 설명에 나와 있듯이 Policy 먼저 생성
- PVE 접속 도메인 접근 시 Email 인증하도록 Policy 설정

설정한 Policy 할당

PVE 접속 도메인 접근 시 이메일 인증 요구하는 화면 출력 확인
설정 완료!

3. Promox 인바운드 접근 차단

Cloudflare Tunnel이 뚫렸기 때문에, 기존에 anyopen되어 있던 Promox 공인 IP에 대한 접근을 전부 차단
Zero-Inbound 설정
PVE 콘솔 → Datacenter → Firewall → Options → Firewall 활성화
설정 즉시 공인 IP를 통한 PVE 콘솔 차단 완료!

결과

홈서버로서의 취약한 보안 조치 완료
- 홈 공인IP 숨기기
- 관리자용 페이지 접근 시 이메일 인증 적용

홈서버 접근 용도로 Cloudflare Tunnel을 쓰는 이유

Thu, 05 Feb 2026 09:00:00 +0900

외부에서 홈서버에 안전하게 접근하기 위한 설정

홈서버를 디폴트 상태로 외부에서 접근하기 위해선 IP와 Port로 접근이 필요하다.

클라우드라면 Security Group / ACL 등등으로 제어가 쉽기 때문에 상관이 없지만, 홈서버는 집에서 사용하는 공유기 공인 IP를 외부에 오픈해야하기 때문에 보안적으로 위험하다.

기본적으로 홈 IP는 AnyOpen되어 있고, 외부에서 접근한다는 것 자체가 Wifi든 모바일이든 매번 접근하는 IP가 가변적이기 때문에 IP로 접근을 차단하는 것에도 무리가 있다.

특히 Proxmox 관리 콘솔(PVE)은 관리자 권한 탈취될 시 홈 네트워크 전체에 대한 통제권을 넘길 수 있기 때문에 매우 위험하다.

따라서 Cloudflare Tunnel로 공인 IP를 숨기고, Cloudflare Access로 인증된 사용자만 접근할 수 있게 하려고 한다.

1. Cloudflare Tunnel

IP와 포트를 공개하지 않고도 외부에서 서버로 접속할 수 있게 하는 서비스
외부에서 Cloudflare를 거쳐서 서버에 접속
기존 인바운드+포트 포워딩 기반 접근과 다른 아웃바운드 기반 리버스 프록시 연결

Cloudflare Tunnel을 쓰는 이유

홈서버는 가정용 공유기에 부여된 공인 IP로 접근해야 하기 때문에 보안에 취약
기업에서 쓰는 서버들의 경우 WAF, IPS, F/W 등 방어 솔루션이 많지만, 홈서버는 사실상 방어 수단이 전무
Cloudflare를 거치면서 레이턴시가 늘어나더라도, 홈서버는 보안이 최우선
따라서 Zero-Inbound를 유지하고도 운영이 가능한 Cloudflare Tunnel 사용

기존 포트포워딩 방식

포트포워딩은 외부에서 들어오는 Inbound 연결을 서버가 직접 받아들이는 구조
1

외부 클라이언트 → 공유기(포트포워딩) → 홈서버
- 이 방식에서는 서버가 외부에서 접근 가능한 상태가 되며, 열려 있는 포트는 스캔이나 공격의 대상이 될 수 있어서 보안적으로 매우 취약

Cloudflare Tunnel 방식

Cloudflare Tunnel은 서버가 먼저 Cloudflare로 Outbound 연결을 생성
1 2

[항상 유지되는 연결] 홈서버(cloudflared) → Cloudflare
- cloudflared 데몬은 Cloudflare Edge와 여러 개의 TLS 연결을 지속적으로 유지
- 이 시점에는 외부 요청이 없어도 연결은 계속 생존
- 즉, 요청이 올 때마다 연결을 여는 구조가 아니다
외부 사용자가 서비스에 접근하면 요청은 먼저 Cloudflare에 도달
1

외부 클라이언트 → Cloudflare
이 단계에서 Cloudflare는 아래 접근 제어를 수행
- Cloudflare Access 기반 인증 (로그인, OTP, SSO, 서비스 토큰 등)
- IP, 국가, 정책 기반 접근 제어
- 인증 실패 시 요청 차단
- 인증과 접근 제어는 홈서버와 분리된 상태에서 Cloudflare가 전담
인증 이후 실 연결
1

Cloudflare → 기존 Tunnel → 홈서버
- 인증을 통과한 요청만 이미 열려 있는 터널 연결을 통해 홈서버로 전달됨

2. Cloudflare Access

Cloudflare tunnel만 사용한다면, 최초 목적 중 공인 IP 숨기기만 가능하다.

PVE 콘솔에 대한 접근 자체를 막기 위해선 Cloudflare Access를 사용한 인증 절차 도입이 필요하다.

Cloudflare Access 도입 후의 구조

위 Cloudflare Tunnel의 2번째 단계에서 Cloudflare Access 추가

1

외부 클라이언트 → Cloudflare Access → Cloudflare

정리

Cloudflare Tunnel은 요청을 역방향으로 전달하는 Outbound 기반 리버스 프록시 구조
홈서버 입장에서는 외부 클라이언트와 직접 통신하지 않는다
Cloudflare와 유지 중인 Outbound 연결만 사용하며, 외부에서 서버로 들어오는 Inbound 포트는 존재하지 않는다
따라서 Zero-Inbound로 외부에서 서비스 접근이 가능
내가 외부에서 접근해야 하지만 공개적으로 오픈하면 안 될 경우 Cloudflare Access 사용
실제 작업 과정은 다음 글 확인

홈서버용 Mini PC에 Promox 설치하기

Wed, 04 Feb 2026 09:00:00 +0900

개발/인프라/K8S 연습용 홈서버로 Mini PC 구매

Mini PC에 Proxmox 설치

Mini PC 모델: Chatreey AN3P

1. Promox 이미지 준비

ISO 이미지로 설치 가능한 USB를 만들 때 사용
- https://rufus.ie/ko/

2. Mini PC 부팅

미니 PC 부팅하니 바이오스 화면 진입
가상화 기능을 써야 하니 관련 설정이 정상적인지 확인
- Advanced → CPU Configuration → SVM / Virtualization / AMD-V 관련 항목은 무조건 Enabled

USB를 통한 Promox 설치 시 막힐 수 있어서 Secure Boot 해제
- Boot → Boot Configuration → Secure Boot → Disabled

Boot → Boot Option 순서에서 Promox 설치 USB를 첫번째 순서로 조정

설정 저장 및 재기동

3. Promox 설정

부팅 후 Promox 기본 설정대로 설치 진행
인터페이스는 일단 DHCP로 설정
모든 설정 후 재부팅하면 설치 완료

4. Promox PVE 접근 확인

재부팅하면 Promox CLI로 부팅됨
- ID는 root, PWD는 설정한 비밀번호로 로그인
CLI에 출력되는 공인IP:Port로 외부에서 PVE(Promox 관리 콘솔) 접근 가능
- PVE 콘솔 접근 정보는 계정 접근 정보와 동일
접근 성공!