Eigen TLS, SSH-oerdracht of VPN foar ien cloudtsjinst

De fraach is selden oft der wat tusken twa cloudmasines fersifere moat wurde; it is hokker ynterface jo fersiferje en wa waans identiteit kontrolearret. Ik begjin dizze petearen by de tsjinst ynstee fan it netwurkdiagram, om't de tsjinst al wit wat er nedich hat. Trije grinzen dekke de measte gefallen: de eigen TLS fan 'e applikaasje, ien trochstjoerde TCP-poarte oer SSH en in rûte-oerlaach dy't elke dielnimmer in adres jout. Se wurde net rangearre op krêft, mar op hoefolle fan it probleem se dekke.

Begjin by de tsjinst, net by it netwurk

Wurk fan it proses nei bûten. Hokker protokol praat it, hokker namme sil de klant ferifiearje, en wa mei hielendal in ferbining iepenje? Dy trije antwurden eliminearje opsjes flugger as hokker ferlikingstabel dan ek, en de eigen konfiguraasje fan 'e tsjinst antwurdet se meastentiids yn in pear minuten.

Nim in lytse ynterne API dy't al HTTPS tsjinnet op poarte 8443 mei in sertifikaat foar api.internal.example. ss -ltnp op 'e host lit sjen wêr't it oan ferbynt, en openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example lit sjen oft it sertifikaat jildich is foar de namme dy't de klant echt brûkt. As beide sûn binne, kin de tsjinst syn eigen stream beskermje en bliuwt allinnich berikberens oer. Dat is in folle lytser probleem as in netwurk bouwe.

Stap 1: beskermet de tsjinst himsels?

Dit is de opsje om te kiezen as it past, en it past faker as teams oannimme. De fersifering fan 'e tsjinst dekt it hiele paad tusken klant en server, ynklusyf elke hop dertusken, wat gjin tunnel om it midden hinne ferbetteret. Stel de ferwachte namme en fertrouwen eksplisyt yn ynstee fan te fertrouwen op wat de standertopslach fan 'e klant tafallich befettet.

Fersifering en berikberens bliuwe aparte kontrôles, en it gearfoegjen dêrfan is wêr't dizze opsje misgiet. In TLS-tsjinst op in ûnbeheinde iepenbiere listener akseptearret noch altyd ferbiningspogingen fan elkenien, dus de listener en de netwurkregels moatte apart bepaald wurde fan it feit dat de lading beskerme is. Kontrolearje dan de ôfhinklikheden, want in API oer TLS seit neat oer it ûntdekkings-einpunt, de adminpoarte of it massale oerdrachtskanaal dêrnjonken. Elk dêrfan hat syn eigen antwurd nedich, en ien ûnbeskerme broer is genôch om de hiele grins in fiksje te meitsjen.

Stap 2: is ien TCP-poarte de hiele eask?

As de eask echt ien TCP-poarte is, is in oerdracht it lytste ding dat wurket. In pleatslike SSH-oerdracht draacht dy poarte troch in al besteande autentisearre ferbining.

De foarm is ssh -N -L 8443:127.0.0.1:8443 [email protected], en it detail dat telt is it doeladres: 127.0.0.1 wurdt oan 'e fiere kant oplost, dus de ferbining nei de tsjinst wurdt fan it bastion iepene ynstee fan fan jo laptop. Byn de pleatslike listener smal as -L 127.0.0.1:8443:..., sadat jo de tsjinst net by ûngelok op jo eigen pleatslike netwurk publisearje. Behein oan 'e serverside wat it akkount trochstjoere mei, ynstee fan te fertrouwen dat de klant him goed gedraacht. PermitOpen, AllowTcpForwarding local en in standert GatewayPorts no binne de trije ynstellings dy't in algemien relais yn in spesifyk kanaal feroarje.

It kontrakt is smal yn beide rjochtingen. SSH beskermet syn eigen kanaal, en in fierdere hop fan it bastion nei in oare applikaasje hat syn eigen beskerming nedich. In tsjinst dy't allinnich op 'e loopback fan it bastion harket, hat in hiel oare bleatstelling as ien dy't oer in oar netwurk berikt wurdt, en de oerdracht feroaret dat net. Hâld de autentikaasje en TLS-kontrôles fan 'e applikaasje yn plak ynstee fan de tunnel as har ferfanging te behanneljen.

Dit wurket goed foar ien ferbining mei ien eigner. Op skaal wurdt it in systeem: pleatslike poartekonflikten, tafersjoch, kaairotasjon en de fraach wa't de oerdracht nei in reboot wer start.

Stap 3: is routing de echte eask?

Dy list is de earlike kosten fan 'e lytste opsje, en dêrom ferfange teams úteinlik in hânfol fergetten eftergrûnkommando's troch wat beheard. De ferfanging is net automatysk in VPN. As de eask noch hieltyd ien TCP-poarte is, is in ûnder tafersjoch brochte oerdracht mei in dokumintearre eigner goedkeaper te draaien as in oerlaach en it mislearret op manieren dy't jo sjogge. Mjit operasjoneel eignerskip foardat jo elegance mjit.

Routing wurdt it goede antwurd as routing de eask is. Ferskate applikaasjes dy't gewoane IP-ferbining nedich hawwe, protokollen dy't in TCP-oerdracht net drage kin, of tsjinsten dy't tusken hosts ferhúzje, wize allegear deselde kant út.

In oerlaach jout dielnimmers in adres en in rûte, en dan begjint it echte wurk: net-oerlaapjende berikken, rûte-eignerskip, DNS, ynskriuwing, ynlûken en wat der bart as in peer ferdwynt. Neat dêrfan komt mei it adres. In peer dy't ta de oerlaach talitten is, is ek net automatysk autorisearre foar elke operaasje op 'e bestimming, dus autentikaasje op tsjinstnivo bliuwt.

Wat jo dêrnei besitte

Twa dingen hearre yn it register dat jo efterlitte. It earste is de identiteit dy't de klant ferwachte wurdt te ferifiearjen, want elk fan dizze grinzen giet stil efterút sadree't in nammentekkening fersloppe wurdt om wat wurkje te litten. It twadde is de fuorthelingsstap: hokker kaai, hokker regel of hokker rûte ferdwynt as tagong einiget, en wa't dat docht.

De rûnlieding einiget wêr't er begon, by de tsjinst. Kies de grins dy't it werklike ferkear dekt en de peers ferifiearret dy't jo bedoelden te ferifiearjen, en skriuw dan op hoe't tagong bywurke, kontrolearre en fuortsmiten wurdt. De OpenSSH-referinsje is it plak om de oerdrachtsopsjes te befêstigjen foardat jo in smel kontrakt tasizze. As jo de fuorthelingsstap net yn ien sin beskriuwe kinne, is de grins grutter as it probleem.