다음 stunnel 구성 파일을 사용하십시오.
chroot = /var/run/stunnel
setuid = nobody
setgid = nobody
debug = 7
output = /var/log/stunnel/stunnel.log
pid = /stunnel.pid
cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.pem
client = yes
[https]
accept = 127.0.0.1:10051
connect = 10.0.10.116:443
"sudo stunnel"을 입력하면 다음과 같은 결과가 나타납니다. (포그라운드 명령을 사용하고 로그를 터미널로 보내면 프로필이 작동합니다)
[chuck@scorch ~]$ sudo stunnel
Clients allowed=500
stunnel 4.56 on x86_64-redhat-linux-gnu platform
Compiled/running with OpenSSL 1.0.1e-fips 11 Feb 2013
Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP
Reading configuration from file /etc/stunnel/stunnel.conf
FIPS mode is enabled
Compression not enabled
PRNG seeded successfully
Initializing service [https]
Insecure file permissions on /etc/stunnel/stunnel.pem
Certificate: /etc/stunnel/stunnel.pem
Certificate loaded
Key file: /etc/stunnel/stunnel.pem
Private key loaded
SSL options set: 0x01000004
Configuration successful
Service [https] (FD=12) bound to 127.0.0.1:10051
Cannot open log file: /var/log/stunnel/stunnel.log
Closing service [https]
Service [https] closed (FD=12)
Sessions cached before flush: 0
Sessions cached after flush: 0
Service [https] closed
str_stats: 16 block(s), 1147 data byte(s), 928 control byte(s)
"chroot 명령"으로 인해 일종의 권한 문제인 줄 알았는데, stunnel 로그 디렉터리의 권한을 "nobody:nobody"로 설정해 보았지만 작동하지 않았습니다. 그래서 나는 무슨 일이 일어나고 있는지 정확하게 이해하지 못했습니다. "chroot" 및 "pid" 줄을 유지하면 작동합니까? 나는 이것이 내가 보지 못하는 명백한 것이라고 확신합니다. 어떤 아이디어가 있습니까?
Centos 7에서 실행 중입니다.
답변1
감사해요트리거그리고선행은 이루기가 어렵다나는 /var/run/stunnel
로그 파일을 디렉토리에 넣어서 이 작업을 수행하는 방법을 찾았습니다. 그러다가 재부팅 후 디렉터리를 다시 생성한 sudo mkdir /var/run/stunnel
후 권한을 설정했는데, sudo chown nobody:nobody /var/run/stunnel
적어도 실행 중에 재부팅을 하면 없어졌지만, 테스트 중이나 부팅 후에는 백그라운드에서 로그를 볼 수 있었습니다. chroot
로그 파일 문제를 일으키는 것과 같은 방식으로 키와 인증서 위치에 영향을 주지 않는 이유를 아직도 이해하지 못합니까 ?
답변2
로그 파일에 대한 상대 경로를 사용하여 문제를 해결할 수 있었습니다. 예를 들면 다음과 같습니다.
출력 = stunnel.log
chroot = /var/run/stunnel