SSL VPN или TLS омот? Упоредите границу која је пала

Два дизајна могу да држе TLS на порту 443 и да тиме значе сасвим различите ствари. Омот штити једну конфигурисану везу између локалног порта и удаљеног backend-а. Дизајн мрежног приступа преноси изабрани саобраћај и мења шта клијент може да достигне. Прођите четири провере испод редом и знаћете на коју гледате, што је обично довољно да знате који је слој отказао.

Почните од везе коју сте заиста конфигурисали

Запишите предњи и задњи крај пре него што упоредите производе. Омот слуша на локалној адреси и прослеђује на удаљену или покреће програм на удаљеној страни, и тај пар је цео његов уговор. Остале апликације клијента не знају ништа о њему осим ако их усмерите на њега. То није недостатак алата, то је његова сврха.

Уговор мрежног дизајна је другачији и изражава се у рутама и политици, а не у пару портова.

Приметите који од та два описа одговара вашој шеми. Ако је одговор једно мапирање порта са сертификатом у средини, имате омот чак и када назив производа каже VPN. Ако је одговор интерфејс тунела и промене рута, имате мрежни дизајн чак и када ради на 443.

Проверите на шта се омот повезује

Прочитајте подешавања слушања и повезивања и пратите их до стварног backend-а. Омот који прослеђује на порт базе података не отвара веб апликацију, а омот који извршава програм покреће тај програм уместо да објави све остало што хост извршава. Backend је једино што омот зна.

Затим одлучите да ли је прослеђени ток обичан текст након што TLS заврши. Омотана веза штити сегмент између два омота, а оно што се дешава после далеког омота је одвојено питање. Зато је омотавање нечега што већ носи сопствену заштиту понекад разумно, а понекад само додатни покретни делови. Прегледајте следећи корак уместо да претпоставите било који од два одговора.

openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443

Прва команда показује сертификат који се клијенту заиста нуди, а друга показује шта слуша на хосту. Упоредите то име сертификата са оним које сте очекивали пре него што прочитате било шта друго.

Проверите који саобраћај дизајн преноси

Дизајни мрежног приступа преносе изабрани саобраћај и интегришу се са рутирањем и политиком приступа клијента. Пријем није ауторизација, па ауторизована веза и даље треба одлуку о томе до којих ресурса може да достигне. Портал без клијента је трећи модел који посредује подржане операције без тога да се икада појави као интерфејс tun.

Ознака производа не говори који сте од тих модела купили, а број порта говори још мање.

Слојевитост је могућа и не сме да збуни поређење. Тунелски протокол и сам може бити омотан у TLS у подржаном TCP распореду, што додаје слој око тунела без претварања омота у тунел. То је дизајнерска одлука са сопственим понашањем перформанси и отказа и заслужује ред у шеми. Забележите је, а затим упоредите основне моделе, а не спољни омот.

Проверите границу која је пала, не ознаку

Запишите чињенице за један неуспешан покушај: адреса предњег краја, слушалац, идентитет који је клијент проверио, циљ backend-а и тражена операција. Успешно руковање доказује да је спољни TLS завршен и не говори ништа о backend-у. Одбијање backend-а је други догађај од отказа идентитета на предњем крају, и ниједно се не поправља уклањањем -verify_return_error из клијента. Упоредите слично са сличним, јер успех кроз друго име хоста или порт не показује да су услови били исти.

Порт 443 је конвенција која пушта TLS кроз међусклопове. Она не чини произвољан саобраћај сличним веб захтеву за уређај политике.

Завршите једном реченицом која именује пар крајњих тачака, шта се преноси, које апликације га користе и какву дозволу одредиште спроводи. Дизајн који не може да попуни те четири празнине није завршен, шта год његова ознака тврдила. Та реченица је и најбржи начин да објасните дизајн ономе ко поседује заштитни зид.