Stunnel е SSL прокси (TCP тунелен мениджър), които се състои от две части - клиент и сървър. Страницата на проекта е на адрес:

https://www.stunnel.org

Най-важните характеристики на stunnel са:

• комуникацията между клиента и сървъра е само и единствено TCP-базирана (UDP не се поддържа все още)

• stunnel използва библиотеките на OpenSSL:

  Следодвателно SSL протокола (като версии, използвани шифри и др) се реализира на базата на тези библиотеки, с всички произтичащи от това предимства и недостатъци.

• един stunnel сървърски процес може да поддържа множество TCP тунели

Всички модерни дистрибуции поддържат пакет с дистрибуцията на проекта Stunnel. Този документ се фокусира върху инсталирането и конфигурирането на Stunnel под CentOS 7 и Scientific Linux 7 и интегрирането му с PKI инфраструктурата на проекта УНИТе.

Процесът на stunnel може да бъде конфигуриран да функционира като сървър или клиент:

• сървър:

  Вашият клиентски софтуер се свързва към порта, на който слуша stunnel процеса, използвайки SSL, а от своя страна stunnel процеса се свързва към отдалечен ресурс, от името на вашия клиентски софтуер, без да установява SSL комуникация, от/до ресурса.

• клиент:

  Вашият клиентски софтуер се свързва към порта, на който слуша stunnel процеса, без да използва SSL, а от своя страна stunnel процеса се свързва към отдалечен ресурс, от името на вашия клиентски софтуер, установявайки SSL комуникация, от/до ресурса.

Целта на използването на Stunnel-базирано реверсивно прокси в инфраструктурата на УНИТе е да се предостави, когато е необходимо, достъп до TCP базирани ресурси (като файлови сървъри, iSCSI инициатори и др), на базата на валиден X.509 сертификат, без да се модифицира протокола на услугата, който е обвит в изградения SSL тунел.

Стандартния пакет stunnel в CentOS 7 и Scientific Linux 7 не поддържа протокола TLS v1.3. Причината е, че версията на дистрибутивния пакет openssl не позволява това. Поради тази причина, е разработен специален пакет, който да може да адаптира stunnel пакета към последната версия на OpenSSL, без да се налага замяната на пакета openssl в дистрибуцията.

Използвайте актуализирана и поддържана версия на CentOS 7 или Scientific Linux 7!

Пакетът stunnel5 е специално изработен по начин, по който да поддържа интеграция със systemd и едновременното използване на много различни конфигурации (едновремено стартирани процеси на stunnel) в една състема. Освен това, пакетът не интерферира с никой от пакетите (включително пакетите stunnel и openssl), който са инсталирани от дистрибутивното хранилище на CentOS 7 или Scientific Linux 7. В последната версия на този пакет, е включена поддръжката на протокола TLSv1.3.

Инсталирайте пакета за поддръжка на пакетното хранилище на СУ PKI и след това инсталирайте пакета stunnel5:

$ sudo yum install https://pki.uni-sofia.bg/yum/el7/x86_64/Packages/pkisu-release-1.0.0-1.el7.noarch.rpm
$ sudo yum install stunnel5

В случай, че вече имате инсталиран пакета stunnel5 от пакетното хранилище посочено по-горе, той ще бъде актуализиран автоматично, ако сте настроили yum-cron за целта.

Ако искате да инсталирате и последната версия на OpenSSL (спрямо която е изграден пакета stunnel5), изпълнете:

$ sudo yum install openssl-bundle

Съдържанието на пакета ще бъде поставено в директория /opt/openssl-bundle. По този начин, ако искате да използвате изпълнимия файл openssl от тази специално приготвена дистрибуция, трябва да изпълните:

$ /opt/openssl-bundle/bin/openssl

Стартовата конфигурация на stunnel5, която е дадена по-долу, прави възможно stunnel5 да бъде стартиран като сървър, който проксира SSL трафика (използвайки транспорт по протокол TLS v1.2 или TLSv1.3), идващ на порт 3260/tcp към друга отдалчена системата (без да се използва SSL транспорт), прозрачно за клиентския софтуер:

