Тек VPN арқылы қолжетімді HTTPS сайтына SSH жіберуі арқылы жету

Бір машинада бұрыннан мақұлданған VPN қатынасы бар, екінші машинаға дәл бір жеке HTTPS қызметі қажет, ал жергілікті SSH жіберуі бұл алшақтықты екінші машинаға туннель бермей-ақ жаба алады. Жіберу бүкіл желінің орнына бір TCP межесін тасымалдайды, және дәл осы шектеу — мәселенің мәні. Төмендегі бес қадамды ретімен орындаңыз, өйткені әрқайсысы әртүрлі себеппен сәтсіз аяқталады және кейінгі қадам бұрынғы алшақтықты сақтап қала алмайды. Егер қандай да бір алғышарт жетіспесе, бұл құрылым оны шешпейді және бұйрықтарды реттеу еш көмектеспейді.

Бірінші қадам: үш алғышартты растаңыз

Кез келген бұйрық маңызды болмас бұрын үш нәрсе бұрыннан дұрыс болуы керек. Бірінші машинаны жіберу хосты ретінде пайдалануға рұқсат, оған жұмыс істейтін SSH қатынасы және көзделген межені рұқсат ететін сервер саясаты қажет. Файл тасымалдау үшін жасалған SSH тіркелгісінде жіберу өшірілген болуы мүмкін, ал жіберуге рұқсат беретін сервер ол арқылы қай межелерге қол жететінін шектеуі мүмкін. Сынамас бұрын сұраңыз, өйткені әріптесіңіздің жұмыс станциясын келісімсіз секіру нүктесі ретінде пайдалану — бұйрық мінсіз жұмыс істесе де, саясат мәселесі.

Екі бұйрық сол тізімнің техникалық жартысын шешеді. Біріншісі тіркелгі мен кілттің интерактивті сұраусыз жұмыс істейтінін дәлелдейді, ал екіншісі конфигурация файлындағы түсініктемеленген мысалдың орнына нақты сервер саясатын басып шығарады.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Екінші қадам: loopback портын байланыстырып, сессияны тірі ұстаңыз

Клиент қолданбасын іске қосатын машинада жеке қызметке жергілікті жіберуді ашыңыз. Оны жергілікті желіде жарияланбауы үшін loopback-ке анық байланыстырыңыз және ешбір жергілікті қызмет ұстамайтын жоғары порт таңдаңыз. Жұмыс істеп жатқанда сессияны ашық ұстаңыз, өйткені оны жабу тыңдаушыны жабады. ExitOnForwardFailure қабылданбаған байланыстыруды немесе алынған портты жіберусіз қалған сессияның орнына дереу шығуға айналдырады, және дәл осы ақау режимі ең көп уақытты жоғалтады.

Жеке қосылым секіру хосттан жасалады, сондықтан сол хосттың DNS, маршруттары, VPN саясаты және қызметке қатынасы — бәрі жұмыс істеуі керек. SSH сессиясы секіру хостында жоқ қолжетімділікті жасамайды және VPN ешқашан жібермеген маршрутты жөндей алмайды. Тыңдаушыны бұйрықтың үнсіздігіне сенудің орнына шын мәнінде қайда болса, сонда растаңыз.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Үшінші қадам: сокет жергілікті болғанда HTTPS атауын сақтаңыз

https://127.0.0.1:9443/-ке шолу TLS сервер атауын және қолданба өкілеттігін өзгертеді. portal.lab.example үшін берілген сертификат loopback мекенжайына қарсы тексерілмейді, және пайда болған қате жіберу қысқартқысының емес, сынған сертификаттың көрінісін береді. Бұйрық жолының сынағы үшін нақты URL-ды сақтап, тек сокет межесін өзгертіңіз. --connect-to осыны жасайды, ал curl нұсқаулығы төменде пайдаланылатын төрт өрісті пішінді құжаттайды.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

Атау URL-да, TLS қол алысуында және Host тақырыбында қалады, ал TCP қосылымы жергілікті тыңдаушыға барады. Проксисіз опция сынақты конфигурацияланған HTTP проксиі ұстап қалуына жол бермей, осы жіберуде ұстайды, ал сертификат тексеруін қосулы ұстау нәтижені мағыналы етеді.

Төртінші қадам: бір жіберудің нені қамти алмайтынын біліңіз

Бір TCP жіберуі бір межелік портты қамтиды. Екінші хост атауына қайта бағыттайтын, жеке желі ішіндегі хосттан ресурстар жүктейтін немесе басқа портқа жіберетін бетке өзінің жіберуі қажет, және олардың әрқайсысы біріншісіндей саясат тексеруін талап етеді. Браузер жұмыс ағындары өз талаптарын қосады, өйткені браузерге нақты атауды прокси конфигурациясы немесе жергілікті сәйкестендіру арқылы жергілікті портқа жіберу керектігін айту қажет. Сондықтан сәтті бұйрық жолының сынағы браузердің де сәтті болатынын дәлелдемейді, дегенмен жолды дәлелдейді.

UDP, SMB анықтау және доменге кіру TCP жіберуінен мүлдем өтпейді. Егер нақты қажеттілік жалпы желілік қатынас болса, бұл құрылым дұрыс емес құрал, ал қолдау көрсетілетін қашықтан қатынау шлюзі дұрыс таңдау.

Бесінші қадам: тазалап, жазып қойыңыз

Сынақ біткенде сессияны тоқтатып, тыңдаушының кеткенін растаңыз. Егер таңдалған порт бұрыннан алынған болса, нөмірді босату үшін байланысы жоқ жергілікті қызметті тоқтатудың орнына басқа пайдаланылмаған loopback портын таңдап, URL-ды, сынақ бұйрығын және жазбаны бірге жаңартыңыз. Ноутбукта ашық қалдырылған жіберу диагностиканы басқарылмайтын қызметке айналдырады.

Секіру хостты, жіберілген межені, жергілікті портты және бұл келісімді кім мақұлдағанын жазып қойыңыз. Тек біреудің shell тарихында ғана бар жіберу бір қайта жүктеуден кейін қайталанатын тексеріске әкеледі, ал келесі адам үш алғышарттың қайсысы тексерілгенін білмейді.