Domajna frontado ne estas VPN: du nomoj, unu peto

La du teknikoj estas arĥivitaj kune ĉar ambaŭ implikas peranton kaj ambaŭ sonas kiel kaŝado. Ili funkcias sur malsamaj objektoj. Domajna frontado temas pri tio, kiu nomo aperas en kiu tavolo de unu HTTPS-peto. VPN temas pri tio, kiuj pakoj iras apartan vojon al kunulo. Nomi frontadon speco de VPN kondukas al dezajnoj, kiuj ne povas funkcii, kaj al revizioj, kiuj demandas la malĝustan demandon.

Du nomoj, du tavoloj

TLS-konekto povas porti servilan nomon en sia manpremo. Post kiam la konekto ekzistas, la HTTP-peto identigas la aŭtoritaton, kiun ĝi volas, kutime en la kaplinio Host. Tiuj estas du kampoj legitaj en du malsamaj momentoj de du malsamaj pecoj de programaro.

Domajna frontado ekspluatas diferencon inter la unuaj du, tiel ke frontada servo akceptas la konekton kaj poste enkursigas la peton aliloken. Ĝi funkcias nur tie, kie tiu servo pretas enkursigi ĝin, kio estas demando pri politiko de provizanto, ne pri protokola artifiko.

Frontado dependas de la provizanto, ne de la tekniko

Kiel limigita ekzemplo, la gvidilo Front Door FAQ de Azure dokumentas protektojn kontraŭ domajna frontado. Ĝi priskribas permesitan malkongruon por domajnoj ene de la sama abono kaj agorditaj vojoj, kaj respondon 421 Misdirected Request kiam la protekto kontraŭ malkongruo blokas peton.

Tiu sola dokumentita politiko nuligas ambaŭ sloganojn samtempe. Ne ĉiu paro de malsamaj nomoj funkcias, kaj ankaŭ ne ĉiu malkongruo estas malpermesita. Aliaj servoj havas siajn proprajn kontrolojn, siajn proprajn postulojn pri deplojo kaj siajn proprajn erarkodojn.

Ĝi ankaŭ ne estas instrukcio por ĉirkaŭiri la limigojn de alia reto. Legi la enkursigajn regulojn de provizanto por kompreni, kion ĝi permesas, estas arkitektura laboro; trakti tiujn regulojn kiel ĉirkaŭiran recepton estas alia agado kun aliaj konsekvencoj. Tenu tiujn du agadojn aparte en la dokumento, kiun vi skribas. La dua estas tio, kio kaŭzas, ke dezajno estas malakceptita en revizio.

Kion VPN efektive elektas

En reta VPN, enkursigo kaj platforma politiko elektas internan trafikon por tunelo al kunulo. Depende de la aranĝo tio povas kovri plurajn aplikojn aŭ difinitan subaron, kaj ĝi povas porti protokolojn, kiuj tute ne havas HTTP-peton.

Frontado faras neniom da tio. Aranĝi unu HTTPS-peton tra frontada servo ne instalas privatan retan vojon, ne portas arbitrajn UDP-aplikojn, kaj ne igas ĉiun programon sur la aparato uzi la servon. Se vi bezonas tiun kovron, vi bezonas prokuran servilon aŭ tunelon, ne nomartifikon.

Tial la du estas konfuzitaj en revizio: ambaŭ estas priskribitaj kiel perantoj, kaj ambaŭ aperas en dokumentoj pri aliro. La interfaco, kiun ĉiu proponas, estas tute malsama, kaj nur unu el ili estas reta vojo.

Videbleco ne estas duuma

Ankaŭ la komparo ne estas simple kaŝita kontraŭ videbla. DNS-demandoj, celadresoj, manpremaj trajtoj, pakgrandoj kaj tempo ĉiuj restas observeblaj por iu, kiu estas poziciita por vidi ilin, kaj tion, kion tiu observanto lernas, dependas de kie ĝi sidas.

Aplikaj datumoj ankaŭ videblas ĉe la finpunktoj, kiuj finigas ilin. Frontada servo, kiu enkursigas vian peton, estas unu el tiuj finpunktoj, kaj VPN-kunulo estas alia. Neniu el la du aranĝoj igas la enhavon netransparenta por la partio, kiu devas legi ĝin por servi vin.

Desegnu la tri skatolojn

Por arkitektura revizio, desegnu la TLS-finputon, la HTTP-enkursigan servon kaj la finan aplikon kiel tri apartajn skatolojn, kaj poste desegnu ajnan VPN-kunulon aliloke denove. La loko, kiu elektas retan celon, kaj la loko, kiu transportas pakojn de privata reto, ne devas esti la sama sistemo, kaj kutime ne estas.

Post kiam la skatoloj estas apartaj, la demandoj iĝas respondeblaj: kiujn nomojn ĉi tiu provizanto akceptas, kiuj protokoloj bezonas transporton, kaj kiu partio povas vidi kion. Diagramo, kiu kunfandas ilin, produktas dezajnon, kiun neniu povas efektivigi, kaj revizion, kiu disputas pri vortprovizo.