Proxy HTTP, twnnel SSH neu VPN: dewiswch y haen iawn

Gofynnwch i dri pheiriannydd sut i gyrraedd gwasanaeth mewnol a chewch dri chynllun: proxy gwe, twnnel SSH neu VPN llawn. Gall y tri roi gwasanaeth o bell o fewn cyrraedd, a gall y tri wneud i draffig ymddangos fel pe bai'n dod o rywle arall. Daw'r gwahaniaethau i'r amlwg yn ddiweddarach, pan nad yw'r protocol sy'n cael ei ddefnyddio yr un y mae'r offeryn a ddewiswyd yn ei dybio. Mae cynllun sy'n pasio gwiriad porwr cyflym yn methu'n rheolaidd ar y rhaglen a ysgogodd y cais.

Penderfynwch o ddau ffaith: pa brotocolau sy'n rhaid croesi, a phwy all ddatrys yr enwau dan sylw. Mae popeth arall yn ddewis personol.

Mae proxy yn symud yn unig yr hyn y mae'n ei ddeall

Mae proxy gwe yn dadansoddi'r protocol y cafodd ei adeiladu ar ei gyfer. Mae'r cleient yn rhoi cais iddo ac mae'n trosglwyddo'r cais ymlaen, felly nid yw rhaglen heb osodiad proxy yn cymryd rhan o gwbl. Ar gyfer HTTPS mae angen sianel afloyw ar y cleient, ac mae'r proxy yn ei darparu drwy CONNECT yn hytrach na darllen y cais.

Mae anfon dynameg SSH yn agor porthladd lleol sy'n siarad SOCKS, ac mae'r porthladd hwnnw'n trosglwyddo ffrwd TCP i unrhyw gyrchfan a enwir gan y cleient. Mae protocolau wedi'u hadeiladu ar TCP fel arfer yn gweithio drwyddo. Nid yw UDP yn gwneud, oni bai bod offeryn yn ychwanegu cymorth yn benodol. Mae anfon lleol yn gulach fyth: un porthladd lleol wedi'i fapio i un gwesteiwr a phorthladd sefydlog, sy'n gwasanaethu un gwasanaeth hysbys a dim mwy.

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

Mae VPN yn symud pecynnau. Mae popeth y mae'r cleient yn ei lwybr i'r twnnel yn croesi, gan gynnwys UDP ac ICMP, a dyna pam mae'n addas i ofyniad rhwydwaith yn hytrach na chysylltiad sengl.

Rhaid i rywun ddatrys yr enw

Pan fo'r enw targed yn bodoli dim ond yn DNS y rhwydwaith pell, rhaid i'r blwch sy'n gwneud yr edrychiad allu gweld y parth hwnnw. Mae proxy gwe yn gwneud yr edrychiad ei hun, felly mae enw mewnol yn gweithio drwyddo hyd yn oed pan na all y gliniadur ddatrys yr enw o gwbl. Gall SOCKS ymddwyn yr un ffordd, ond dim ond os yw'r cleient yn anfon yr enw ymlaen yn lle cysylltu â chyfeiriad y mae eisoes wedi'i ddatrys. Mae'r dewis hwnnw yn y cleient, nid yn y gweinydd.

Mae curl yn dangos y rhaniad yn glir: mae un baner yn trosglwyddo enw'r gwesteiwr i'r proxy, mae un arall yn ei ddatrys yn lleol gyntaf. Gyda datrysiad lleol mae enw mewnol yn methu cyn cyffwrdd unrhyw dwnnel, ac mae'r gwall yn beio'r proxy am rywbeth a oedd mewn gwirionedd yn benderfyniad DNS.

Mae VPN yn cymryd y trydydd llwybr drwy osod y datryswr preifat a'r parth chwilio wrth ymyl y llwybrau. Mae hynny'n gyfleus, ac mae'n creu rhith cyfarwydd: mae llwybr sy'n bodoli gyda datryswr nad yw'n ateb yn edrych yn union fel twnnel marw, er bod pecynnau'n cyrraedd yr ochr bell.

