HTTP starpniekserveris, SSH tunelis vai VPN: izvēlieties pareizo slāni
Starpniekserveris, SSH tunelis un VPN pārvadā atšķirīgu trafiku. Saskaņojiet slāni ar protokoliem un vārdu atrisināšanu, kas nepieciešama jūsu uzdevumam, un pēc tam pārbaudiet ceļu.
Pajautājiet trim inženieriem, kā nokļūt līdz iekšējam pakalpojumam, un saņemsiet trīs projektus: tīmekļa starpniekserveri, SSH tuneli vai pilnu VPN. Visi trīs var padarīt attālinātu pakalpojumu sasniedzamu, un visi trīs var likt trafikam izskatīties tā, it kā tas nāktu no citurienes. Atšķirības parādās vēlāk, kad izmantotais protokols nav tas, ko pieņem izvēlētais rīks. Projekts, kas iztur ātru pārlūka pārbaudi, bieži cieš neveiksmi tajā lietotnē, kas rosināja pieprasījumu.
Izlemiet, pamatojoties uz diviem faktiem: kuri protokoli ir jāšķērso un kas var atrisināt attiecīgos vārdus. Viss pārējais ir izvēle.
Starpniekserveris pārvieto tikai to, ko saprot
Tīmekļa starpniekserveris analizē protokolu, kuram tas tika būvēts. Klients tam nodod pieprasījumu, un tas nodod pieprasījumu tālāk, tāpēc lietotne bez starpniekservera iestatījuma vispār nepiedalās. HTTPS gadījumā klientam nepieciešams necaurspīdīgs kanāls, ko starpniekserveris nodrošina ar CONNECT, nevis lasot pieprasījumu.
SSH dinamiskā pāradresācija atver vietējo portu, kas runā SOCKS, un šis ports pārsūta TCP plūsmu uz jebkuru galamērķi, ko klients nosauc. Uz TCP balstīti protokoli parasti darbojas caur to. UDP ne, ja vien rīks nav skaidri pievienojis atbalstu. Vietējā pāradresācija ir vēl šaurāka: viens vietējais ports kartēts uz vienu fiksētu resursdatoru un portu, kas apkalpo vienu zināmu pakalpojumu un neko vairāk.
ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastionVPN pārvieto paketes. Viss, ko klients novirza tunelī, tam iet cauri, tostarp UDP un ICMP, tāpēc tas atbilst tīkla prasībai, nevis vienam savienojumam.
Kādam ir jāatrisina vārds
Kad mērķa vārds pastāv tikai attālinātā tīkla DNS, mašīnai, kas veic meklēšanu, ir jāredz šī zona. Tīmekļa starpniekserveris meklēšanu veic pats, tāpēc iekšējs vārds darbojas caur to arī tad, kad klēpjdators vārdu nemaz nevar atrisināt. SOCKS var uzvesties tāpat, bet tikai tad, ja klients pārsūta vārdu, nevis pieslēdzas adresei, ko jau ir atrisinājis. Šī izvēle ir klientā, nevis serverī.
curl skaidri parāda šķīrumu: viens karodziņš nodod resursdatora vārdu starpniekserverim, cits vispirms to atrisina lokāli. Ar lokālu atrisināšanu tikai iekšējs vārds cieš neveiksmi vēl pirms jebkura tuneļa aizskaršanas, un kļūda vaino starpniekserveri tajā, kas patiesībā bija DNS lēmums.
VPN izvēlas trešo ceļu: blakus maršrutiem instalē privāto atrisinātāju un meklēšanas domēnu. Tas ir ērti, un tas rada pazīstamu ilūziju: maršruts, kas pastāv ar atrisinātāju, kurš neatbild, izskatās tieši kā miris tunelis, lai gan paketes sasniedz otru pusi.
Kad tīkls atļauj tikai vienu izeju
Daudzi uzņēmumu tīkli atļauj izejošos savienojumus tikai caur autentificētu tīmekļa starpniekserveri. OpenVPN un SSH abus tur var dabūt darboties: pirmais tunelē savu transportu caur starpniekserveri, otrais izmanto starpniekservera komandu, kas palaiž nelielu CONNECT palīgu.
Uz TCP balstīti tuneļi iztur šo ierobežojumu, un uz UDP balstīts VPN ne, kas izskaidro ļoti daudzas konfigurācijas, kas darbojas mājās un cieš neveiksmi birojā. Otru izmaksu ir viegli nepamanīt: TCP tunelim, kas nests TCP savienojumā caur starpniekserveri, tagad ir divi slāņi, kas pārsūta no jauna, un zudumu apstākļos šis pāris iestrēgst tā, kā neviens slānis viens pats nerada.
Starpnieku ķēdēšana ir cits jautājums nekā slāņa izvēle. Otra starpniekservera vai Tor pievienošana maina to, kas ko novēro, un pozīcija ķēdē nosaka, kurš lēciens redz šifrēto tekstu.
Secība ir svarīgāka par lēcienu skaitu. Ārējais lēciens novēro šifrētu plūsmu, bet iekšējais redz vienkāršo tekstu, ko tā nes, tāpēc ķēde ir tik privāta, cik tās vismazāk uzmanīgais posms. Protokolu sajaukšana starp lēcieniem to automātiski neuzlabo. Tas galvenokārt padara atteices režīmus grūtāk pārdomājamus.
Viltota adrese nav viens no variantiem
Pakešu veidošana ar svešu avota adresi neko lietderīgu nesasniedz: atbildes ceļo pie īstā īpašnieka, un lielākā daļa tīklu vienkārši izmet trafiku. Starpnieks ir nepieciešams tieši tāpēc, ka avotu nevar izdomāt, un tas ir godīgais visu trīs projektu pamatojums.
Tas arī ierobežo, ko katrs no tiem drīkst apgalvot. Izskatīties tā, it kā trafiks nāktu no noteiktas adreses, ir jautājums par to, kur šī adrese ir likumīgi piešķirta un kas to drīkst maršrutēt, nevis par to, kurš rīks spēj viltot galveni. Ja projekts pieņem pretējo, pieņēmums sabrūk pie pirmā pakalpojumu sniedzēja, kas to filtrē. Pierakstiet pieņēmumu, lai atteice būtu atpazīstama, kad tā pienāk.
Izlemiet pēc protokoliem un vārdiem
Izvēlieties starpniekserveri, kad vienam tīmekļa klientam nepieciešams viens tīmekļa pakalpojums un tam ir starpniekservera iestatījumi. Izvēlieties SSH tuneli, kad pietiek ar dažiem zināmiem TCP pakalpojumiem un SSH piekļuve jau pastāv. Izvēlieties VPN, kad vairākas lietotnes, ne TCP trafiks, privāts DNS vai atkārtoti lietojams ceļš ir prasības daļa.
Pēc tam pārbaudiet ar īsto klientu un īsto vārdu. Lapas ielāde caur starpniekserveri neiemāca neko par UDP, un viena rīka darbināšana caur SOCKS neiemāca neko par sistēmas atrisinātāju. Izlasiet, ar kuru vietējo adresi process saistījās un kurš atrisinātājs atbildēja. Tā ir atšķirība starp ceļu, kas darbojas, un ceļu, kas reiz nejauši darbojās.