HTTP-проксі, SSH-тунэль ці VPN: абярыце патрэбны ўзровень

Спытайце трох інжынераў, як дабрацца да ўнутранай службы, і атрымаеце тры схемы: вэб-проксі, SSH-тунэль або поўны VPN. Усе тры могуць зрабіць аддаленую службу даступнай, і ўсе тры могуць паказаць трафік так, нібы ён ідзе з іншага месца. Адрозненні выяўляюцца пазней, калі пратакол у рабоце не той, які меркавала абраная прылада. Схема, якая праходзіць хуткую праверку ў браўзеры, звычайна зрываецца на праграме, якая і выклікала запыт.

Рашайце з двух фактаў: якія пратаколы павінны прайсці і хто можа развязаць датычныя імёны. Усё астатняе — перавага.

Проксі пераносіць толькі тое, што разумее

Вэб-проксі разбірае пратакол, для якога быў створаны. Кліент перадае яму запыт, а ён перадае гэты запыт далей, таму праграма без наладкі проксі ўвогуле не ўдзельнічае. Для HTTPS кліенту патрэбен непразрысты канал, і проксі дае яго праз CONNECT, а не праз чытанне запыту.

Дынамічная перадача SSH адкрывае лакальны порт, які размаўляе па SOCKS, і гэты порт перадае TCP-паток на любую мэту, якую назваў кліент. Пратаколы на TCP звычайна працуюць праз яго. UDP — не, калі прылада не дадае падтрымку яўна. Лакальная перадача яшчэ вузейшая: адзін лакальны порт адлюстраваны на адзін фіксаваны хост і порт, што абслугоўвае адну вядомую службу і нічога больш.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN пераносіць пакеты. Усё, што кліент накіроўвае ў тунель, праходзіць праз яго, уключаючы UDP і ICMP, таму ён падыходзіць для патрабавання сеткі, а не аднаго злучэння.

Хтосьці мусіць развязаць імя

Калі мэтавае імя існуе толькі ў DNS аддаленай сеткі, той кампутар, што робіць пошук, мусіць бачыць гэтую зону. Вэб-проксі робіць пошук сам, таму ўнутранае імя працуе праз яго, нават калі ноўтбук не можа развязаць імя зусім. SOCKS можа паводзіць сябе гэтак жа, але толькі калі кліент перадае імя, а не злучаецца з адрасам, які ўжо развязаў. Гэты выбар у кліенце, а не ў серверы.

curl ясна паказвае падзел: адзін сцяг перадае імя хоста проксі, другі спачатку развязвае яго лакальна. Пры лакальным развязанні імя, даступнае толькі ўнутры, зрываецца яшчэ да дотыку да тунелю, і памылка валіць на проксі тое, што было рашэннем DNS.

VPN ідзе трэцім шляхам, усталёўваючы прыватны распазнавальнік і пошукавы дамен побач з маршрутамі. Гэта зручна і стварае знаёмую ілюзію: маршрут, які існуе з распазнавальнікам, што не адказвае, выглядае як мёртвы тунель, хаця пакеты дасягаюць таго боку.

Калі сетка дазваляе толькі адзін выхад

Шмат карпаратыўных сетак дазваляюць знешнія злучэнні толькі праз аўтэнтыфікаваны вэб-проксі. OpenVPN і SSH можна прымусіць там працаваць: першы — тунелюючы свой транспарт праз проксі, другі — праз каманду проксі, якая запускае невялікі памочнік CONNECT.

Тунелі на TCP перажываюць гэтае абмежаванне, а VPN на UDP — не, што тлумачыць мноства канфігурацый, якія працуюць дома і зрываюцца ў офісе. Другі кошт лёгка не заўважыць: TCP-тунель унутры TCP-злучэння праз проксі мае цяпер два ўзроўні, што паўтараюць перадачу, і пры стратах гэтая пара застойваецца так, як не стварае ніводзін узровень асобна.

Ланцуг пасярэднікаў — іншае пытанне, чым выбар узроўню. Даданне другога проксі ці Tor змяняе, хто што назірае, а месца ў ланцугу вырашае, які скок бачыць шыфратэкст.

Парадак важнейшы за колькасць скокаў. Знешні скок назірае за шыфраваным патокам, а ўнутраны бачыць адкрыты тэкст, які той пераносіць, таму ланцуг прыватны настолькі, наколькі прыватнае яго найменш асцярожнае звяно. Змешванне пратаколаў паміж скокамі не паляпшае гэта аўтаматычна. Яно пераважна робіць рэжымы збою цяжэйшымі для разумення.

Падроблены адрас не ўваходзіць у лік варыянтаў

Фарміраванне пакетаў з чужым адрасам крыніцы не дае нічога карыснага: адказы ідуць да сапраўднага ўладальніка, і большасць сетак проста скідвае такі трафік. Пасярэднік патрэбны менавіта таму, што крыніцу нельга выдумаць, і гэта сумленнае абгрунтаванне ўсіх трох схем.

Гэта таксама абмяжоўвае, на што любая з іх можа прэтэндаваць. Выглядаць так, нібы трафік ідзе з пэўнага адраса, — пытанне пра тое, дзе гэты адрас законна прызначаны і хто можа яго маршрутызаваць, а не пра тое, якая прылада можа падмануць загаловак. Калі схема мяркуе іншае, меркаванне рушыцца на першым правайдэры, які яго фільтруе. Запішыце меркаванне, каб збой быў пазнавальны, калі настане.

Вырашайце па пратаколах і імёнах

Бярыце проксі, калі адзіны вэб-кліент мае патрэбу ў адзінай вэб-службе і мае наладкі проксі. Бярыце SSH-тунэль, калі хапае жменькі вядомых TCP-службаў і доступ па SSH ужо ёсць. Бярыце VPN, калі некалькі праграм, не-TCP трафік, прыватны DNS або шлях для шматразовага выкарыстання ўваходзяць у патрабаванне.

Затым праверце сапраўдным кліентам і сапраўдным імем. Загрузка старонкі праз проксі не навучыць вас нічому пра UDP, а запуск адной прылады праз SOCKS — нічому пра сістэмны распазнавальнік. Прачытайце, да якога лакальнага адраса прывязаўся працэс і які распазнавальнік адказаў. Гэта розніца паміж шляхам, які працуе, і тым, які аднойчы выпадкова спрацаваў.