Etä-SSH VPN:n yli: mitä tunneli ei tee

VPN antaa SSH-palvelimelle yksityisen reitin ja poistaa tarpeen julkiselle kuuntelijalle portissa 22. Se ei todista isäntää, valtuuta käyttäjää eikä päätä, mitkä tilit saavat kirjautua sisään. Se jää SSH:n tehtäväksi. Onko VPN oikea tapa päästä palvelimelle, riippuu kolmesta ehdosta, ja tunneli on vain yksi mahdollisista vastauksista.

Mitä tunneli muuttaa ja mitä SSH yhä päättää

Tunneli muuttaa tavoitettavuutta: mitä osoitteita voidaan saavuttaa ja mistä. Se ei muuta sitä, mitä tapahtuu, kun TCP-yhteys saapuu, missä palvelin esittää isäntäavaimen ja pyytää käyttäjän identiteettiä.

Pidä kaksi kerrosta erillään sekä päässäsi että dokumentaatiossasi. VPN-kirjautuminen todistaa, kuka saa käyttää verkkoa. Se ei kerro mitään siitä, mitä tilejä kohteessa on, eikä se ole lupa kirjautua jokaiseen tavoitettavaan koneeseen.

Myös epäonnistumistilat ovat erillisiä, ja juuri se tekee erottelusta hyödyllisen tapahtuman aikana.

Kolme ehtoa, jotka määräävät käyttömallin

Ensinnäkin, täytyykö palvelimen olla verkkosi ulkopuolisten ihmisten tavoitettavissa? Jos ei, yksityinen reitti sekä bastion tai mesh on pienempi suunnittelu. Toiseksi, voiko asiakaskunta todella ajaa VPN-asiakasta, mukaan lukien ne, jotka ovat rajoituksilla varustetuilla hallituilla laitteilla?

Kolmanneksi, tarvitsetko palvelukohtaista vai käyttäjäkohtaista hallintaa? VPN myöntää verkon kantaman; SSH myöntää tilin käyttöoikeuden. Jos vaatimus on, että urakoitsija saavuttaa yhden isännän eikä mitään muuta, se on valtuutusvaatimus, eikä pelkkä tunneli voi ilmaista sitä.

Vastaa noihin kolmeen, niin malli valitsee itse itsensä. Ohita ne, niin päädyt paljastamaan SSH:n julkisesti välttääksesi asiakaskäyttöönoton.

Vahvista yksityinen reitti ennen kuin syytät SSH:ta

Yhdistä hyväksyttyyn VPN:hen ja käytä kohteen dokumentoitua yksityistä nimeä tai osoitetta. Tarkista sitten valittu reitti, yhdyskäytävän lupa ja paluureitti asiakkaalle. Nimi, joka ratkeaa oikein, ei ole todiste siitä, että osoite ottaa aiotun tunnelin, koska päällekkäiset paikalliset ja etäetuliitteet voivat lähettää pyynnön aivan muualle. Tämä ero kannattaa kirjoittaa runbookiin.

Jos yhteys ei koskaan saavu, varmista, että palvelin kuuntelee odottamallasi rajapinnalla ja että sen isäntäpalomuuri sallii lähteen, jonka se todella näkee. Yhdyskäytävän NAT voi kirjoittaa lähteen uudelleen, joten asiakkaan tunneliosoitteelle kirjoitettu sallittujen luettelo ei ehkä koskaan täsmää.

Tämä epäsuhta on yleisin itse aiheutettu SSH-vika VPN:n yli.

Lue epäonnistumisvaihe, älä yhdistettyä virhettä

Kolme vaihetta tuottaa kolme eri viestiä, ja vain yksi niistä koskee tunnistetietoja.

Käytä täsmällistä virhettä ja palvelimen omaa lokia sen sijaan, että nollaisit sekä VPN- että SSH-tunnistetiedot yhtä aikaa. Molempien nollaus on tapa, jolla viiden minuutin diagnoosista tulee kahden päivän identiteettitapahtuma.

Yksityiskohtainen tuloste näyttää, mihin vaiheeseen pääsit:

ssh -vv [email protected]

Pidä isäntäavaimet ja valtuutus ehjinä

Validoi isäntäavain aiotun luotetun prosessin kautta, erityisesti palvelimen vaihdon jälkeen. Odottamaton vaihtuneen avaimen varoitus on ainoa viesti, jota et saa jättää huomiotta vain siksi, että VPN yhdisti, koska yksityinen tunneli ei tee kohteesta sitä konetta, jota luulet. Tarkista sormenjälki lähteestä, johon luotat yhteydestä riippumatta.

Palvelimen puolella varmista, että tili on valtuutettu ja että määrittämäsi todennusmenetelmä on se, jota tarjotaan. Avain, joka on läsnä mutta ohitetaan, on yleensä käyttöoikeus- tai kokoonpano-ongelma eikä verkko-ongelma.

Rajaa palvelun käyttöoikeus vaadittuihin identiteetteihin ja pidä valtuutettu palautumispolku verkkomuutoksia varten.