Ĉu malŝalti ARP rompas vian VPN? Ĝi povas, ĉe la ekstera salto

{Du paketoj vojaĝas en la sama konekto kaj obeas malsamajn regulojn. Unu estas la privata paketo, kiun la tunelo portas, kaj kiun la virtuala interfaco pritraktas sen iu ajn Ethernet-kapo. La alia estas la ĉifrita paketo, kiu forlasas la maŝinon tra la alira ligo, kaj tiu ankoraŭ bezonas lokan sekvan salton solvitan al hardvara adreso. Konfuzi la du estas kiel homoj malŝaltas adresan solvon sur la malĝusta interfaco kaj poste demandas sin, kial la tunelo neniam ekfunkcias.}

{Unu paketo ene de la alia, du liveraj modeloj}

{La virtuala interfaco en enkursigita reĝimo akceptas IP-paketojn. Ĝi havas neniun Ethernet-kapon, neniun dissendan domajnon kaj neniujn adresojn por solvi ene de ĝi, do la internan paketon liveras la tunelo mem. Kio ajn okazas en la alira reto, tio estas aparta livera tavolo.}

inner packet: private address -> tunnel device -> the VPN process
outer packet: endpoint address -> access route -> next-hop hardware address

{Tiu ekstera paketo estas ordinara unuĉela kadro kiam ĝi forlasas Ethernet-interfacon, kaj ĝi bezonas la celan hardvaran adreson de sia sekva salto. Adresa solvo provizas ĝin, kaj la sekva salto kutime estas la loka enirejo, ne la fora servilo. Kompreni, ke la serĉo estas por la enirejo, ne por la finpunkto, estas la plej granda parto de la diagnozo. Notu ambaŭ adresojn antaŭ ol vi ŝanĝos ion.}

{Trovu la najbaron, kiu vere gravas}

{Demandu la enkursigadan tabelon, kiun sekvan salton la finpunkto uzas, poste ekzamenu la najbaran tabelon por tiu salto. La finpunkto mem malofte aperas tie, ĉar ĝi ne estas sur la loka ligo.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Se la rikordo ĉeestas kaj estas atingebla, la ekstera vojo estas en ordo kaj la fuŝo estas aliloke. Se ĝi mankas aŭ estas en fiaska stato, la ligo, la enireja adreso aŭ regularo, kiu blokas solvon, estas la loko por rigardi. Ŝanĝi ĉifrajn agordojn sur la tunelo povas helpi en neniu el la du kazoj. Notu la statan ĉenon, kiun raportas la najbara tabelo, ĉar ĝi distingas provon en progreso disde daŭra fiasko.}

{Lernita rikordo povas kaŝi la dependon}

{Kaŝmemora rikordo daŭre funkcias iom da tempo post kiam malaperis tio, kio kreis ĝin, do testo farita minutojn post ŝanĝo povas sukcesi pro la malĝusta kaŭzo. Atendu, ĝis la rikordo eksvalidiĝos, aŭ forigu ĝin intence, antaŭ ol konkludi, ke solvo estas nenecesa.}

{La mala eraro same oftas: nesolvita rikordo estas traktata kiel pruvo, ke la tunelo estas rompita. Fakte ĝi montras la lokan segmenton, duoblan adreson aŭ havenan sekurecan regulon, kiu forĵetas la kadrojn portantajn la respondon. Kontrolu la komutilan havenon antaŭ ol tuŝi la VPN-agordon.}

{Legu la tempon kiel pruvon. Rikordo, kiu solviĝas kaj poste ree eksvalidiĝas, sugestas flirtan ligon aŭ du aparatojn respondantajn por unu adreso, dum rikordo, kiu neniam solviĝas, montras la enirejan adreson aŭ filtradon sur la alira haveno.}

{Decidu inter dinamika solvo kaj fiksa rikordo}

{Dinamika solvo estas la defaŭlta pro kaŭzo: ĝi sekvas la hardvaron kiam enirejo estas anstataŭigita kaj bezonas neniun kunordigon kun iu ajn. Statika rikordo estas defendebla kiam la reto estas intence administrata kaj la parigo de adreso kaj hardvara adreso estas parto de dokumentita dezajno.}

{Ĉiel ajn, apliku la elekton al la alira interfaco, kiu portas la eksteran paketon. Malŝalti solvon sur tiu interfaco ne firmigas la tunelon; ĝi forprenas de la kliento la kapablon atingi la enirejon, kiu portas ĝin, kaj la fuŝo aspektas kiel morta VPN anstataŭ kiel loka adresproblemo.}

{Memoru la alian stakon}

{IPv6 ne uzas adresan solvon en la sama formo; ĝi uzas najbaran malkovron. La tavola demando restas senŝanĝa: kiel la reala ekstera paketo atingas lokan sekvan salton, kaj kio pruvas, ke la respondo estas aktuala.}

{Kontrolu la samajn du faktojn sur la alia stako antaŭ ol deklari la dezajnon kompleta, ĉar tunelo, kiu portas ambaŭ familiojn, havas du eksterajn vojojn por konsideri. Notu, kiun vi kontrolis kaj kiun vi supozis.}