• използване на протокол TLSv1.2:

  options = CIPHER_SERVER_PREFERENCE
  sslVersion = TLSv1.2
  ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
  curve = secp384r1
  
  CApath = /etc/stunnel5/CA
  CRLpath = /etc/stunnel5/CRL
  verify = 2
  
  cert = /etc/pki/tls/certs/stunnel.crt
  key = /etc/pki/tls/private/stunnel.key
  
  syslog = no
  output = /var/log/stunnel5/iscsi.log
  
  pid = /var/run/stunnel5/iscsi.pid
  
  setuid = stunnel
  setgid = stunnel
  
  [iscsi]
  client = no
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  accept = 62.44.109.26:3260
  accept = 2001:67c:20d0:aafa::26:3260
  local = fc00:67c:20d0:bafa::40:3260
  connect = fc00:67c:20d0:bafa::41:3260
  sessionCachetimeout = 600
  sessionCacheSize = 200
  TIMEOUTidle = 600

• използване на протокол TLSv1.3 (с връщане към TLSv1.2, ако TLSv1.3 не се поддържа от клиента):

  sslVersionMax = TLSv1.3
  sslVersionMin = TLSv1.2
  options = CIPHER_SERVER_PREFERENCE
  ciphers = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
  curve   = secp384r1
  
  CApath = /etc/stunnel5/CA
  CRLpath = /etc/stunnel5/CRL
  verify = 2
  
  cert = /etc/pki/tls/certs/stunnel.crt
  key = /etc/pki/tls/private/stunnel.key
  
  syslog = no
  output = /var/log/stunnel5/iscsi.log
  
  pid = /var/run/stunnel5/iscsi.pid
  
  setuid = stunnel
  setgid = stunnel
  
  [iscsi]
  client = no
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  accept = 62.44.109.26:3260
  accept = 2001:67c:20d0:aafa::26:3260
  local = fc00:67c:20d0:bafa::40:3260
  connect = fc00:67c:20d0:bafa::41:3260
  sessionCachetimeout = 600
  sessionCacheSize = 200
  TIMEOUTidle = 600

Ето и описание на декларациите, които са използвани в конфигурацията по-горе:

• options = CIPHER_SERVER_PREFERENCE

  С тази опция правите така, че при договорянето на SSL алгоритмите и параметрите, тези предлагани от сървъра да са с предимство пред тези, предлагани от клиента. Това е важно за предотвратяване на атаки, при които атакуващия може нарочно да накара сървъра да приеме от клиента предложения за шифри, които са слаби и взломяеми.

• sslVersion = TLSv1.2

  Използвайте (когато това е възможно) само протокол TLS 1.2 или по-висока версия (която се очаква скоро да се появи в библиотеките на OpenSSL).

• sslVersionMin = TLSv1.2

  Минимална версия на TLS протокола. В примерите по-горе, това е версия 1.2.

• sslVersionMax = TLSv1.3

  Максимална версия на TLS протокола. В примерите по-горе, това е версия 1.3.

• ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256

  Тази деклрация задава кой набор шифри сървъра да оферира и договаря с клиента. Посочените шифри са "златното сечение" за TLSv1.2. Най-важната част от тях е избрания алгоритъм за обмен на сесиен ключ, който използва елиптични криви (избран е ECDHE, виж също декларацията curve по-долу). Препоръчително е да използвате елиптични криви за обмен на ключ, ако клиентския софтуер може да работи с тях. Реално, към момента на написването на тази документация, над 90% от използвания клиентски софтуер, в който има SSL интеграция, поддържа работа с елиптични криви.

  За да проверите какви шифри за TLSv1.2 са допустими в stunnel5 конфигурацията, изпълнете:

  $ /opt/openssl-bundle/bin/openssl ciphers -tls1_2

• ciphers = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256

  Тази деклрация задава кой набор шифри сървъра да оферира и договаря с клиента, при използване на TLSv1.2 и TLSv1.3. Посочените шифри са "златното сечение" за TLSv1.2 и TLSv1.3. Най-важната част от тях е избрания алгоритъм за обмен на сесиен ключ, който използва елиптични криви за TLSv1.2 (избран е ECDHE, виж също декларацията curve по-долу). Не използвайте Diffie-Hellman алгоритъм. Реално, към момента на написването на тази документация, над 90% от използвания клиентски софтуер, в който има SSL интеграция, поддържа работа с елиптични криви.

  За да проверите какви шифри за TLSv1.3 са допустими в stunnel5 конфигурацията, изпълнете:

  $ /opt/openssl-bundle/bin/openssl ciphers -tls1_3

