Publika prefikso por VPN-klientoj: kion ĝi fakte rompas

Klientaro elektita ĉar la nombroj aspektas ordaj estas itinero, kiu atendas instaladon. La prefikso ne devas esti privata por ke la VPN funkciu, kaj uzi blokon, kiu apartenas al iu alia, ankaŭ ne aŭtomate elmetas viajn uzantojn al la interreto. Kion ĝi faras, estas igi tiujn adresojn signifi ion alian dum la tunelo estas supre, kaj poste denove signifi ion alian kiam ĝi falas. Trapasu la kvin kontrolojn sube laŭorde kaj haltu tie, kie la respondo estas «atribuita aliloke».

Atribuo ne estas anonco

Meti adreson sur tunelan interfacon ne anoncas ĝin al la interreto. Publika atingeblo bezonas itinero, rajtigitan vojon kaj provizanton preta porti ĝin, kaj neniu el tiuj aperas ĉar kliento ricevis la adreson el klientaro. Fajroŝirma politiko kaj gastiga rajtigo denove estas apartaj decidoj.

Tial la risko ne estas tio, kion plej multaj homoj supozas. La prunteprenita prefikso ne igas viajn klientojn atingeblaj; ĝi igas celojn de iu alia neatingeblaj el viaj klientoj, kio estas alia fiasko kun alia posedanto. Neniu estas atakata kaj neniu anonco eskapas. Uzanto simple ne povas malfermi retejon, kiu funkciis hieraŭ, kaj la helpdesko havas neniun kialon suspekti la VPN-klientaron.

La distingo gravas kiam vi elektas klientaron. Se via sola zorgo estus elmeto al la interreto, publika bloko ŝajnus sekura ĉar nenio anoncas ĝin. La zorgo estas la loka itinero, kiun la kliento instalas por tiu prefikso, kaj tiu itinero estas instalata sendepende de tio, ĉu iu alia povas vidi ĝin.

Kion la klienta itinero fakte kaptas

Kiam la tunelo supreniĝas, la kliento ricevas itinero por la prefikso de la klientaro, kaj tiu itinero superas la defaŭltan itinero por ĉiu celo ene de ĝi. Peto al legitima gastiganto en tiu bloko nun iras al la VPN anstataŭ al la interreto. Ĉu ĝi fiaskas, pendas aŭ atingas la malĝustan servilon dependas de tio, kion via flanko faras kun ĝi.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

Rulu la serĉon kun la tunelo supre kaj denove kun ĝi malsupre. La adreso signifas unu aferon en la unua kazo kaj tute alian en la dua, kaj ajna aplikaĵo, kiu kaŝmemorigis konekton aŭ nomrezolucion trans tiu transiro, kondutos nekonsekvence. Tiu nekonsekvenco estas pli malfacile subtenebla ol pura fiasko, ĉar ĝi dependas de tempo. Uzanto, kiu rekonektiĝas en la malĝusta momento, spertas alion ol unu, kiu ne faras tion.

Tial ankaŭ konata IP-adreso ne estas pruvo de identeco. Konservu atestilon kaj servilnomvalidigon por la reala celo, ĉar la numera adreso, kiun vi atingis antaŭ kvin minutoj, nun povas aparteni al alia konversacio.

Komparu la klientaron kun ĉiu reto, kiun vi konas

RFC 1918 rezervas tri blokojn por privata uzo: 192.168.0.0/16, 172.16.0.0/12 kaj 10.0.0.0/8. Milionoj da apartaj organizaĵoj reuzas ilin, do privata estas aserto pri atribuado kaj neniam promeso, ke neniu alia elektis la samajn nombrojn.

Komparu la kandidatan klientaron kun oficejaj LAN-oj, nubaj VPC-oj, aliaj VPN-klientaroj, partneraj ligiloj kaj la teritorioj, kiujn malproksimaj laborantoj verŝajne havas hejme. La hejma kazo ne estas kialo inventi strangan prefikson; ĝi estas kialo teni la klientaron malgranda kaj dokumentita.

Kunordigu la atribuadon kun tiu, kiu posedas vojigon, kaj registru la revenan vojon en la sama loko. Klientaro, al kiu neniu povas vojigi reen, estas klientaro, kiu estos retrovita dum paneo. Metu la klientaron en la saman dokumenton kiel la retejajn teritoriojn, ne en klientan agordon, kiun redaktis nur unu persono. La dokumento estas tio, kio igas la sekvan kolizion evitebla.

Kiam publika adresado estas la ĝusta respondo

Organizaĵoj kun ĝuste atribuita tutmonda spaco povas tute konstrui publike adresitan VPN-klientaron, kaj iuj faras tion intence por eviti tradukadon. Tiu dezajno ankoraŭ bezonas vojigon, fontvalidigon, alirregulojn kaj klientan aŭtentikigon; la atribuo liveras neniun el ili.

Kion ĝi liveras, estas unikeco, la eco, kiun la prunteprenita prefikso mankas. Se vi posedas la blokon, la itinero, kiun via kliento instalas, montras al adresoj, kiuj vere estas viaj, kaj la signifo ne ŝanĝiĝas kiam la tunelo falas.

Ne aldonu NAT aŭtomate por kompensi elekton de klientaro. Vojigita privata dezajno kun eksplicitaj revenaj itineroj estas pli pura ol tradukado aplikita ĉar la adresado neniam estis planita, kaj IPv6 bezonas sian propran intencan planon anstataŭ kopion de la IPv4-supozoj.

Retiriĝu malbonan klientaron sen perdi aliron

Se la klientaro jam estas deplojita, faru inventaron antaŭ ol ŝanĝi ĝin: adresrezervoj, instalitaj itineroj, DNS-rikordoj, kiuj solviĝas en la blokon, fajroŝirmaj ampleksoj kaj la aplikaĵoj, kiuj dependas de ili. Poste planu la ŝanĝon kun la sama zorgo kiel ĉiu alia vojiga transiro. Anoncu ĝin al la homoj, kiuj rimarkos, ĉar iliaj seancoj falos kiam la klientaro moviĝos. Silenta ŝanĝo de klienta adresado generas subtenajn biletojn, kiuj aspektas ne rilataj al la laboro.

Konservu reakiran vojon, kiu ne dependas de la klientaro, kiun vi forigas, ĉar la momento, kiam vi retiras ĝin, estas la momento, kiam via fora aliro eble malaperos kun ĝi. Poste validigu ambaŭ direktojn: la celitaj privataj celoj ankoraŭ funkcias, kaj la interretaj celoj, kiuj antaŭe estis kaptitaj, nun solviĝas al siaj veraj posedantoj.

Kion vi volas, estas klientaro, kiun la reta teamo povas atribui, vojigi kaj retiri kiel unu koheran aferon. Adresa formato sola establas nek sekurecon nek konekteblecon.