Plena tunelo kontraŭ finpunkta vojo: teni la VPN-servilon atingebla

Aldonu defaŭltan vojon tra la tunelo, kaj la propraj pakaĵoj de la tunelo sekvos ĝin. La tabelo tiam enhavas regulon, kiu venkas sin mem. La ĉifrita konekto al la servilo provas vojaĝi interne de la konekto, kiun ĝi provas starigi.

Du meĥanismoj malhelpas tiun buklon. Unu estas videbla en la enkursiga tabelo, la alia vivas interne de la aplikaĵo.

Interna kaj ekstera trafiko estas malsamaj decidoj

Aplikaĵa pakaĵo eniras la virtualan interfacon kaj estas enkapsuligita. La rezulto estas nova pakaĵo adresita al la publika adreso de la servilo. Tiu pakaĵo bezonas vojon en la fizika reto, ĉar nenio de ĝi rajtas eniri la tunelon.

Ambaŭ estas enkursigaj decidoj, kaj nur la unua apartenas al la tunelo. Kiam la kliento instalas defaŭltan vojon, kiu kovras ankaŭ la servilon, la ekstera pakaĵo ankaŭ estas kaptita.

La simptomoj estas tujaj kaj totalaj. La manpremo finiĝas kaj poste nenio fluas, aŭ la konekto falas en la momento, kiam la vojo estas instalita. En ambaŭ kazoj la keepalive ne plu povas eliri.

Opcio unu: gastiga vojo por la finpunkto

La rekta aliro aldonas vojon por la adreso de la servilo tra la origina enirejo. Ĝi postulas unu linion. Ĝi estas videbla al ĉiu, kiu legas la tabelon. Ĝi ankaŭ facile klarigeblas en ŝanĝprotokolo.

Ĝia malforto aperas, kiam la suba vojo ŝanĝiĝas. La konservita vojo nomas enirejon kaj interfacon el la malnova reto. Post Wi-Fi-ŝanĝo tiu enirejo eble ne ekzistas, kaj la vojo restas malantaŭe, aspektas ĝuste kaj faras nenion.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Gastiga nomo malfaciligas tion. Se la finpunkto estas nomo, kiu solviĝas al pluraj adresoj, la escepto devas kovri la adreson efektive uzatan. Pli posta serĉo povas redoni ion, kion la vojo neniam kovris.

Opcio du: protekti la soketon

La alia aliro neniam tuŝas la enkursigan tabelon. La kliento markas aŭ protektas la soketon, kiu portas la tunelon, do la operaciumo sendas la trafikon de tiu soketo ekster la tunelon laŭ politiko. Android malkaŝas la meĥanismon rekte al VPN-aplikaĵoj. Labortablaj klientoj realigas ekvivalentojn per fajroŝirmilaj markoj aŭ alvokoj de ligo al aparato.

La avantaĝo estas, ke la escepto sekvas la konekton anstataŭ konservitan enirejon. Reta ŝanĝo reskribas la suban vojon, kaj la protektita soketo moviĝas kun ĝi, ĉar ĝi neniam estis fiksita al adreso. La enkursiga tabelo restas pura.

La kosto estas videbleco. Nenio en la enkursiga tabelo montras la escepton, do recenzanto serĉanta gastigan vojon trovas nenion kaj povas konkludi, ke la dezajno estas nesekura. La protekto vivas en la kodo de la kliento kaj en la politikaj reguloj, kiujn tiu kodo instalas.

Elekti inter ili

Elektu la soketan meĥanismon, kiam la kliento subtenas ĝin, ĉar ĝi postvivas la retajn ŝanĝojn, kiuj rompas fiksitan vojon. Elektu la gastigan vojon, kiam la escepto devas esti videbla al aliaj iloj, aŭ kiam la kliento proponas nenion pli bonan.

Neniu el la meĥanismoj forigas la bezonon, ke la adreso de la servilo estu ĝenerale atingebla. Privata enirejo havas publikan aŭskultan adreson, kaj tiu adreso estas tio, kio devas resti ekster la tunelo. La internaj retoj malantaŭ ĝi fariĝas atingeblaj nur post kiam la tunelo ekzistas.

Kion ajn vi elektos, tenu ĝin ĉe la komponanto, kiu posedas la tunelon. Vaganta gastiga vojo aldonita permane funkcias ĝis la sekva reto, kaj tiam ĝi fariĝas la mistera paneo de morgaŭ.