• curve = secp384r1

  Тази деклрация задава коя елиптична крива да се използва при обмен на сесиен ключ за използване в ECDHE. Не използвайте 521-битови криви, поне до края на живота на дистрибуцията. Някои SSL клинти не поддържат обмен на ключ чрез подобни криви.

• CApath = /etc/stunnel5/CA

  В директория /etc/stunnel5/CA трябва да поставите файловете, които съдържат сертификатите, на база на които ще се валидират сертификатите на клиентите. След това трябва да създадете symlink обекти към тези файлове така, че името на обекта да е хешираната стойност на "Subject" полето в сертификата:

  $ sudo su wget https://pki.uni-sofia.bg/crt/SU_ECC_Root_CA.crt -O /etc/stunnel5/CA/SU_ECC_Root_CA.crt
  $ sudo su wget https://pki.uni-sofia.bg/crt/UNITe_ECC_CA.crt -O /etc/stunnel5/CA/UNITe_ECC_CA.crt
  $ sudo su cd /etc/stunnel5/CA && ln -s SU_ECC_Root_CA.crt `openssl x509 -hash -noout -in SU_ECC_Root_CA.crt`.0
  $ sudo su cd /etc/stunnel5/CA && ln -s UNITe_ECC_CA.crt `openssl x509 -hash -noout -in UNITe_ECC_CA.crt`.0

• CRLpath = /etc/stunnel5/CRL

  В директория /etc/stunnel5/CRL трябва да поставите файловете, които съдържат списъците с отменени сертификати (CRL), на база на които ще се валидира моментната валидност на сертификатите на клиентите. След като ги поставите там, трябва да създадете symlink обекти, на базата на които stunnel процеса да може да търси файл по хешираната стойност на "Subject" полето в сертификата на издадетеля:

  $ sudo su wget https://pki.uni-sofia.bg/crl/SU_ECC_Root_CA.crl -O /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin
  $ sudo su wget https://pki.uni-sofia.bg/crt/UNITe_ECC_CA.crl -O /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin
  $ sudo openssl crl -inform DER -in /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin -outform PEM -out /etc/stunnel5/CRL/SU_ECC_Root_CA.crl
  $ sudo openssl crl -inform DER -in /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin -outform PEM -out /etc/stunnel5/CRL/UNITe_ECC_CA.crl
  $ sudo su cd /etc/stunnel5/CRL && ln -s SU_ECC_Root_CA.crl `openssl crl -hash -noout -in SU_ECC_Root_CA.crl`.r0
  $ sudo su cd /etc/stunnel5/CRL && ln -s UNITe_ECC_CA.crl `openssl crl -hash -noout -in UNITe_ECC_CA.crl`.r0
  $ sudo rm -f /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin
  $ sudo rm -f /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin

• verify = 2

  Ако в деклрацията verify е зададено числото 2, това означава, че сървърския stunnel процес ще провери валидността на клиентския сертификат спрямо сертификатите на издателите в директория /etc/stunnel5/CA.

• cert = /etc/pki/tls/certs/stunnel.crt

  /etc/pki/tls/certs/stunnel.crt е файла, който съдържа сървърския X.509 сертификат и сертификатната верига (ако такава има), като всеки сертификат е представен в този файл като PEM блок.

  ВНИМАНИЕ! В този файл първи е сертификата на сървъра.

• key = /etc/pki/tls/private/stunnel.key

  /etc/pki/tls/private/stunnel.key е файла, който съдържа частния ключ към сървърския X.509 сертификат, в PEM формат. Направете така, че да не бъде читаем от всички потребители на системата, но да бъде читаем от потребителя, с чиито права се изпълнява stunnel сървърския процес (ако е инсталиран пакета от хранилището, посочено по-горе, този потребител ще е stunnel):

  $ sudo chmod 600 /etc/pki/tls/private/stunnel.key
  $ sudo chown stunnel:stunnel /etc/pki/tls/private/stunnel.key

• syslog = no

  Тази деклрация прави така, че сървърския процес на stunnel да не описва събитията в syslog (т.е. да не се използват дефинициите в /etc/rsyslog.conf).

• output = /var/log/stunnel5/iscsi.log

  /var/log/stunnel5/iscsi.log е файла, в който се описват събитията, свързани с комуникацията от и до сървърския процес на stunnel.

• pid = /var/run/stunnel5/iscsi.pid

  С тази декларация се задава файла, в който се поставя PID номера (Process ID) на сървърския процес на stunnel, след успешното стартиране на този процес.

