TLS brodorol, trosglwyddo SSH neu VPN ar gyfer un gwasanaeth cwmwl

Anaml y gofynnir a ddylid amgryptio rhywbeth rhwng dau beiriant cwmwl; y cwestiwn yw pa ryngwyneb yr ydych yn ei amgryptio a phwy sy'n gwirio pwy. Dechreuaf y sgyrsiau hyn gyda'r gwasanaeth yn hytrach na'r diagram rhwydwaith, oherwydd mae'r gwasanaeth eisoes yn gwybod beth sydd ei angen. Mae tair ffin yn cwmpasu'r rhan fwyaf o achosion: TLS yr ap ei hun, un porth TCP wedi'i drosglwyddo dros SSH, a haen drosodd wedi'i chyfeirio sy'n rhoi cyfeiriad i bob cyfranogwr. Nid ydynt wedi'u rhestru yn ôl cryfder, ond yn ôl faint o'r broblem y maent yn ei chwmpasu.

Dechreuwch gyda'r gwasanaeth, nid y rhwydwaith

Cerddwch allan o'r broses. Pa brotocol mae'n ei siarad, pa enw fydd y cleient yn ei wirio, a phwy sy'n cael agor cysylltiad o gwbl? Mae'r tri ateb hynny'n dileu opsiynau'n gyflymach nag unrhyw dabl cymharu, ac mae cyfluniad y gwasanaeth ei hun fel arfer yn eu hateb mewn ychydig funudau.

Cymerwch API mewnol bach sydd eisoes yn gwasanaethu HTTPS ar borth 8443 gyda thystysgrif ar gyfer api.internal.example. Mae ss -ltnp ar y gwesteiwr yn dangos beth y mae'n rhwymo iddo, ac mae openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example yn dangos a yw'r dystysgrif yn dilysu ar gyfer yr enw y bydd y cleient yn ei ddefnyddio mewn gwirionedd. Os yw'r ddau'n iach, gall y gwasanaeth amddiffyn ei ffrwd ei hun a dim ond cyrhaeddedd sydd ar ôl. Mae hynny'n broblem lawer llai na chodi rhwydwaith.

Cam 1: a yw'r gwasanaeth yn amddiffyn ei hun?

Dyma'r opsiwn i'w gymryd pan fydd yn gweddu, ac mae'n gweddu'n amlach nag y mae timau'n tybio. Mae amgryptiad y gwasanaeth yn cwmpasu'r llwybr cyfan rhwng cleient a gweinydd, gan gynnwys pob naid rhyngddynt, nad oes unrhyw dwnnel o amgylch y canol yn ei wella. Gosodwch yr enw disgwyliedig a'r ymddiriedaeth yn benodol yn lle dibynnu ar beth bynnag sydd yn storfa ragosodedig y cleient.

Mae amgryptio a chyrhaeddedd yn parhau'n reolyddion ar wahân, a chyfuno'r ddau yw lle mae'r opsiwn hwn yn mynd o'i le. Mae gwasanaeth TLS ar wrandawr cyhoeddus heb gyfyngiad yn dal i dderbyn ymdrechion cysylltu gan unrhyw un, felly rhaid cwmpasu'r gwrandawr a'r rheolau rhwydwaith yn annibynnol ar y ffaith bod y llwyth yn cael ei amddiffyn. Yna gwiriwch y dibyniaethau, oherwydd nid yw API dros TLS yn dweud unrhyw beth am y pwynt darganfod, y porth gweinyddol na'r sianel trosglwyddo swmp wrth ei ymyl. Mae angen ateb ei hun ar bob un, ac mae un brawd heb ei amddiffyn yn ddigon i wneud y ffin gyfan yn ffuglen.

Cam 2: ai un porth TCP yw'r gofyniad cyfan?

Pan fo'r gofyniad mewn gwirionedd yn un porth TCP, trosglwyddiad yw'r peth lleiaf sy'n gweithio. Mae trosglwyddiad lleol SSH yn cario'r porth hwnnw drwy gysylltiad dilys sydd eisoes yn bodoli.

