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