• setuid = stunnel

  Тази деклрация задава името на потребителя, с чиито права ще се изпълнява сървърския процес на stunnel.

• setgid = stunnel

  Тази деклрация задава името на групата, с чиито права ще се изпълнява сървърския процес на stunnel.

• деклрация на ресурс

  Декларацията на ресурс, дадена в примера по-горе:

  [iscsi]
  client = no
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  accept = 62.44.109.26:3260
  accept = 2001:67c:20d0:aafa::26:3260
  local = fc00:67c:20d0:bafa::40:3260
  connect = fc00:67c:20d0:bafa::41:3260
  sessionCachetimeout = 600
  sessionCacheSize = 200
  TIMEOUTidle = 600

  прави така, че процеса на stunnel да работи като сървър (client = no) приемайки заявките, идващи до порт 3260/tcp на 62.44.109.26 и 2001:67c:20d0:aafa::26 (тези два IP адреса, указани с декларацията accept трябва да са конфигурирани локално в системата, на някой от мрежовите интерфейси), установявайки SSL сесия с вашия клиентски софтуер и след като тя бъде установена, проксирайки комуникацията между вашия клиент и ресурса, който е достъпен на порт 3260/tcp на адрес fc00:67c:20d0:bafa::41. Т.е. свързвайки се с приложението, което слуша на порт 3260/tcp на 62.44.109.26 и/или 2001:67c:20d0:aafa::26, вие реално се свързвате с приложението, което слуша на порт 3260/tcp на 2001:67c:20d0:bafa::41. Това, което трябва да имате предвид е, че приложението, което слуша на порт 3260/tcp на fc00:67c:20d0:bafa::41 ще вижда вашите заявки идващи не от вашия IP адрес, а от този, който е посочен чрез декларацията local (това е fc00:67c:20d0:bafa::40, той също трябва да е конфигуран локално в системата, в която работи stunnel). Допълнително са добавени декларации за регулиране на ресурсите за всяка сесия sessionCachetimeout, sessionCacheSize, TIMEOUTidle. Стойностите в тези деклрациите трябва да бъдат настроени спрямо потреблението на ресурси и резерва им в системата.

Тази конфигурация трябва да запазите във файл, който да се намира в директория /etc/stunnel5/conf.d. Разширението на файла трябва да е *.conf.

Стартовата конфигурация на stunnel5, която е дадена по-долу, прави възможно stunnel5 да бъде стартиран като локален не-SSL клиент, който проксира трафика, идващ на порт 3260/tcp към друга отдалчена системата, използвайки за този транспорт протокол TLS v1.2 или v1.3, прозрачно за клиентския софтуер (клиентския софтуер не е нужно да има SSL функционалност):

• използване на протокол TLSv1.2:

  sslVersion = TLSv1.2
  ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
  
  CApath = /etc/stunnel5/CA
  CRLpath = /etc/stunnel5/CRL
  verify = 2
  
  cert = /etc/pki/tls/certs/client.crt
  key = /etc/pki/tls/private/client.key
  
  syslog = no
  output = /var/log/stunnel5/iscsi-client.log
  
  pid = /var/run/stunnel5/iscsi-client.pid
  
  setuid = stunnel
  setgid = stunnel
  
  [iscsi-client]
  client = yes
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  accept = 127.0.0.1:3260
  accept = ::1:3260
  retry = yes
  checkHost = iscsi.services.unite.uni-sofia.bg
  connect = iscsi.services.unite.uni-sofia.bg:3260

• използване на протокол TLSv1.3 (с връщане към TLSv1.2, ако TLSv1.3 не се поддържа от клиента):

  sslVersionMax = TLSv1.3
  sslVersionMin = TLSv1.2
  ciphers = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
  
  CApath = /etc/stunnel5/CA
  CRLpath = /etc/stunnel5/CRL
  verify = 2
  
  cert = /etc/pki/tls/certs/client.crt
  key = /etc/pki/tls/private/client.key
  
  syslog = no
  output = /var/log/stunnel5/iscsi-client.log
  
  pid = /var/run/stunnel5/iscsi-client.pid
  
  setuid = stunnel
  setgid = stunnel
  
  
  [iscsi-client]
  client = yes
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  accept = 127.0.0.1:3260
  accept = ::1:3260
  retry = yes
  checkHost = iscsi.services.unite.uni-sofia.bg
  connect = iscsi.services.unite.uni-sofia.bg:3260

