Kial nomo de VPN-adaptilo povas kaŝi alian protokolon
La etikedo apud adaptilo priskribas la programaron, kiu kreis ĝin, ne la pakaĵojn en la reto. Kontrolu la klienton, la profilon kaj la samtavolanon antaŭ ol elekti solvon.
La etikedo apud VPN-adaptilo priskribas la programaron, kiu kreis la interfacon, kaj tio estas unu tavolo super la pakaĵoj, kiuj efektive trairas la reton. Kromprogramo povas montri adaptilon, kies nomo reflektas la propran klasifikon de la kromprogramo anstataŭ la enkapsuligon en la reto. Legi la klienton, la profilon kaj la samtavolanon respondas tion, kion la nomo ne povas respondi. Du konektoj, kiuj en agorda menuo aspektas identaj, povas konduti tute malsame en registraĵo.
La nomo venas de la provizanto, ne de la reto
Windows difinas mallongan liston de konektotipoj por siaj enkonstruitaj VPN-klientoj, kaj produktoj de triaj partioj instalas sian propran stakon apud ili. La adaptilon, kiu aperas en la retlisto, kreas tiu pelilo, kiu posedas la konekton, do ĝia nomo estas pruvo pri la pelilo, ne garantio pri la ekstera protokolo. Tial ankaŭ malinstalo de unu kliento povas lasi adaptilan nomon malantaŭe.
La dokumentaro de Microsoft pri VPN-konektotipoj estas klara, ke la tipo priskribas la agordon de la kliento por tiu konekto. Kiam kromprogramo partoprenas, la montrata tipo sekvas tion, kion la kromprogramo registras, kaj la efektiva enkapsuligo povas esti tute io alia.
La sama tavoligo aperas aliloke. Virtuala adaptilo sur Linux-gastiganto, TAP-aparato aŭ poŝtelefona VPN-servo-etendaĵo estas ĉiuj interfacoj kreitaj de programaro, kaj la interfacan nomon elektas tiu programaro anstataŭ intertrakti ĝin kun la servilo.
Kion pordoj kaj adresoj povas kaj ne povas diri al vi
Ĉiu tavolo lasas malsamajn pruvojn. Legu ilin aparte kaj etikedo ĉesas esti verdikto:
| Evidence | What it establishes | Where it misleads |
|---|---|---|
| Adapter name | Which driver bound the interface | Plugins choose their own labels |
| Profile file | Which client consumes the configuration | Abstraction layers hide the transport |
| Outer port | Which port the peer accepts | 443 carries several protocols plus HTTPS |
| Tunnel address | The inner interface's network | Says nothing about encapsulation |
TCP 443 estas la plej klara ekzemplo. Ĝi povas porti SSTP, OpenVPN TCP-tunelon, SoftEther SSL-VPN-sesion aŭ ordinaran retan trafikon, kaj la pordnumero sola ne povas distingi ilin. Tial fajroŝirma regulo, kiu permesas 443, ne estas pruvo pri tio, kiu kliento estas uzata. Registraĵo sur la ekstera interfaco solvas tion, kaj solvas ĝin en sekundoj.
Legu la profilan formaton kaj la samtavolanon
La agorda dosiero estas pli forta indiko ol la adaptilo. OpenVPN-profilo enhavas instrukciojn kiel remote, proto kaj ca; WireGuard-agordo enhavas sekcion [Interface] kun privata ŝlosilo kaj sekciojn [Peer] kun permesitaj IP-oj; telefonlibra ero de Windows konservas la konektotipon en sia propra formato. Ĉiu sintakso apartenas al unu efektivigo.
Poste rigardu la dokumentaron kaj protokolojn de la samtavolano. La servilo scias, kiu protokola traktilo akceptis la sesion, kaj ĝia protokolo nomas la etapojn, kiuj finiĝis. Tiu pruvo superas ĉiun labortablan etikedon, ĉar ĝi estas registrata tie, kie la pakaĵoj efektive estis interpretitaj.
Elektu la manlibron laŭ protokolo, ne laŭ etikedo
OpenVPN-instrukcio apartenas al OpenVPN, WireGuard-ŝlosiloj kaj permesitaj IP-oj apartenas al WireGuard, kaj SSTP-profilo estas nek unu nek la alia. Alglui la opcion de unu kliento en alian, ĉar adaptila nomo sonis kongrua, estas la maniero kiel rompiĝas funkcianta agordo.
Post kiam la protokolo estas identigita, elektu la konforman vojon por solvi problemojn: la propra protokolo de la kliento, la protokolo de la servilo specifa al la protokolo, kaj registraĵo, kiu montras la eksteran interŝanĝon. De tie la paneo havas nomon anstataŭ etikedon.