VPN Gate kaj via propra SoftEther-servilo ne estas la sama afero

Teamo instalas SoftEther-servilon, eksportas konektan agordon, kaj poste iu trovas la saman protokolon en publika dosierujo de VPN Gate kaj demandas, ĉu la kompanio nun funkciigas publikan relajson. La konfuzo estas komprenebla: la kliento aspektas idente, la protokolo estas identa, kaj ambaŭ aperas en la sama speco de konekta listo. La distingo ne estas teknika, ĝi estas operacia. Servilo, kiun vi starigas, apartenas al tiu, kiu starigis ĝin, kaj VPN Gate estas aparta volontula projekto, kiu publikigas proprajn finpunktojn.

Sama kliento, du malsamaj operatoroj

Tri demandoj apartigas la du starigojn, kaj neniun el ili respondas la programaro. Indas skribi ilin antaŭ ol iu komparas klientojn.

La meza vico decidas la plej multajn diskutojn. Sur via propra servilo la kontolisto estas io, kion vi kontrolas, do membreco signifas ion; sur volontula nodo ĉiu dosieruja uzanto estas ebla samaĝulo ĉe la sama finpunkto. Tiun vicon ankaŭ ne eblas dedukti el la kliento, kaj tial du homoj kun identa programaro povas priskribi tute malsamajn retojn.

Legu, kiu publikigis la finpunkton

Komencu ĉe la fonto de la konekta agordo. Dosieruja ero kun volontula gastignomo, rotacia adreso kaj publika listo estas alia objekto ol agordo, kiun via administranto eksportis kun via propra gastignomo kaj atestilo. Se la finpunkto aperas en publika listo, traktu ĝin kiel publika, ĉar ĝuste tion signifas la listo. Nenio pri la protokolo ŝanĝas la respondon.

Dosieruja ero ankaŭ ne estas administra aliro. Povi konektiĝi al nodo diras nenion pri ĝia administra interfaco, kaj provi administrajn akreditaĵojn ĉe volontula gasto estas kaj senefika kaj maldeca. Uzu la konektan metodon, kiun la listo proponas, kaj nenion pli.

Protokolado sekvas la operatoron, ne la protokolon

SoftEther kiel programaro povas protokoli konektojn, kaj la administranto de servilo decidas, kio estas konservata kaj por kiom longe. VPN Gate publikigas siajn proprajn paĝojn pri la volontula modelo kaj pri protokolado kontraŭ misuzo, kaj tiuj paĝoj estas la sola ĝusta deklaro pri tiu projekto. Legi ilin estas malsama ago ol supozi, ke iu ajn SoftEther-bazita servo konservas nenion, kio estas aserto, kiun la programaro ne povas subteni.

Por via propra servilo, la ekvivalenta deklaro venas el via agordo kaj via konserva politiko. Tio povas esti pli da protokolado ol konservas publika nodo, aŭ malpli, kaj ĝi estas via respondeco ĉiukaze. Iu, kiu diras, ke la protokolo garantias anonimecon, priskribas esperon anstataŭ dezajnon.

Publika eliro ne estas membreco en privata reto

La praktika fiasko venas, kiam iu bezonas internan servon kaj ekkaptas senpagan publikan eliron anstataŭ la kompanian pordegon. Publika nodo povas ŝanĝi la adreson, de kiu ŝajnas veni via trafiko. Ĝi ne povas igi vin membro de reto, al kiu vi neniam ricevis aliron, kaj neniu klienta agordo tion ŝanĝas. La atingebla aro estas difinita ĉe la fora flanko, de tiu, kiu funkciigas la pordegon.

Ĉi tie ankaŭ apartenas la sekureca politiko. Trafiko tra nekonata volontula gasto estas submetita al la praktikoj de tiu gasto, kaj la fidodecido estas kategorie malsama ol trafiko tra pordego, kiun via organizo funkciigas kaj revizias. Elekti la senpagan eliron movas la fidon, ĝi ne forigas ĝin.

Decidu, kion vi fakte starigas

Tri demandoj solvas ĝin. Kiu funkciigos la finpunkton? Kiu rajtas konektiĝi al ĝi? Kies protokola kaj konserva politiko validas por la trafiko? Se la respondo al iu el ili estas “kiu ajn trovos ĝin”, la starigo estas publika, kion ajn diras la protokola dosiero.

Skribu la respondojn apud la starigo, inkluzive de la operatoro, la permesitaj uzantoj kaj la konserva politiko. Kiam la sekva persono trovos la saman protokolon en publika dosierujo, tiu noto estas la tuta klarigo, kaj ĝi ŝparas la disputon pri tio, ĉu la kompanio funkciigas relajson.