HTTP tarpinis serveris, SSH tunelis ar VPN: pasirinkite tinkamą sluoksnį

Paklauskite trijų inžinierių, kaip pasiekti vidinę paslaugą, ir gausite tris projektus: žiniatinklio tarpinį serverį, SSH tunelį arba visą VPN. Visi trys gali padaryti nuotolinę paslaugą pasiekiamą, ir visi trys gali parodyti srautą taip, tarsi jis ateitų iš kitur. Skirtumai paaiškėja vėliau, kai naudojamas protokolas nėra tas, kurį numato pasirinktas įrankis. Projektas, kuris praeina greitą naršyklės patikrą, dažnai nepavyksta toje programoje, kuri paskatino užklausą.

Spręskite pagal du faktus: kurie protokolai turi praeiti ir kas gali išspręsti susijusius vardus. Visa kita yra pasirinkimas.

Tarpinis serveris perkelia tik tai, ką supranta

Žiniatinklio tarpinis serveris analizuoja protokolą, kuriam buvo sukurtas. Klientas jam perduoda užklausą, o jis perduoda ją toliau, todėl programa be tarpinio serverio nustatymo visiškai nedalyvauja. HTTPS atveju klientui reikia nepermatomo kanalo, kurį tarpinis serveris suteikia per CONNECT, o ne skaitydamas užklausą.

SSH dinaminis persiuntimas atidaro vietinį prievadą, kuris kalba SOCKS, ir tas prievadas persiunčia TCP srautą į bet kurią paskirties vietą, kurią nurodo klientas. TCP pagrindu sukurti protokolai paprastai veikia per jį. UDP ne, nebent įrankis aiškiai prideda palaikymą. Vietinis persiuntimas dar siauresnis: vienas vietinis prievadas susietas su vienu fiksuotu mazgu ir prievadu, kuris aptarnauja vieną žinomą paslaugą ir nieko daugiau.

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

VPN perkelia paketus. Viskas, ką klientas nukreipia į tunelį, praeina per jį, įskaitant UDP ir ICMP, todėl jis tinka tinklo reikalavimui, o ne vienam ryšiui.

Kažkas turi išspręsti vardą

Kai tikslinis vardas egzistuoja tik nuotolinio tinklo DNS, mašina, kuri atlieka paiešką, turi matyti tą zoną. Žiniatinklio tarpinis serveris paiešką atlieka pats, todėl vidinis vardas veikia per jį net tada, kai nešiojamasis kompiuteris visiškai negali išspręsti vardo. SOCKS gali elgtis taip pat, bet tik jei klientas perduoda vardą, o ne jungiasi prie adreso, kurį jau išsprendė. Šis pasirinkimas yra kliente, o ne serveryje.

curl aiškiai parodo atskyrimą: viena vėliavėlė perduoda mazgo vardą tarpiniam serveriui, kita pirmiausia išsprendžia jį vietoje. Sprendžiant vietoje, tik vidinis vardas nepavyksta dar nepalietus jokio tunelio, o klaida kaltina tarpinį serverį dėl to, kas iš tikrųjų buvo DNS sprendimas.

VPN pasirenka trečią kelią: šalia maršrutų įdiegia privatų sprendiklį ir paieškos domeną. Tai patogu, ir tai sukuria pažįstamą iliuziją: maršrutas, kuris egzistuoja su sprendikliu, kuris neatsako, atrodo lygiai kaip negyvas tunelis, nors paketai pasiekia kitą pusę.

Kai tinklas leidžia tik vieną išėjimą

Daugelis įmonių tinklų išorinius ryšius leidžia tik per autentifikuotą žiniatinklio tarpinį serverį. OpenVPN ir SSH abu galima ten paleisti: pirmasis tuneliuoja savo transportą per tarpinį serverį, antrasis naudoja tarpinio serverio komandą, kuri paleidžia mažą CONNECT pagalbininką.

TCP pagrindu sukurti tuneliai atlaiko šį apribojimą, o UDP pagrindu veikiantis VPN ne, todėl daug konfigūracijų veikia namuose ir nepavyksta biure. Antrą kainą lengva nepastebėti: TCP tunelis, nešamas TCP ryšyje per tarpinį serverį, dabar turi du sluoksnius, kurie persiunčia iš naujo, o esant nuostoliams ta pora sustoja taip, kaip nė vienas sluoksnis vienas to nesukuria.

Tarpininkų grandinimas yra kitas klausimas nei sluoksnio pasirinkimas. Antro tarpinio serverio ar Tor pridėjimas keičia, kas ką stebi, o vieta grandinėje nusprendžia, kuri šuolis mato šifruotą tekstą.

Tvarka svarbesnė už šuolių skaičių. Išorinis šuolis stebi šifruotą srautą, o vidinis mato paprastą tekstą, kurį jis neša, todėl grandinė yra tokia privati, kokia yra jos mažiausiai atidi grandis. Protokolų maišymas tarp šuolių to automatiškai nepagerina. Jis labiausiai apsunkina gedimų režimų apmąstymą.

Sufalsifikuotas adresas nėra vienas iš variantų

Paketų kūrimas su svetimu šaltinio adresu nieko naudingo nepasiekia: atsakymai keliauja tikrajam savininkui, o dauguma tinklų tiesiog numeta srautą. Tarpininkas reikalingas būtent todėl, kad šaltinio neįmanoma išgalvoti, ir tai yra sąžiningas visų trijų projektų pagrindimas.

Tai taip pat riboja, ką kiekvienas jų gali teigti. Atrodyti, kad srautas kyla iš konkretaus adreso, yra klausimas apie tai, kur tas adresas teisėtai priskirtas ir kas gali jį maršrutizuoti, o ne apie tai, kuris įrankis gali suklastoti antraštę. Jei projektas daro priešingą prielaidą, ji žlunga pas pirmą tiekėją, kuris ją filtruoja. Užrašykite prielaidą, kad gedimas būtų atpažįstamas, kai ateis.

Spręskite pagal protokolus ir vardus

Rinkitės tarpinį serverį, kai vienam žiniatinklio klientui reikia vienos žiniatinklio paslaugos ir jis turi tarpinio serverio nustatymus. Rinkitės SSH tunelį, kai pakanka kelių žinomų TCP paslaugų ir SSH prieiga jau yra. Rinkitės VPN, kai kelios programos, ne TCP srautas, privatus DNS ar daugkartinio naudojimo kelias yra reikalavimo dalis.

Tada patikrinkite tikru klientu ir tikru vardu. Puslapio įkėlimas per tarpinį serverį nieko neišmoko apie UDP, o vieno įrankio paleidimas per SOCKS nieko neišmoko apie sistemos sprendiklį. Perskaitykite, su kuriuo vietiniu adresu procesas susijungė ir kuris sprendiklis atsakė. Tai skirtumas tarp kelio, kuris veikia, ir kelio, kuris kartą veikė atsitiktinai.