Eigið TLS, SSH-framsending eða VPN fyrir eina skýjaþjónustu

Spurningin er sjaldan hvort dulkóða eigi eitthvað milli tveggja skýjavéla; hún er hvaða viðmót þú dulkóðar og hver athugar hverjir. Ég byrja þessi samtöl á þjónustunni frekar en netteikningunni, því þjónustan veit nú þegar hvað hún þarf. Þrjú mörk ná yfir flest tilvik: eigið TLS forritsins, einn framsendur TCP-port yfir SSH og leiðslað yfirlag sem gefur hverjum þátttakanda vistfang. Þau eru ekki röðuð eftir styrk heldur eftir því hve mikið af vandamálinu þau ná yfir.

Byrjaðu á þjónustunni, ekki netinu

Farðu út frá ferlinu. Hvaða samskiptareglu talar það, hvaða nafn mun biðlarinn sannreyna og hver má yfirhöfuð opna tengingu? Þessi þrjú svör útiloka valkosti hraðar en hvaða samanburðartafla sem er, og eigin stilling þjónustunnar svarar þeim venjulega á nokkrum mínútum.

Taktu lítið innra API sem þegar þjónar HTTPS á porti 8443 með skírteini fyrir api.internal.example. ss -ltnp á hýsilnum sýnir við hvað það bindst, og openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example sýnir hvort skírteinið gildir fyrir nafnið sem biðlarinn mun raunverulega nota. Ef bæði eru heilbrigð getur þjónustan varið eigin straum og aðeins aðgengi er eftir. Það er miklu minna vandamál en að byggja net.

Skref 1: ver þjónustan sjálfa sig?

Þetta er valkosturinn þegar hann hentar, og hann hentar oftar en teymi gera ráð fyrir. Dulkóðun þjónustunnar nær yfir alla leiðina milli biðlara og netþjóns, þar á meðal hvert stökk á milli, sem engin göng utan um miðjuna bæta. Stilltu væntanlegt nafn og traust skýrt í stað þess að treysta á það sem skyldugeymsla biðlarans inniheldur fyrir tilviljun.

Dulkóðun og aðgengi eru áfram aðskilin stýring, og sameining þeirra er þar sem þessi valkostur fer úrskeiðis. TLS-þjónusta á ótakmörkuðum opinberum hlustara tekur enn við tengingartilraunum frá hverjum sem er, svo hlustarinn og netreglurnar verða að vera afmarkaðar óháð því að hyrningurinn er varinn. Athugaðu síðan háðin, því API yfir TLS segir ekkert um uppgötvunarendapunkt, stjórnborðið eða magnflutningsrásina við hliðina. Hvert þeirra þarf sitt svar, og eitt óvarið systkini nægir til að gera allt markið að skáldskap.

Skref 2: er einn TCP-port allt skilyrðið?

Þegar skilyrðið er raunverulega einn TCP-portur er framsending minnsta hluturinn sem virkar. SSH-framsending á staðnum ber þann port í gegnum þegar tiltekna auðkennda tengingu.

Formið er ssh -N -L 8443:127.0.0.1:8443 [email protected], og smáatriðið sem skiptir máli er markvistfangið: 127.0.0.1 er leyst á fjarlægu hliðinni, svo tengingin við þjónustuna er opnuð frá bastíunni frekar en fartölvunni þinni. Bindtu staðbundna hlustarann þröngt sem -L 127.0.0.1:8443:... svo þú birtir þjónustuna ekki óvart á eigin staðarneti. Á netþjónshlið, takmarkaðu hvað reikningnum er heimilt að framsenda í stað þess að treysta því að biðlarinn hagi sér vel. PermitOpen, AllowTcpForwarding local og sjálfgefið GatewayPorts no eru þrjár stillingar sem gera almenna endurvarpa að ákveðinni rás.

Samningurinn er þröngur í báðar áttir. SSH verndar eigin rás, og frekara stökk frá bastíunni til annars forrits þarf eigin vernd. Þjónusta sem hlustar aðeins á loopback bastíunnar hefur gjörólíka vá heldur en sú sem næst yfir annað net, og framsendingin breytir því ekki. Haltu auðkenningu og TLS-athugunum forritsins á sínum stað í stað þess að meðhöndla göngin sem staðgengil þeirra.

Þetta virkar vel fyrir eina tengingu með einum eiganda. Í stærri skala verður þetta kerfi: staðbundin portárekstur, eftirlit, lyklaskipti og spurningin hver endurræsir framsendinguna eftir endurræsingu.

Skref 3: er leiðsla raunverulega skilyrðið?

Sá listi er heiðarlegur kostnaður minnsta valkostsins, og þess vegna skipta teymi að lokum út handfylli gleymdra bakgrunnsskipana fyrir eitthvað stýrt. Utskiptingin er ekki sjálfkrafa VPN. Ef skilyrðið er enn einn TCP-portur er eftirlitsskyld framsending með skjalfestum eiganda ódýrari í rekstri en yfirlag og bregst á sýnilega vegu. Mældu rekstrareign fyrir mælingum á glæsileika.

Leiðsla verður rétta svarið þegar leiðsla er skilyrðið. Nokkur forrit sem þurfa venjulega IP-tengingu, samskiptareglur sem TCP-framsending getur ekki borið eða þjónustur sem flytjast milli hýsla benda öll í sömu átt.

Yfirlag gefur þátttakendum vistfang og leið, og þá hefst raunverulega verkið: svið sem skarast ekki, eignarhald leiða, DNS, skráning, afturköllun og hvað gerist þegar jafningi hverfur. Ekkert af þessu kemur með vistfanginu. Jafningi sem er tekinn inn í yfirlagið er heldur ekki sjálfkrafa heimilaður fyrir hverja aðgerð á áfangastaðnum, svo auðkenning á þjónustustigi helst.

Hvað þú átt eftir

Tvennt tilheyrir skránni sem þú skilur eftir. Hið fyrra er auðkennið sem biðlarans er ætlað að sannreyna, því hvert þessara marka versnar hljóðlega um leið og nafnathugun er slökuð til að fá eitthvað til að virka. Hið síðara er fjarlægingarskrefið: hvaða lykill, hvaða regla eða hvaða leið hverfur þegar aðgangi lýkur, og hver framkvæmir það.

Gönguferðin endar þar sem hún byrjaði, við þjónustuna. Veldu markið sem nær yfir raunverulega umferð og sannreynir þá jafningja sem þú ætlaðir að sannreyna, og skrifaðu síðan hvernig aðgangur er uppfærður, fylgst með og fjarlægður. OpenSSH tilvísunin er staðurinn til að staðfesta framsendingarvalkostina áður en þú lofar þröngum samningi. Ef þú getur ekki lýst fjarlægingarskrefinu í einni setningu er markið stærra en vandamálið.