Øydelegg det VPN-en din å slå av ARP? Det kan, på det ytre hoppet

{To pakkar reiser i same sambinding og følgjer ulike reglar. Den eine er den private pakken tunnelen fraktar, som det virtuelle grensesnittet handterer utan noko Ethernet-hovud. Den andre er den krypterte pakken som forlèt maskina over aksesslenkja, og den treng framleis eit lokalt neste hopp løyst opp til ei maskinvareadresse. Å blande dei to er korleis folk slår av adresseoppslag på feil grensesnitt og deretter lurar på kvifor tunnelen aldri startar.}

{Éin pakke inne i ein annan, to leveringsmodellar}

{Det virtuelle grensesnittet i ruta modus tek imot IP-pakkar. Det har ikkje noko Ethernet-hovud, ikkje noko kringkastingsdomene og ingen adresser å løysa opp inne i seg, så den indre pakken vert levert av tunnelen sjølv. Det som skjer på aksessnettet, er eit eige leveringslag.}

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

{Den ytre pakken er ei vanleg einskildadressert ramme når ho forlèt eit Ethernet-grensesnitt, og ho treng maskinvareadressa til destinasjonen for sitt neste hopp. Adresseoppslag skaffar henne, og neste hopp er vanlegvis den lokale gatewayen og ikkje den eksterne tenaren. Å forstå at oppslaget gjeld gatewayen og ikkje endepunktet, er det meste av diagnosen. Skriv ned båe adressene før du endrar noko.}

{Finn naboen som faktisk betyr noko}

{Spør rutetabellen kva neste hopp endepunktet brukar, og undersøk deretter nabotabellen for det hoppet. Sjølve endepunktet dukkar sjeldan opp der, fordi det ikkje er på den lokale lenkja.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Viss oppføringa finst og er nåbar, er den ytre vegen i orden og feilen ligg ein annan stad. Viss ho manglar eller er i ein feiltilstand, er lenkja, gatewayadressa eller ein policy som blokkerer oppslag staden å sjå. Å endre chifferinnstillingar på tunnelen kan ikkje hjelpe i nokon av tilfella. Legg merke til tilstandstrengen nabotabellen rapporterer, fordi han skil eit forsøk som pågår frå ein varig feil.}

{Ei innlært oppføring kan skjule avhengnaden}

{Ei bufra oppføring held fram med å verke ei stund etter at det som laga henne er borte, så ein test som vert køyrd minutt etter ei endring kan bestå av feil grunn. Vent til oppføringa vert for gammal, eller slett henne med vilje, før du konkluderer med at oppslag er unødvendig.}

{Den motsette feilen er like vanleg: ei uløyst oppføring vert handsama som prov på at tunnelen er øydelagd. I praksis peikar ho på det lokale segmentet, på ei duplikatadresse eller på ein porttryggleiksregel som slepp rammene som ber svaret. Sjekk svitsjporten før du rører VPN-konfigurasjonen.}

{Les timinga som prov. Ei oppføring som vert løyst opp og deretter går ut på tid gang på gang, tyder på ei flagrande lenkje eller to einingar som svarar for éi adresse, medan ei oppføring som aldri vert løyst opp, peikar på gatewayadressa eller på filtrering på aksessporten.}

{Vel mellom dynamisk oppslag og ei fast oppføring}

{Dynamisk oppslag er standard av ein grunn: det følgjer maskinvaren når ein gateway vert bytt ut og treng ingen koordinering med nokon. Ei statisk oppføring er forsvarleg når nettet vert styrt med vilje og koplinga mellom adresse og maskinvareadresse er ein del av eit dokumentert design.}

{Uansett, bruk valet på aksessgrensesnittet som ber den ytre pakken. Å slå av oppslag på det grensesnittet gjer ikkje tunnelen hardare; det fjernar evna klienten har til å nå gatewayen som ber han, og feilen ser ut som ein død VPN og ikkje som eit lokalt adresseringsproblem.}

{Hugs den andre stakken}

{IPv6 brukar ikkje adresseoppslag i same form; det brukar nabo-oppdaging. Det lagdelte spørsmålet står uendra: korleis når den faktiske ytre pakken eit lokalt neste hopp, og kva provar at svaret er oppdatert.}

{Sjekk dei same to fakta på den andre stakken før du erklærer designet fullstendig, fordi ein tunnel som ber båe familiane har to ytre vegar å vurdera. Noter kva for ein du verifiserte og kva for ein du antok.}