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 не ви учи на нищо за системния резолвер. Прочетете кой локален адрес е завързал процесът и кой резолвер е отговорил. Това е разликата между път, който работи, и такъв, който случайно е проработил веднъж.