Propra TLS, SSH-plusendado aŭ VPN por unu nuba servo

La demando malofte estas ĉu ĉifri ion inter du nubaj maŝinoj; ĝi estas kiun interfacon vi ĉifras kaj kiu kontrolas kies identecon. Mi komencas ĉi tiujn konversaciojn ĉe la servo, ne ĉe la reta diagramo, ĉar la servo jam scias, kion ĝi bezonas. Tri limoj kovras plej multajn kazojn: la propra TLS de la aplikaĵo, unu plusendita TCP-pordo tra SSH, kaj rutigita tavolo, kiu donas al ĉiu partoprenanto adreson. Ili ne estas ordigitaj laŭ forto, sed laŭ kiom da la problemo ili kovras.

Komencu ĉe la servo, ne ĉe la reto

Iru eksteren de la procezo. Kiun protokolon ĝi parolas, kiun nomon la kliento kontrolos, kaj kiu rajtas malfermi konekton entute? Tiuj tri respondoj forigas eblojn pli rapide ol iu ajn kompara tabelo, kaj la propra agordo de la servo kutime respondas ilin en kelkaj minutoj.

Prenu malgrandan internan API, kiu jam servas HTTPS sur pordo 8443 kun atestilo por api.internal.example. ss -ltnp sur la gastiganto montras, al kio ĝi ligiĝas, kaj openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example montras, ĉu la atestilo validas por la nomo, kiun la kliento efektive uzos. Se ambaŭ sanas, la servo povas protekti sian propran fluon kaj restas nur atingeblo. Tio estas multe pli malgranda problemo ol konstrui reton.

Paŝo 1: ĉu la servo protektas sin mem?

Ĉi tio estas la eblo preni kiam ĝi taŭgas, kaj ĝi taŭgas pli ofte ol teamoj supozas. La ĉifrado de la servo kovras la tutan vojon inter kliento kaj servilo, inkluzive ĉiun salton intere, kion neniu tunelo ĉirkaŭ la mezo plibonigas. Agordu la atendatan nomon kaj fidon eksplicite anstataŭ fidi tion, kion la defaŭlta konservejo de la kliento hazarde enhavas.

Ĉifrado kaj atingeblo restas apartaj kontroloj, kaj ĝuste ilia kunfandiĝo estas kie ĉi tiu eblo eraras. TLS-servo sur senlima publika aŭskultanto ankoraŭ akceptas konektoprovojn de iu ajn, do la aŭskultanto kaj la retaj reguloj devas esti limigitaj sendepende de la fakto, ke la utilaĵo estas protektita. Poste kontrolu la dependecojn, ĉar API super TLS diras nenion pri la malkovra finpunkto, la administra pordo aŭ la amasa transiga kanalo apude. Ĉiu el ili bezonas propran respondon, kaj unu neprotektita frato sufiĉas por fari la tutan limon fikcio.

Paŝo 2: ĉu unu TCP-pordo estas la tuta postulo?

Kiam la postulo vere estas unu TCP-pordo, plusendado estas la plej malgranda afero, kiu funkcias. Loka SSH-plusendado portas tiun pordon tra jam ekzistanta aŭtentikigita konekto.

La formo estas ssh -N -L 8443:127.0.0.1:8443 [email protected], kaj la grava detalo estas la cela adreso: 127.0.0.1 estas solvata ĉe la fora flanko, do la konekto al la servo malfermiĝas el la bastiono anstataŭ el via tekkomputilo. Ligu la lokan aŭskultanton mallarĝe kiel -L 127.0.0.1:8443:... por ke vi ne hazarde publikigu la servon en via propra loka reto. Ĉe la servila flanko, limigu kion la konto rajtas plusendi anstataŭ fidi ke la kliento kondutos bone. PermitOpen, AllowTcpForwarding local kaj defaŭlta GatewayPorts no estas la tri agordoj, kiuj transformas ĝeneralan relajson en specifan kanalon.

La kontrakto estas mallarĝa en ambaŭ direktoj. SSH protektas sian propran kanalon, kaj plua salto de la bastiono al alia aplikaĵo bezonas sian propran protekton. Servo aŭskultanta nur ĉe la loopback de la bastiono havas tute alian eksponiĝon ol unu atingata trans alia reto, kaj la plusendado tion ne ŝanĝas. Konservu la aŭtentikigon kaj TLS-kontrolojn de la aplikaĵo anstataŭ trakti la tunnelon kiel ilian anstataŭaĵon.

Ĉi tio bone funkcias por unu konekto kun unu posedanto. Je skalo ĝi fariĝas sistemo: lokaj pordokonfliktoj, superrigardo, ŝlosilrotacio kaj la demando, kiu restartigos la plusendadon post restartigo.

Paŝo 3: ĉu rutado estas la efektiva postulo?

Tiu listo estas la honesta kosto de la plej malgranda eblo, kaj tial teamoj fine anstataŭigas manplenon da forgesitaj fonkomandoj per io administrata. La anstataŭaĵo ne estas aŭtomate VPN. Se la postulo ankoraŭ estas unu TCP-pordo, superrigardata plusendado kun dokumentita posedanto estas pli malmultekosta por funkciigi ol tavolo, kaj ĝi malsukcesas laŭ manieroj, kiujn vi povas vidi. Mezuru operacian posedon antaŭ ol mezuri elegantecon.

Rutado fariĝas la ĝusta respondo kiam rutado estas la postulo. Pluraj aplikaĵoj bezonantaj ordinaran IP-konektecon, protokoloj, kiujn TCP-plusendado ne povas porti, aŭ servoj moviĝantaj inter gastigantoj ĉiuj montras la saman direkton.

Tavolo donas al partoprenantoj adreson kaj itineron, kaj tiam komenciĝas la vera laboro: ne-koincidaj intervaloj, itinera posedo, DNS, aliĝo, revoko kaj kio okazas kiam kunulo malaperas. Nenio el tio venas kun la adreso. Akceptita kunulo en la tavolo ankaŭ ne aŭtomate rajtas por ĉiu operacio ĉe la celo, do aŭtentikigo je serva nivelo restas.

Kion vi posedas poste

Du aferoj apartenas al la rekordo, kiun vi lasas. La unua estas la identeco, kiun la kliento atendas kontroli, ĉar ĉiu el ĉi tiuj limoj silente difektiĝas tuj kiam nomkontrolo malstreĉiĝas por igi ion funkcii. La dua estas la foriga paŝo: kiu ŝlosilo, kiu regulo aŭ kiu itinero malaperas kiam aliro finiĝas, kaj kiu faras ĝin.

La promenado finiĝas kie ĝi komenciĝis, ĉe la servo. Elektu la limon, kiu kovras la faktan trafikon kaj kontrolas la kunulojn, kiujn vi intencis kontroli, poste skribu, kiel aliro estas ĝisdatigata, observata kaj forigata. La OpenSSH-referenco estas la loko por konfirmi la plusendajn opciojn antaŭ ol promesi mallarĝan kontrakton. Se vi ne povas priskribi la forigan paŝon en unu frazo, la limo estas pli granda ol la problemo.