Повечето от конфигурационните декларации са описани в секцията, в която е описана конфигурацията на сървъра (виж по-горе). По-долу са коментирани само тези от тях, който са специфични за клиента:

• cert = /etc/pki/tls/certs/client.crt

  /etc/pki/tls/certs/client.crt е файла, който съдържа клиентския X.509 сертификат (ако такъв се налага да бъде използван) и сертификатната верига (ако такава има), като всеки сертификат е представен в този файл като PEM блок.

  ВНИМАНИЕ! В този файл първи е сертификата на клиента.

• key = /etc/pki/tls/private/client.key

  /etc/pki/tls/private/client.key е файла, който съдържа частния ключ към клиентския X.509 сертификат, в PEM формат (ако използването на такъв сертификат се налага). Направете така, че да не бъде читаем от всички потребители на системата, но да бъде чутаем от потребителя, с чиито права се изпълнява stunnel сървърския процес (ако е инсталиран пакета от хранилището, посочено по-горе, този потребител ще е stunnel):

  $ sudo chmod 600 /etc/pki/tls/private/client.key
  $ sudo chown stunnel:stunnel /etc/pki/tls/private/client.key

• output = /var/log/stunnel5/iscsi-client.log

  /var/log/stunnel5/iscsi.log е файла, в който се описват събитията, свързани с комуникацията от и до клиентския процес на stunnel.

• pid = /var/run/stunnel5/iscsi-client.pid

  С тази декларация се задава файла, в който се поставя PID номера (Process ID) на клиентския процес на stunnel, след успешното стартиране на този процес.

• деклрация на ресурс

  Декларацията на ресурс, дадена в примера по-горе:

  [iscsi-client]
  client = yes
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  socket = l:TCP_KEEPIDLE=15
  socket = l:TCP_KEEPINTVL=5
  socket = l:TCP_KEEPCNT=5
  accept = 127.0.0.1:3260
  accept = ::1:3260
  retry = yes
  checkHost = iscsi.services.unite.uni-sofia.bg
  connect = iscsi.services.unite.uni-sofia.bg:3260

  прави така, че процеса stunnel5 да приема заявките, идващи до порт 3260/tcp на локалния хост (127.0.0.1 и ::1 са съответно IPv4 и IPv6 адресите на локалния хост, указани с декларацията accept, които са конфигурирани на мрежовия интерфейс lo) и да проксира комуникацията към ресурса, който е достъпен на порт 3260/tcp на iscsi.services.unite.uni-sofia.bg. Т.е. свързвайки се с приложението, което слуша на порт 3260/tcp на локалния хост (без да използвате SSL за тази връзка), вие реално се свързвате в SSL тунел (протокол TLS v1.2) към приложението, което слуша на iscsi.services.unite.uni-sofia.bg. Допълнително е добвена деклрация retry, чиято цел е да възстановява SSL тунела, ако поради липса на комуникация TCP сесията, на която той е базиран, се разпадне. Установяването на това дали сесията се е разпаднал, става на база на деклрациите за socket. Също така, stunnel в ролята си на SSL клиент, проверява и валидността на X.509 сертификата на iscsi.services.unite.uni-sofia.bg, относно това дали сървърския X.509 сертификата, който iscsi.services.unite.uni-sofia.bg връща, е наистина издаден за да валидира името на хост "iscsi.services.unite.uni-sofia.bg".

Тази конфигурация трябва да запазите във файл, който да се намира в директория /etc/stunnel5/conf.d. Разширението на файла трябва да е *.conf.

Стартовата конфигурация на stunnel, която е дадена по-долу, прави възможно stunnel да бъде стартиран като локален не-SSL клиент, който проксира трафика, идващ на порт 3260/tcp към друга отдалчена системата, използвайки за този транспорт протокол TLS v1.2 или TLS v1.3, прозрачно за клиентския софтуер (клиентския софтуер не е нужно да има SSL функционалност), без да се налага използването на systemd и без да се налага потребителя, с чиито права се изпълняват процесите на stunnel, да бъде stunnel. Stunnel с тази конфигурация може да бъде стартиран от всеки локален потребител:

