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

{To pakker reiser i samme forbindelse og følger ulike regler. Den ene er den private pakken tunnelen frakter, som det virtuelle grensesnittet håndterer uten noe Ethernet-hode. Den andre er den krypterte pakken som forlater maskinen over aksesslenken, og den trenger fortsatt et lokalt neste hopp løst opp til en maskinvareadresse. Å blande de to er hvordan folk slår av adresseoppslag på feil grensesnitt og deretter lurer på hvorfor tunnelen aldri starter.}

{Én pakke inne i en annen, to leveringsmodeller}

{Det virtuelle grensesnittet i rutet modus tar imot IP-pakker. Det har ikke noe Ethernet-hode, ikke noe kringkastingsdomene og ingen adresser å løse opp inne i seg, så den indre pakken leveres av tunnelen selv. Det som skjer på aksessnettet, er et eget leveringslag.}

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

{Den ytre pakken er en vanlig enkeltadressert ramme når den forlater et Ethernet-grensesnitt, og den trenger maskinvareadressen til destinasjonen for sitt neste hopp. Adresseoppslag skaffer den, og neste hopp er vanligvis den lokale gatewayen og ikke den eksterne serveren. Å forstå at oppslaget gjelder gatewayen og ikke endepunktet, er det meste av diagnosen. Skriv ned begge adressene før du endrer noe.}

{Finn naboen som faktisk betyr noe}

{Spør rutetabellen hvilket neste hopp endepunktet bruker, og undersøk deretter nabotabellen for det hoppet. Selve endepunktet dukker sjelden opp der, fordi det ikke er på den lokale lenken.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Hvis oppføringen finnes og er nåbar, er den ytre veien i orden og feilen ligger et annet sted. Hvis den mangler eller er i en feiltilstand, er lenken, gatewayadressen eller en policy som blokkerer oppslag stedet å se. Å endre chifferinnstillinger på tunnelen kan ikke hjelpe i noen av tilfellene. Legg merke til tilstandstrengen nabotabellen rapporterer, fordi den skiller et forsøk som pågår fra en varig feil.}

{En innlært oppføring kan skjule avhengigheten}

{En bufret oppføring fortsetter å virke en stund etter at det som lagde den er borte, så en test som kjøres minutter etter en endring kan bestå av feil grunn. Vent til oppføringen blir for gammel, eller slett den med vilje, før du konkluderer med at oppslag er unødvendig.}

{Den motsatte feilen er like vanlig: en uløst oppføring behandles som bevis på at tunnelen er ødelagt. I praksis peker den på det lokale segmentet, på en duplikatadresse eller på en portikkerhetsregel som slipper rammene som bærer svaret. Sjekk svitsjporten før du rører VPN-konfigurasjonen.}

{Les timingen som bevis. En oppføring som løses opp og deretter utløper gang på gang, tyder på en flagrende lenke eller to enheter som svarer for én adresse, mens en oppføring som aldri løses opp, peker på gatewayadressen eller på filtrering på aksessporten.}

{Velg mellom dynamisk oppslag og en fast oppføring}

{Dynamisk oppslag er standard av en grunn: det følger maskinvaren når en gateway byttes ut og trenger ingen koordinering med noen. En statisk oppføring er forsvarlig når nettet styres bevisst og koblingen mellom adresse og maskinvareadresse er en del av et dokumentert design.}

{Uansett, bruk valget på aksessgrensesnittet som bærer den ytre pakken. Å slå av oppslag på det grensesnittet herder ikke tunnelen; det fjerner klientens evne til å nå gatewayen som bærer den, og feilen ser ut som en død VPN og ikke som et lokalt adresseringsproblem.}

{Husk den andre stakken}

{IPv6 bruker ikke adresseoppslag i samme form; det bruker nabo-oppdagelse. Det lagdelte spørsmålet består uendret: hvordan når den faktiske ytre pakken et lokalt neste hopp, og hva beviser at svaret er oppdatert.}

{Sjekk de samme to fakta på den andre stakken før du erklærer designet fullstendig, fordi en tunnel som bærer begge familier har to ytre veier å vurdere. Noter hvilken du verifiserte og hvilken du antok.}