HTTP-prokurilo, SSH-tunelo aŭ VPN: elektu la ĝustan tavolon

Demandu tri inĝenierojn kiel atingi internan servon kaj vi ricevos tri dezajnojn: retprokurilo, SSH-tunelo aŭ plena VPN. Ĉiuj tri povas meti malproksiman servon en atingon, kaj ĉiuj tri povas igi trafikon ŝajni veni de aliloke. La diferencoj montriĝas poste, kiam la uzata protokolo ne estas tiu, kiun la elektita ilo supozas. Dezajno, kiu trapasas rapidan retumilan kontrolon, kutime malsukcesas ĉe la aplikaĵo, kiu kaŭzis la peton.

Decidu per du faktoj: kiuj protokoloj devas trapasi kaj kiu povas solvi la koncernajn nomojn. Ĉio alia estas prefero.

Prokurilo movas nur tion, kion ĝi komprenas

Retprokurilo analizas la protokolon, por kiu ĝi estis konstruita. La kliento transdonas al ĝi peton kaj ĝi transdonas tiun peton pluen, do aplikaĵo sen prokurila agordo tute ne partoprenas. Por HTTPS la kliento bezonas maldiafan kanalon, kiun la prokurilo liveras per CONNECT anstataŭ legante la peton.

Dinamika SSH-plusendado malfermas lokan pordon, kiu parolas SOCKS, kaj tiu pordo plusendas TCP-fluon al ajna celo, kiun la kliento nomas. Protokoloj konstruitaj sur TCP ĝenerale funkcias tra ĝi. UDP ne, krom se ilo aldonas subtenon eksplice. Loka plusendado estas eĉ pli mallarĝa: unu loka pordo mapita al unu fiksa gastiganto kaj pordo, kiu servas unu konatan servon kaj nenion pli.

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

VPN movas pakaĵojn. Ĉio, kion la kliento enkursigas en la tunelon, trapasas ĝin, inkluzive UDP kaj ICMP, tial ĝi taŭgas por retpostulo, ne por unuopa konekto.

Iu devas solvi la nomon

Kiam la celnomo ekzistas nur en la DNS de la malproksima reto, la maŝino, kiu faras la serĉon, devas vidi tiun zonon. Retprokurilo mem faras la serĉon, do interna nomo funkcias tra ĝi eĉ kiam la tekkomputilo tute ne povas solvi la nomon. SOCKS povas konduti same, sed nur se la kliento plusendas la nomon anstataŭ konekti al adreso, kiun ĝi jam solvis. Tiu elekto estas en la kliento, ne en la servilo.

curl montras la dividon klare: unu flago transdonas la gastigantnomon al la prokurilo, alia unue solvas ĝin loke. Ĉe loka solvado nomo nur interna malsukcesas antaŭ ol oni eĉ tuŝas tunelon, kaj la eraro kulpigas la prokurilon pri tio, kio fakte estis DNS-decida.

VPN prenas la trian vojon instalante la privatan solvilon kaj la serĉdomajnon apud la vojoj. Tio estas oportuna, kaj ĝi kreas konatan iluzion: vojo, kiu ekzistas kun solvilo, kiu ne respondas, aspektas ĝuste kiel morta tunelo, kvankam pakaĵoj atingas la alian flankon.

Kiam la reto permesas nur unu eliron

Multaj entreprenaj retoj permesas elirantajn konektojn nur tra aŭtentikigita retprokurilo. OpenVPN kaj SSH ambaŭ povas esti igitaj funkcii tie, la unua per tuneligo de sia propra transporto tra la prokurilo kaj la dua per prokurila komando, kiu rulas malgrandan CONNECT-helpan programon.

Tuneloj konstruitaj sur TCP postvivas tiun limigon, kaj UDP-bazita VPN ne, kio klarigas tre multajn agordojn, kiuj funkcias hejme kaj malsukcesas en oficejo. Dua kosto facile preteratentigas: TCP-tunelo portata ene de prokurila TCP-konekto nun havas du tavolojn, kiuj resendas, kaj sub perdo tiu paro haltas tiel, kiel neniu tavolo sola produktas.

Ĉenigi perantojn estas alia demando ol elekti tavolon. Aldoni duan prokurilon aŭ Tor ŝanĝas, kiu observas kion, kaj pozicio en la ĉeno decidas, kiu salto vidas la ĉifrotekston.

Ordo gravas pli ol la nombro de saltoj. Ekstera salto rigardas ĉifritan fluon dum interna vidas la klartekston, kiun ĝi portas, do ĉeno estas same privata kiel ĝia malplej zorgema ligo. Miksi protokolojn trans saltoj ne plibonigas tion aŭtomate. Ĝi ĉefe malfaciligas pripensi la fiaskmanierojn.

Falsita adreso ne estas unu el la elektoj

Krei pakaĵojn kun la fontadreso de iu alia atingas nenion utilan: respondoj vojaĝas al la vera posedanto, kaj plej multaj retoj simple forĵetas la trafikon. Peranto necesas ĝuste ĉar la fonto ne povas esti elpensita, kaj tio estas la honesta pravigo por ĉiuj tri dezajnoj.

Ĝi ankaŭ limigas, kion iu ajn el ili povas pretendi. Ŝajni originita de aparta adreso estas demando pri tio, kie tiu adreso estas laŭleĝe asignita kaj kiu rajtas enkursigi ĝin, ne pri tio, kiu ilo povas falsi kaplinion. Se dezajno supozas alie, la supozo fiaskas ĉe la unua provizanto, kiu ĝin filtras. Skribu la supozon, por ke la fiasko estu rekonebla kiam ĝi venos.

Decidu laŭ protokoloj kaj nomoj

Uzu prokurilon kiam unu retkliento bezonas unu retservon kaj havas prokurilajn agordojn. Uzu SSH-tunelon kiam manpleno da konataj TCP-servoj sufiĉas kaj SSH-aliro jam ekzistas. Uzu VPN kiam pluraj aplikaĵoj, ne-TCP-trafiko, privata DNS aŭ reuzebla vojo estas parto de la postulo.

Poste kontrolu per la vera kliento kaj la vera nomo. Ŝuti paĝon tra prokurilo ne instruas al vi ion pri UDP, kaj funkciigi unu ilon tra SOCKS ne instruas al vi ion pri la sistema solvilo. Legu, kiun lokan adreson la procezo ligis kaj kiu solvilo respondis. Tio estas la diferenco inter vojo, kiu funkcias, kaj unu, kiu hazarde funkciis unufoje.