Pan fo'r rhwydwaith yn caniatáu un allanfa yn unig

Mae llawer o rwydweithiau corfforaethol yn caniatáu cysylltiadau allan yn unig drwy proxy gwe dilys. OpenVPN a SSH y gellir eu rhoi i weithio yno: yr un cyntaf drwy dwnelu ei drafnidiaeth ei hun drwy'r proxy a'r ail drwy orchymyn proxy sy'n rhedeg cynorthwyydd CONNECT bach.

Mae twneli wedi'u hadeiladu ar TCP yn goroesi'r cyfyngiad hwnnw, ac nid yw VPN ar sail UDP yn gwneud, sy'n esbonio llawer o ffyrddiadau sy'n gweithio gartref ac yn methu mewn swyddfa. Mae ail gost yn hawdd ei cholli: mae gan dwnnel TCP a gludir o fewn cysylltiad TCP trwy proxy ddwy haen bellach yn ail-drosglwyddo, ac o dan golled mae'r pâr hwnnw'n stopio mewn ffordd nad yw'r un haen yn ei chynhyrchu ar ei phen ei hun.

Mae cadwyno cyfryngwyr yn gwestiwn gwahanol i ddewis haen. Mae ychwanegu ail proxy neu Tor yn newid pwy sy'n arsylwi beth, ac mae safle yn y gadwyn yn penderfynu pa naid sy'n gweld y testun seiffredig.

Mae trefn yn bwysicach na nifer y naidiau. Mae naid allanol yn gwylio ffrwd seiffredig tra mae un mewnol yn gweld y testun plaen y mae'n ei chario, felly dim ond mor breifat â'i chysylltiad lleiaf gofalus yw cadwyn. Nid yw cymysgu protocolau ar draws naidiau yn gwella hynny'n awtomatig. Yn bennaf mae'n gwneud y moddau methu yn anoddach i'w rhesymu.

Nid yw cyfeiriad ffug yn un o'r opsiynau

Nid yw creu pecynnau â chyfeiriad ffynhonnell rhywun arall yn cyflawni dim defnyddiol: mae atebion yn teithio i'r gwir berchennog, ac mae'r rhan fwyaf o rwydweithiau'n gollwng y traffig yn llwyr. Mae angen cyfryngwr yn union oherwydd na ellir dyfeisio'r ffynhonnell, a dyna'r cyfiawnhad gonest dros y tri chynllun.

Mae hefyd yn cyfyngu ar yr hyn y gall unrhyw un ohonynt ei honni. Mae ymddangos fel pe bai'n tarddu o gyfeiriad penodol yn gwestiwn am ble mae'r cyfeiriad hwnnw wedi'i neilltuo'n gyfreithlon a phwy all ei lwybro, nid am ba offeryn all ffugio pennawd. Os yw cynllun yn tybio fel arall, mae'r dybiaeth yn methu yn y darparwr cyntaf sy'n ei hidlo. Ysgrifennwch y dybiaeth fel bod y methiant yn adnabyddadwy pan ddaw.

Penderfynwch yn ôl protocolau ac enwau

Estynnwch am proxy pan fo un cleient gwe angen un gwasanaeth gwe ac mae ganddo osodiadau proxy. Estynnwch am dwnnel SSH pan fo llond llaw o wasanaethau TCP hysbys yn ddigon ac mae mynediad SSH eisoes yn bodoli. Estynnwch am VPN pan fo sawl rhaglen, traffig nad yw'n TCP, DNS preifat neu lwybr ailddefnyddiadwy yn rhan o'r gofyniad.

Yna gwiriwch gyda'r cleient go iawn a'r enw go iawn. Nid yw llwytho tudalen drwy proxy yn dysgu dim i chi am UDP, ac nid yw cael un offeryn i weithio dros SOCKS yn dysgu dim i chi am ddatryswr y system. Darllenwch pa gyfeiriad lleol y rhwymodd y broses a pha ddatryswr a atebodd. Dyna'r gwahaniaeth rhwng llwybr sy'n gweithio a llwybr a fu'n gweithio unwaith drwy lwc.