• използване на протокол TLSv1.2:

  sslVersion = TLSv1.2
  ciphers = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
  
  CApath = /home/username/stunnel5/CA
  CRLpath = /home/username/stunnel5/CRL
  verify = 2
  
  cert = /home/username/stunnel5/tls/certs/client.crt
  key = /home/username/stunnel5/tls/private/client.key
  
  syslog = no
  output = /home/username/stunnel5/log/iscsi-client.log
  
  pid = /home/username/stunnel5/run/iscsi-client.pid
  
  [iscsi-client]
  client = yes
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  accept = 127.0.0.1:3260
  accept = ::1:3260
  retry = yes
  checkHost = iscsi.services.unite.uni-sofia.bg
  connect = iscsi.services.unite.uni-sofia.bg:3260

• използване на протокол TLSv1.3 (с връщане към TLSv1.2, ако TLSv1.3 не се поддържа от клиента):

  sslVersionMax = TLSv1.3
  sslVersionMin = TLSv1.2
  ciphers = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
  
  CApath = /home/username/stunnel5/CA
  CRLpath = /home/username/stunnel5/CRL
  verify = 2
  
  cert = /home/username/stunnel5/tls/certs/client.crt
  key = /home/username/stunnel5/tls/private/client.key
  
  syslog = no
  output = /home/username/stunnel5/log/iscsi-client.log
  
  pid = /home/username/stunnel5/run/iscsi-client.pid
  
  [iscsi-client]
  client = yes
  socket = l:TCP_NODELAY=1
  socket = r:TCP_NODELAY=1
  accept = 127.0.0.1:3260
  accept = ::1:3260
  retry = yes
  checkHost = iscsi.services.unite.uni-sofia.bg
  connect = iscsi.services.unite.uni-sofia.bg:3260

Конфигурационните декларации, дадени по-горе описани в секция 3 и секция 4 на този документ.

Тази конфигурация трябва да запазите във файл, който да се намира някъде в домашната директория на потребителя, например /home/username/stunnel5/conf.d. Разширението на файла трябва да е *.conf.

Пакетът stunnel5 включа systemd интеграция. Това означава, че всеки отделен конфигурационен файл в /etc/stunnel5/conf.d може да бъде използван за създаването на отделна сървърска или клиентска услуга, базирана на stunnel. По-долу е описано как става това:

• регистриране на нова услуга:

  Ако конфигурацията за услугата се намира във файла /etc/stunnel5/conf.d/service1.conf, то декларирането на услугата става по следния начин:

  $ sudo systemctl enable stunnel5@service1

  (името на услугата е името на префикса на конфигурационния файл).

• стартиране на услуга:

  Ако услугата service1 е дефинирана на база на конфигурацията, която се намира във файла /etc/stunnel5/conf.d/service1.conf, то стартирането на stunnel процеса, предоставящ услугата, става по следния начин:

  $ sudo systemctl start stunnel5@service1

• сприране на услуга:

  Ако услугата service1 е дефинирана на база на конфигурацията, която се намира във файла /etc/stunnel5/conf.d/service1.conf, то спирането на stunnel процеса, предоставящ услугата, става по следния начин:

  $ sudo systemctl start stunnel5@service1

• препрочитане на стартовата конфигурация на услуга:

  Ако услугата service1 е дефинирана на база на конфигурацията, която се намира във файла /etc/stunnel5/conf.d/service1.conf, за да може stunnel процеса, който вече е стартиран на нейна основа, да прочете евентуалните промени в стартовата конфигурация, направени след последното стартиране/рестартиране на услугата, трябва да изпълните следното:

  $ sudo systemctl reload stunnel5@service1

• проверка на текущия статус на услуга:

  Ако услугата service1 е дефинирана на база на конфигурацията, която се намира във файла /etc/stunnel5/conf.d/service1.conf, то проверката на текущия статус на услугата (например, дали процеса на stunnel работи), става по следния начин:

  $ sudo systemctl status stunnel5@service1

7. Управление на процесите на Stunnel без използване на systemd

8. Актуализация на CRL

$ sudo su wget https://pki.uni-sofia.bg/crl/SU_ECC_Root_CA.crl -O /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin
$ sudo su wget https://pki.uni-sofia.bg/crt/UNITe_ECC_CA.crl -O /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin

$ sudo openssl crl -inform DER -in /etc/stunnel5/CRL/SU_ECC_Root_CA.crl.bin -outform PEM -out /etc/stunnel5/CRL/SU_ECC_Root_CA.crl
$ sudo openssl crl -inform DER -in /etc/stunnel5/CRL/UNITe_ECC_CA.crl.bin -outform PEM -out /etc/stunnel5/CRL/UNITe_ECC_CA.crl

9. Управление на журналните ("log") файлове