Fora SSH tra VPN: kion la tunelo ne faras

VPN donas al SSH-servilo privatan vojon kaj forigas la bezonon de publika aŭskultanto sur pordo 22. Ĝi ne aŭtentikigas la gastiganton, ne rajtigas la uzanton kaj ne decidas, kiuj kontoj rajtas ensaluti. Tio restas la tasko de SSH. Ĉu VPN estas la ĝusta maniero atingi la servilon dependas de tri kondiĉoj, kaj la tunelo estas nur unu el la eblaj respondoj.

Kion la tunelo ŝanĝas kaj kion SSH ankoraŭ decidas

La tunelo ŝanĝas atingeblon: kiujn adresojn eblas atingi, kaj de kie. Ĝi ne ŝanĝas tion, kio okazas post kiam la TCP-konekto alvenas, kie la servilo prezentas gastigantan ŝlosilon kaj petas uzantan identecon.

Tenu la du tavolojn aparte en via kapo kaj en via dokumentaro. Ensaluto al VPN pruvas, kiu rajtas uzi la reton. Ĝi diras nenion pri tio, kiuj kontoj ekzistas sur la celo, kaj ĝi ne estas permeso ensaluti al ĉiu atingebla maŝino.

Ankaŭ la fiaskomanieroj estas apartaj, kaj tio estas kio utiligas la apartigon dum okazaĵo.

Tri kondiĉoj, kiuj decidas la alirmodelon

Unue, ĉu la servilo devas esti atingebla de homoj ekster via reto? Se ne, privata vojo plus bastiono aŭ maŝo estas la pli malgranda dezajno. Due, ĉu la klienta loĝantaro povas efektive ruli la VPN-klienton, inkluzive tiujn sur administrataj aparatoj kun limigoj?

Trie, ĉu vi bezonas regadon laŭ servo aŭ regadon laŭ uzanto? VPN donas retan atingon; SSH donas kontan aliron. Se la postulo estas, ke entreprenisto atingu unu gastiganton kaj nenion alian, tio estas rajtiga postulo kaj la tunelo sola ne povas esprimi ĝin.

Respondu tiujn tri kaj la modelo elektas sin mem. Preterlasu ilin kaj vi finas malkaŝante SSH publike por eviti la enkondukon de la kliento.

Konfirmu la privatan vojon antaŭ ol kulpi SSH

Konektiĝu al la aprobita VPN kaj uzu la dokumentitan privatan nomon aŭ adreson de la celo. Poste kontrolu la elektitan vojon, la permeson de la pordego kaj la revenan vojon al la kliento. Nomo, kiu solviĝas ĝuste, ne estas pruvo, ke la adreso prenas la celitan tunelon, ĉar interkovrantaj lokaj kaj malproksimaj prefiksoj povas sendi la peton tute aliloke. Tiu distingo indas esti skribita en la runlibro.

Se la konekto neniam alvenas, konfirmu, ke la servilo aŭskultas sur la interfaco, kiun vi atendas kaj ke ĝia gastiganta fajroŝirmilo permesas la fonton, kiun ĝi efektive vidas. Pordega NAT povas reskribi tiun fonton, do permeslisto skribita por la tunela adreso de la kliento eble neniam kongruos.

Tiu miskongruo estas la plej ofta memkaŭzita SSH-fiasko tra VPN.

Legu la fiaskan stadion, ne la kombinitan eraron

Tri stadioj produktas tri malsamajn mesaĝojn, kaj nur unu el ili temas pri akreditaĵoj.

Uzu la precizan eraron kaj la propran protokolon de la servilo anstataŭ restarigi kaj VPN- kaj SSH-akreditaĵojn kune. Restarigi ambaŭ estas la maniero, kiel kvinminuta diagnozo fariĝas dudaga identeca okazaĵo.

La detala eligo montras, kiun stadion vi atingis:

ssh -vv [email protected]

Konservu gastigantajn ŝlosilojn kaj rajtigon sendifektaj

Validigu la gastigantan ŝlosilon per la celita fidinda procezo, precipe post anstataŭigo de servilo. Neatendita averto pri ŝanĝita ŝlosilo estas la sola mesaĝo, kiun vi devas ne ignori nur ĉar la VPN konektiĝis, ĉar privata tunelo ne faras la celon la maŝino, kiun vi pensas. Kontrolu la fingrospuron kontraŭ fonto, kiun vi fidas sendepende de la konekto.

Ĉe la servila flanko, konfirmu, ke la konto estas rajtigita kaj ke la aŭtentikiga metodo, kiun vi agordis, estas la proponata. Ŝlosilo, kiu ĉeestas sed estas ignorata, kutime estas permesa aŭ agorda problemo prefere ol reta.

Limigu servan aliron al la postulataj identecoj kaj konservu rajtigitan restaŭran vojon por retaj ŝanĝoj.