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 споја сада има два слоја која поново преносе, а под губицима тај пар стане на начин који ниједан слој сам не производи.

Ланчано повезивање посредника је друго питање од бирања слоја. Додавање другог проксија или Тора мења ко шта посматра, а положај у ланцу одлучује који скок види шифрат.

Редослед је важнији од броја скокова. Спољашњи скок гледа шифровани ток док унутрашњи види отворени текст који носи, па је ланац приватан само колико и његова најненажнија карика. Мешање протокола између скокова то не побољшава аутоматски. Углавном само отежава размишљање о начинима отказа.

Лажна адреса није једна од опција

Прављење пакета са туђом изворном адресом не постиже ништа корисно: одговори иду правом власнику, а већина мрежа једноставно одбаци саобраћај. Посредник је потребан управо зато што се извор не може измислити, и то је поштено оправдање за сва три решења.

То уједно ограничава шта било које од њих може да тврди. Изгледати као да потиче са одређене адресе питање је о томе где је та адреса легитимно додељена и ко њоме може да рутује, а не о томе који алат уме да фалсификује заглавље. Ако решење претпоставља другачије, претпоставка пада код првог провајдера који је филтрира. Запишите претпоставку да отказ буде препознатљив када дође.

Одлучите по протоколима и именима

Посегните за проксијем када једном веб клијенту треба један веб сервис и има прокси подешавања. Посегните за SSH тунелом када је неколико познатих TCP сервиса довољно и SSH приступ већ постоји. Посегните за VPN-ом када су део захтева више апликација, саобраћај који није TCP, приватни DNS или путања која се може поново користити.

Затим проверите правим клијентом и правим именом. Учитавање странице кроз прокси не учи вас ничему о UDP-у, а покретање једног алата кроз SOCKS не учи вас ничему о системском резолверу. Прочитајте коју је локалну адресу процес везао и који је резолвер одговорио. То је разлика између путање која ради и оне која је случајно прорадила једном.