Аддалены SSH праз VPN: чаго тунель не робіць
VPN робіць SSH-сервер дасяжным і нічога больш. Тры ўмовы вызначаюць, ці падыходзіць, а стадыя збою паказвае, які ўзровень вінаваты.
VPN дае SSH-серверу прыватны шлях і прыбірае патрэбу ў публічным слухачы на порце 22. Ён не аўтэнтыфікуе хост, не аўтарызуе карыстальніка і не вырашае, якія ўліковыя запісы могуць уваходзіць. Гэта застаецца справай SSH. Ці VPN — правільны спосаб дабрацца да сервера, залежыць ад трох умоў, і тунель — толькі адзін з магчымых адказаў.
Што змяняе тунель і што SSH па-ранейшаму вырашае
Тунель змяняе дасяжнасць: якія адрасы можна дасягнуць і адкуль. Ён не змяняе таго, што адбываецца пасля таго, як TCP-злучэнне ўсталявалася, дзе сервер паказвае ключ хоста і пытае ідэнтычнасць карыстальніка.
Трымайце два ўзроўні асобна ў галаве і ў дакументацыі. Уваход у VPN даказвае, хто можа карыстацца сеткай. Ён нічога не кажа пра тое, якія ўліковыя запісы існуюць на мэце, і гэта не дазвол уваходзіць на кожную дасяжную машыну.
Рэжымы збою таксама асобныя, і менавіта гэта робіць падзел карысным падчас інцыдэнту.
Тры ўмовы, якія вызначаюць мадэль доступу
Па-першае, ці павінен сервер быць дасяжным для людзей па-за вашай сеткай? Калі не, прыватны шлях плюс бастыён або mesh — меншы дызайн. Па-другое, ці можа кліенцкая супольнасць насамрэч запусціць VPN-кліент, уключаючы тых, хто на кіраваных прыладах з абмежаваннямі?
Па-трэцяе, вам патрэбен кантроль па службе ці па карыстальніку? VPN дае сеткавы доступ; SSH дае доступ да ўліковага запісу. Калі патрабаванне ў тым, каб падрадчык дасягнуў аднаго хоста і нічога іншага, гэта патрабаванне аўтарызацыі, і адзін тунель не можа яго выразіць.
Адказце на гэтыя тры — і мадэль выбера сябе. Прапусціце іх — і вы выставіце SSH публічна, каб пазбегнуць разгортвання кліента.
Пацвердзіце прыватны шлях, перш чым вінаваціць SSH
Падключыце ўхвалены VPN і выкарыстайце дакументаванае прыватнае імя або адрас мэты. Затым праверце выбраны маршрут, дазвол шлюза і зваротны шлях да кліента. Імя, якое правільна развязаецца, не з'яўляецца доказам таго, што адрас ідзе праз патрэбны тунель, бо перакрыжаваныя лакальныя і аддаленыя прэфіксы могуць адправіць запыт зусім у іншае месца. Гэта адрозненне варта запісаць у runbook.
Калі злучэнне ніколі не ўсталёўваецца, пераканайцеся, што сервер слухае на чаканым інтэрфейсе і што яго хост-фаервол дазваляе крыніцу, якую ён насамрэч бачыць. 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 падключыўся, бо прыватны тунель не робіць прызначэнне той машынай, якую вы думаеце. Праверце адбітак па крыніцы, якой вы давяраеце незалежна ад злучэння.
На баку сервера пераканайцеся, што ўліковы запіс аўтарызаваны і што менавіта наладжаны вамі метад аўтэнтыфікацыі прапануецца. Ключ, які ёсць, але ігнаруецца, звычайна з'яўляецца праблемай правоў або канфігурацыі, а не сеткі.
Абмяжуйце доступ да службаў патрэбнымі ідэнтычнасцямі і захавайце аўтарызаваны шлях аднаўлення для змен у сетцы.