UFW 앱 프로필이 없나요? 그것은 서비스가 아니라 포트를 설명합니다
UFW 앱 프로필은 포트와 프로토콜의 이름 붙은 목록이며 서비스가 아닙니다. app info를 읽고 실제 리스너와 맞춰 보며 다시 불러오기 전에 돌아갈 길을 확보하세요.
UFW는 OpenSSH와 일치하는 프로필을 찾을 수 없다고 말하고, 원인 탐색은 곧장 SSH 서버로 향합니다. 그것은 잘못된 방향입니다: 이 메시지는 이름 붙은 방화벽 정의에 관한 것이며 sshd가 설치되었는지, 실행 중인지, 수신 중인지에 대해서는 아무 말도 하지 않습니다. UFW 앱 프로필은 라벨이 붙은 포트와 프로토콜의 목록입니다. 정의를 읽는 데는 명령 하나면 충분하고 보통 거기서 조사가 끝납니다.
1단계: UFW가 실제로 아는 이름을 나열합니다
하나를 허용해 달라고 하기 전에 방화벽에 어떤 이름이 있는지 물어보세요. 목록은 이 머신에 설치된 프로필에서 오므로 없는 이름은 이 시스템에 관한 사실이고, 보호하려던 소프트웨어에 관한 사실이 아닙니다. 이름이 있다면 오류는 오타나 셸 기록에 남은 낡은 별칭에서 비롯된 것입니다.
ufw app list
ufw app info OpenSSH
기본 설치에서 목록은 짧고 이름은 패키지 이름이 아닙니다. openssh-server 패키지가 설치되어 있어도 OpenSSH라는 프로필이 없을 수 있고 그 반대도 가능합니다. 목록이 출력하는 정확한 이름을 사용하세요: 철자가 비슷한 VPN 프로필 이름이나 데스크톱 실행기는 UFW 앱 프로필이 아닙니다. 원하는 이름이 없다면 그것이 발견 사항이고, 다음 단계는 무엇이 그것을 제공해야 하는지 보는 것입니다.
2단계: 라벨이 아니라 정의를 읽습니다
프로필은 /etc/ufw/applications.d 아래의 INI 형식 파일이며 이름, 제목, 설명, 포트 필드를 가집니다. 포트 필드는 여러 포트와 전송을 나열할 수 있으므로 라벨은 정의보다 적게 알려 줍니다. UFW 설명서가 이 필드들과 애플리케이션 업데이트 작업을 문서화합니다. 이름이 하나의 익숙한 포트를 뜻한다고 가정하지 말고 파일을 읽으세요.
cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH
22/tcp를 담은 정의는 TCP 포트 22를 설명하며 그 이상은 아닙니다. 이 머신의 데몬이 거기서 수신한다는 증거가 되지 못하고, 나중에 추가한 두 번째 포트도 포괄하지 않습니다. 데몬이 다른 곳에서 실행된다면 이름이 제품과 맞더라도 그 프로필은 잘못된 허용입니다. 둘 중 하나를 허용하기 전에 리스너와 정의를 비교하세요.
ss -ltnp 'sport = :22'
정의와 리스너가 어긋나면 멈추세요. 아무도 수신하지 않는 포트를 명시한 프로필을 허용하면 진전처럼 보이지만 아무것도 보호하지 않는 규칙이 생깁니다.
3단계: 프로필과 실행 중인 서비스를 분리합니다
이름 붙은 프로필을 허용해도 서비스가 설치, 시작, 구성되지는 않으며 실행 중인 서비스가 도달 가능하려고 패키지된 프로필이 필요한 것도 아닙니다. 이는 서로 다른 도구가 소유한 별개의 결정입니다: 패키지 관리자, 서비스 관리자, 방화벽입니다. 이를 하나로 취급하는 것이 사람들이 상징적인 이름을 띄우려고 원치 않는 서버를 설치하는 방식입니다.
VPN 서버에서는 바깥 리스너를 허용한 뒤에도 분리가 이어집니다. 암호화 전송 포트에 대한 허용은 커널 포워딩을 켜지 않고, NAT 규칙을 추가하지 않으며 터널 사용자에게 LAN 접근을 주지 않습니다. 그 각각은 자체 검토를 지닌 별개의 정책입니다. VPN 제품 이름을 딴 프로필은 나열한 포트만을 설명하며 서버 구성의 나머지는 여전히 당신이 써야 합니다.
프로필이 없고 하나가 필요하다면 검토된 명시적 포트 규칙이나 applications.d 아래의 로컬 프로필 둘 다 정당합니다. 원치 않는 패키지를 설치하는 것은 그렇지 않습니다.
4단계: 방화벽을 다시 불러오기 전에 돌아갈 길을 확보합니다
규칙을 바꾸기 전에 머신으로 들어가는 두 번째 경로가 있는지 확인하세요: 콘솔, 대역 밖 주소, 예정된 롤백입니다. 다음으로 규칙 집합과 기본 정책을 읽으세요: SSH 규칙 없는 기본 거부는 시험 중 스스로를 잠그는 고전적인 방법이기 때문입니다. 한 번에 규칙 하나만 바꾸고 UFW가 출력하는 확인을 읽으세요. 저장된 규칙, 활성 규칙, 도달 가능한 서비스는 세 가지 다른 관찰입니다.
ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH
변경 후 허용된 연결과 여전히 거부되어야 하는 경로 하나를 시험하세요. 거부 시험은 허용 시험만큼 중요합니다: 의도보다 넓은 규칙은 첫 시험을 통과하고 두 번째에서 실패하기 때문입니다. 프로필 이름, 그것이 담았던 포트, 검증한 리스너를 기록하세요.
체크리스트는 이름이 있거나 의도적으로 대체되었고, 정의가 실제 리스너와 맞고, 서비스가 별도로 관리되며, 복구 경로를 손에 쥔 채 허용 경로와 거부 경로를 모두 시험했을 때 끝납니다. 목록에 이름이 있는 것은 그중 어느 것도 아닙니다.