Удаљени SSH преко VPN-а: шта тунел не чини
VPN чини SSH сервер доступним и ништа више. Три услова одлучују да ли се уклапа, а фаза квара показује који је слој крив.
VPN даје SSH серверу приватни пут и уклања потребу за јавним слушаоцем на порту 22. Он не проверава идентитет хоста, не ауторизује корисника и не одлучује који се рачуни смеју пријавити. То остаје посао SSH-а. Да ли је VPN прави начин да се дође до сервера, зависи од три услова, а тунел је само један од могућих одговора.
Шта тунел мења, а шта SSH још одлучује
Тунел мења доступност: које адресе се могу достићи и одакле. Не мења оно што се дешава након што се TCP веза успостави, када сервер представи кључ хоста и затражи идентитет корисника.
Држите два слоја одвојено у глави и у документацији. Пријава на VPN доказује коме је дозвољено коришћење мреже. Не говори ништа о томе који рачуни постоје на циљу и није дозвола за пријаву на сваку доступну машину.
Начини квара су такође одвојени, и управо то раздвајање чини корисним током инцидента.
Три услова која одлучују о моделу приступа
Прво, мора ли сервер бити доступан људима изван ваше мреже? Ако не, приватни пут плус бастион или меш је мањи дизајн. Друго, може ли популација клијената заиста да покрене VPN клијент, укључујући оне на управљаним уређајима са ограничењима?
Треће, треба ли вам контрола по сервису или по кориснику? VPN даје мрежни домет; SSH даје приступ рачуну. Ако је захтев да извођач достигне један хост и ништа друго, то је захтев за ауторизацију и сам тунел га не може изразити.
Одговорите на та три и модел се сам бира. Прескочите их и завршавате тако што SSH излажете јавно како бисте избегли увођење клијента.
Потврдите приватни пут пре него што оптужите SSH
Повежите се на одобрени VPN и употребите документовано приватно име или адресу циља. Затим проверите изабрану руту, дозволу гејтвеја и повратни пут до клијента. Име које се исправно разрешава није доказ да адреса иде жељеним тунелом, јер преклапајући локални и удаљени префикси могу послати захтев сасвим другде. Ту разлику вреди записати у приручник.
Ако се веза никада не успостави, потврдите да сервер слуша на интерфејсу коме се надате и да његов фајервол хоста пропушта извор који заиста види. NAT гејтвеја може преписати тај извор, па листа дозвољених написана за тунелску адресу клијента можда никада неће одговарати.
Та неусклађеност је најчешћи самонанети SSH квар преко VPN-а.
Читајте фазу квара, а не спојену грешку
Три фазе дају три различите поруке, а само једна од њих говори о акредитивима.
| 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 |
Употребите тачну грешку и властити дневник сервера уместо да ресетујете и VPN и SSH акредитиве заједно. Ресетовање оба је начин на који петоминутна дијагноза постаје дводневни инцидент са идентитетом.
Детаљни излаз показује до које фазе сте стигли:
ssh -vv [email protected]Сачувајте кључеве хоста и ауторизацију нетакнутима
Проверите кључ хоста кроз предвиђени процес поверења, посебно након замене сервера. Неочекивано упозорење о промењеном кључу је управо порука коју не смете одбацити само зато што се VPN повезао, јер приватни тунел не чини одредиште машином за коју мислите да јесте. Проверите отисак према извору коме верујете независно од везе.
На страни сервера потврдите да је рачун ауторизован и да се нуди управо онај метод аутентификације који сте подесили. Кључ који постоји али се игнорише обично је проблем дозвола или конфигурације, а не мреже.
Ограничите приступ сервису на потребне идентитете и држите ауторизован пут опоравка за мрежне промене.