IPv6-adresoj ne anstataŭas vian VPN: retrovu la originan taskon

Malfermu la statan paĝon de la kliento, vidu tutmondan IPv6-adreson, kaj la tento estas konkludi, ke la tunelo iĝis laŭvola. Tiu paĝo montras adreson, ne ĉifran limon, ne privatan enkursigan tabelon kaj ne alirdecidon. VPN kutime portas tri taskojn samtempe, kaj IPv6 tuŝas nur tiun pri dividado de malmultaj adresoj. Trairi unu servon de la kliento ĝis la aŭskultanto estas la sola maniero vidi, kiu tasko postvivas la ŝanĝon.

Nomu la taskon antaŭ ol forigi la ilon

Homoj diras „la VPN” kiam ili celas unu el tri aranĝoj, kaj la tri malsukcesas pro malsamaj kialoj. Atingi unu aplikaĵon publikigitan de unu teamo estas problemo de aplika aliro. Aliĝi al difinita aro de privataj retoj, por ke pluraj ejoj povu atingi unu la alian, estas enkursiga rilato. Teni stabilan administran supertavolon super infrastrukturo, kiun vi ne plene kontrolas, estas operacia aranĝo kun propra adresa plano.

IPv6 forigas adresdividan obstaklon por la unua aranĝo, kaj tie ĝi faras realan laboron, ĉar rekta adreso povas anstataŭi tradukilon. Por la aliaj du ĝi ŝanĝas nenion, ĉar la postulo neniam estis adresa malabundo. Skribu, kiun el la tri vi efektive funkciigas, antaŭ ol vi tuŝos agordon.

Publika adreso ne estas ĉifrado

Tutmonde ampleksa adreso diras al vi, kie gastiganto estas atingebla; ĝi diras nenion pri tio, ĉu la trafiko alvenanta tien estas ĉifrita aŭ aŭtentigita. La diskuto de RFC 8504 pri sekureco apartigas subtenon de IPsec-realigo disde la pli vasta elekto inter IPsec, TLS, SSH kaj aliaj aliroj, kio estas ĝuste la distingo, kiu malaperas kiam adreseblo estas legata kiel protekto. Staplo, kiu subtenas mekanismon, pruvis nur, ke la mekanismo haveblas, neniam ke ĉi tiu fluo iris tra ĝi. Por IPsec specife, la intertraktita asocio kaj la trafiko, kiun ĝi elektas, decidas, kio estas protektata, kaj adresa familio estas eco de la paketo, ne politiko por ĝi.

Atingeblo estas denove aparta demando. Publika adreso ne igas neatenditan trafikon alveni, ĉar la vojo, la fajroŝirmilo kaj la aŭskultanto ĉiu havas voĉon, kaj forigi NAT forigas unu filtrilon, ne ĉiujn. Decidu, por kiu el tiuj tri la tunelo anstataŭis, se entute.

Kion la supertavolo ankoraŭ provizas

Supertavolo daŭre gajnas sian lokon en tri situacioj. Foraj uzantoj eble bezonas specifan aron de vojoj anstataŭ unu aplikaĵon, du ejoj eble bezonas privatan atingeblan interkonsenton, kaj operatoroj eble volas adresadon, kiu ne ŝanĝiĝas kiam la alirprovizanto ŝanĝiĝas. Neniu el la tri temas pri la manko de IPv4-adresoj.

Tutmondaj adresoj ne faras tion senprizorga. Bela interna plano ne tenas la eksteran finpunkton respondanta post kiam la provizanto ŝanĝas ĝin, kaj aŭtentigo, rekonekto kaj nomaj ĝisdatigoj ankoraŭ bezonas posedanton. Decidu, kiel tiuj resaniĝos, antaŭ ol io estas malŝaltita.

Trairu la servon, kiu fariĝos publika

Komencu ĉe la gastiganto kaj listigu, kio efektive aŭskultas, ĉar la aplikaĵo, kiun vi aprobis, malofte estas la sola afero sur la maŝino. ss -lntup presas ĉiun TCP- kaj UDP-aŭskultanton kun sia bind-adreso kaj aldonas la posedan procezon, kie viaj privilegioj permesas tion, kio montras unuvide, ĉu administra interfaco sidas sur ĵokera adreso aŭ nur sur loopback. Ripetu ĝin kiel ss -6 -lntup se via staplo tenas IPv6-ingojn aparte.

Poste klasifiku ĉiun linion laŭ publiko. Aplika pordo, kiu portas sian propran aŭtentigon kaj transportan sekurecon, povas esti en ordo sur publika adreso, dum administra interfaco, metrika finpunkto kaj datumbaza pordo kutime ne estas. Unu aprobita aplikaĵo estas juĝo pri nur tiu aplikaĵo, neniam permeso elmeti ĉiun servon, kiu dividas la gastiganton. La bind-adreso en ĉiu linio diras al vi, ĉu la elmeto jam ekzistas aŭ estus kreita de la ŝanĝo, kiun vi planas.

Du testoj, tiam decidu kion malŝalti

Antaŭ ol forigi tavolon, respondu du demandojn sur papero. Unue, ĉu la postulo bezonas privatan enkursigon, do atingeblon, kiun publika adreso ne implicas kaj la alirprovizanto ne ofertas? Due, ĉu ĝi bezonas protektan limon, do ĉifradon kaj aŭtentigon sur fluo, kiu alie transirus nefidan vojon malkaŝe? Se ambaŭ respondoj estas ne por tiu servo, la tunelo estas kandidato por forigo; se iu ajn estas jes, ĝi restas.

Rulu la saman teston super IPv4 kaj IPv6 aparte sur dual-stack-kliento, ĉar protektita IPv4-trafiko priskribas nenion pri la IPv6-vojo. Tutmonda IPv6-adreso en stata paĝo ne estas pruvo de liko, kaj mankanta unu ne estas pruvo de protekto. Malŝaltu nur la servojn, kie ambaŭ respondoj estis skribitaj kaj ankoraŭ estas ne, kaj notu en la ŝanĝa registro, kiu demando decidis tion.