Oddaljeni SSH prek VPN: česa tunel ne naredi
VPN naredi SSH strežnik dosegljiv in nič več. Trije pogoji odločijo, ali ustreza, faza odpovedi pa pokaže, kateri sloj je kriv.
VPN da SSH strežniku zasebno pot in odpravi potrebo po javnem poslušalcu na vratih 22. Ne preverja identitete gostitelja, ne avtorizira uporabnika in ne odloča, kateri računi se lahko prijavijo. To ostaja naloga SSH. Ali je VPN pravi način za dosego strežnika, je odvisno od treh pogojev, tunel pa je le eden od možnih odgovorov.
Kaj tunel spremeni in kaj SSH še vedno odloča
Tunel spremeni dosegljivost: kateri naslovi so dosegljivi in od kod. Ne spremeni tega, kar se zgodi po vzpostavitvi povezave TCP, ko strežnik predstavi gostiteljski ključ in zahteva uporabniško identiteto.
Dva sloja imejte ločeno v glavi in v dokumentaciji. Prijava v VPN dokaže, kdo sme uporabljati omrežje. Ne pove ničesar o tem, kateri računi obstajajo na cilju, in ni dovoljenje za prijavo v vsak dosegljiv stroj.
Tudi načini odpovedi so ločeni, in prav zato je ločevanje koristno med incidentom.
Trije pogoji, ki odločijo o modelu dostopa
Prvič, mora biti strežnik dosegljiv ljudem zunaj vašega omrežja? Če ne, je zasebna pot plus bastion ali mesh manjša zasnova. Drugič, ali lahko skupina odjemalcev dejansko zažene odjemalca VPN, tudi tisti na upravljanih napravah z omejitvami?
Tretjič, potrebujete nadzor po storitvi ali po uporabniku? VPN podeli omrežni doseg; SSH podeli dostop do računa. Če je zahteva, da izvajalec doseže enega gostitelja in nič drugega, je to zahteva po avtorizaciji in sam tunel je ne more izraziti.
Odgovorite na te tri in model se izbere sam. Če jih preskočite, na koncu izpostavite SSH javno, samo da bi se izognili uvajanju odjemalca.
Potrdite zasebno pot, preden obtožite SSH
Povežite se z odobrenim VPN in uporabite dokumentirano zasebno ime ali naslov cilja. Nato preverite izbrano pot, dovoljenje prehoda in povratno pot do odjemalca. Ime, ki se pravilno razreši, ni dokaz, da naslov gre po želenem tunelu, ker prekrivajoče se lokalne in oddaljene predpone lahko zahtevo pošljejo povsem drugam. To razliko je vredno zapisati v runbook.
Če povezava nikoli ne nastane, potrdite, da strežnik posluša na vmesniku, ki ga pričakujete, in da njegov gostiteljski požarni zid prepušča vir, ki ga v resnici vidi. NAT prehoda lahko ta vir prepiše, zato seznam dovoljenih, napisan za tunelski naslov odjemalca, morda nikoli ne bo ustrezal.
To neskladje je najpogostejša samo povzročena okvara SSH prek VPN.
Berite fazo odpovedi, ne združene napake
Tri faze ustvarijo tri različna sporočila in samo eno od njih govori o poverilnicah.
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
Uporabite točno napako in dnevnik strežnika samega, namesto da bi hkrati ponastavili poverilnice VPN in SSH. Ponastavljanje obojih je način, kako petminutna diagnoza postane dvodnevni incident z identiteto.
Podroben izpis pokaže, do katere faze ste prišli:
ssh -vv [email protected]Ohranite gostiteljske ključe in avtorizacijo nedotaknjene
Preverite gostiteljski ključ po predvidenem procesu zaupanja, še posebej po zamenjavi strežnika. Nepričakovano opozorilo o spremenjenem ključu je prav to sporočilo, ki ga ne smete zavreči samo zato, ker se je VPN povezal, ker zasebni tunel ne naredi cilja stroja, za katerega mislite, da je. Primerjajte prstni odtis z virom, ki mu zaupate neodvisno od povezave.
Na strani strežnika potrdite, da je račun avtoriziran in da se ponuja prav tista metoda preverjanja, ki ste jo nastavili. Ključ, ki obstaja, a se ignorira, je običajno težava z dovoljenji ali konfiguracijo, ne z omrežjem.
Omejite dostop do storitve na potrebne identitete in ohranite avtorizirano pot za obnovitev ob spremembah omrežja.