Y siâp yw ssh -N -L 8443:127.0.0.1:8443 [email protected], a'r manylyn sy'n bwysig yw'r cyfeiriad targed: mae 127.0.0.1 yn cael ei ddatrys ar yr ochr bell, felly agorir y cysylltiad â'r gwasanaeth o'r bastion yn hytrach nag o'ch gliniadur. Rhwymwch y gwrandawr lleol yn gul fel -L 127.0.0.1:8443:... fel nad ydych yn cyhoeddi'r gwasanaeth i'ch rhwydwaith lleol eich hun ar ddamwain. Ar ochr y gweinydd, cyfyngwch yr hyn y gall y cyfrif ei drosglwyddo yn lle ymddiried y bydd y cleient yn ymddwyn. PermitOpen, AllowTcpForwarding local a GatewayPorts no diofyn yw'r tri gosodiad sy'n troi relái cyffredinol yn sianel benodol.

Mae'r contract yn gul yn y ddau gyfeiriad. Mae SSH yn amddiffyn ei sianel ei hun, ac mae angen ei amddiffyniad ei hun ar naid bellach o'r bastion i ap arall. Mae gan wasanaeth sy'n gwrando ar loopback y bastion yn unig amlygiad tra gwahanol i un a gyrhaeddir dros rwydwaith arall, ac nid yw'r trosglwyddiad yn newid hynny. Cadwch ddilysu a gwiriadau TLS yr ap yn eu lle yn lle trin y twnnel fel eu dirprwy.

Mae hyn yn gweithio'n dda ar gyfer un cysylltiad ag un perchennog. Ar raddfa mae'n dod yn system: gwrthdaro porth lleol, goruchwyliaeth, cylchdroi allweddi a'r cwestiwn pwy sy'n ailgychwyn y trosglwyddiad ar ôl ailgychwyn.

Cam 3: ai cyfeirio yw'r gwir ofyniad?

Mae'r rhestr honno'n gost onest yr opsiwn lleiaf, a dyna pam mae timau yn y pen draw yn disodli llond llaw o orchmynion cefndir wedi'u hanghofio â rhywbeth a reolir. Nid yw'r disodliad yn VPN yn awtomatig. Os yw'r gofyniad yn dal i fod yn un porth TCP, mae trosglwyddiad dan oruchwyliaeth gyda pherchennog wedi'i ddogfennu'n rhatach i'w redeg na haen drosodd ac mae'n methu mewn ffyrdd y gallwch eu gweld. Mesurwch berchnogaeth weithredol cyn mesur cain.

Mae cyfeirio'n dod yn ateb cywir pan fo cyfeirio'r gofyniad. Mae sawl ap sydd angen cysylltedd IP cyffredin, protocolau na all trosglwyddiad TCP eu cario, neu wasanaethau sy'n symud rhwng gwesteiwyr i gyd yn pwyntio'r un ffordd.

Mae haen drosodd yn rhoi cyfeiriad a llwybr i gyfranogwyr, ac yna mae'r gwaith go iawn yn dechrau: ystodau nad ydynt yn gorgyffwrdd, perchnogaeth llwybrau, DNS, cofrestru, dirymu a beth sy'n digwydd pan fo cymar yn diflannu. Nid oes unrhyw beth o hyn yn dod gyda'r cyfeiriad. Nid yw cymar a dderbyniwyd i'r haen drosodd ychwaith wedi'i awdurdodi'n awtomatig ar gyfer pob gweithrediad ar y cyrchfan, felly mae dilysu ar lefel gwasanaeth yn aros.

Beth sy'n eiddo i chi wedyn

Mae dau beth yn perthyn i'r cofnod a adewch ar ôl. Y cyntaf yw'r hunaniaeth y disgwylir i'r cleient ei gwirio, oherwydd mae pob un o'r ffiniau hyn yn dirywio'n dawel unwaith y bydd gwiriad enw'n cael ei lacio i wneud rhywbeth yn gweithio. Yr ail yw'r cam tynnu: pa allwedd, pa reol neu pa lwybr sy'n diflannu pan ddaw mynediad i ben, a phwy sy'n ei gyflawni.

Mae'r daith yn gorffen lle y dechreuodd, gyda'r gwasanaeth. Dewiswch y ffin sy'n cwmpasu'r traffig gwirioneddol ac yn gwirio'r cymarau yr oeddech am eu gwirio, yna nodwch sut y mae mynediad yn cael ei ddiweddaru, ei fonitro a'i dynnu. Y cyfeirlyfr OpenSSH yw'r man i gadarnhau'r opsiynau trosglwyddo cyn addo contract cul. Os na allwch ddisgrifio'r cam tynnu mewn un frawddeg, mae'r ffin yn fwy na'r broblem.