Ødelægger det din VPN at slå ARP fra? Det kan, på det ydre hop

{To pakker rejser i samme forbindelse og følger forskellige regler. Den ene er den private pakke, som tunnelen transporterer, og som det virtuelle interface håndterer uden nogen Ethernet-header. Den anden er den krypterede pakke, der forlader maskinen over adgangslinkset, og den har stadig brug for et lokalt næste hop opløst til en hardwareadresse. At forveksle de to er måden, hvorpå folk slår adresseopløsning fra på det forkerte interface og derefter undrer sig over, hvorfor tunnelen aldrig starter.}

{Én pakke inde i en anden, to leveringsmodeller}

{Det virtuelle interface i routet tilstand accepterer IP-pakker. Det har ingen Ethernet-header, intet broadcast-domæne og ingen adresser at opløse indeni, så den indre pakke leveres af tunnelen selv. Hvad der sker på adgangsnettet, er et separat leveringslag.}

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

{Den ydre pakke er en almindelig unicast-ramme, når den forlader et Ethernet-interface, og den har brug for destinationshardwareadressen på sit næste hop. Adresseopløsning skaffer den, og næste hop er normalt den lokale gateway og ikke den eksterne server. At forstå, at opslaget gælder gatewayen og ikke endepunktet, er det meste af diagnosen. Skriv begge adresser ned, før du ændrer noget.}

{Find den nabo, der faktisk betyder noget}

{Spørg rutetabellen, hvilket næste hop endepunktet bruger, og undersøg derefter nabotabellen for det hop. Selve endepunktet dukker sjældent op der, fordi det ikke er på det lokale link.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Hvis posten findes og er nåbar, er den ydre vej i orden, og fejlen ligger et andet sted. Hvis den mangler eller er i fejltilstand, er linket, gatewayadressen eller en politik, der blokerer opløsning, stedet at kigge. Ændring af cipherindstillinger på tunnelen kan ikke hjælpe i nogen af tilfældene. Bemærk tilstandsstrengen, som nabotabellen rapporterer, fordi den skelner et forsøg i gang fra en varig fejl.}

{En indlært post kan skjule afhængigheden}

{En cachet post virker et stykke tid, efter at det, der skabte den, er væk, så en test udført få minutter efter en ændring kan bestå af den forkerte grund. Vent på, at posten udløber, eller slet den med vilje, før du konkluderer, at opløsning er unødvendig.}

{Den modsatte fejl er lige så almindelig: en uopløst post behandles som bevis på, at tunnelen er brudt. I praksis peger den på det lokale segment, på en dubletadresse eller på en portsikkerhedsregel, der dropper de rammer, der bærer svaret. Kontrollér switchporten, før du rører VPN-konfigurationen.}

{Læs timingen som bevis. En post, der opløses og derefter udløber gentagne gange, tyder på et flagrende link eller to enheder, der svarer på én adresse, mens en post, der aldrig opløses, peger på gatewayadressen eller på filtrering på adgangsporten.}

{Vælg mellem dynamisk opløsning og en fast post}

{Dynamisk opløsning er standard af en grund: den følger hardwaren, når en gateway udskiftes, og kræver ingen koordinering med nogen. En statisk post er forsvarlig, når netværket styres bevidst, og parringen af adresse og hardwareadresse er en del af et dokumenteret design.}

{Uanset hvad, anvend valget på det adgangsinterface, der bærer den ydre pakke. At slå opløsning fra på det interface hærder ikke tunnelen; det fjerner klientens evne til at nå den gateway, der bærer den, og fejlen ser ud som en død VPN i stedet for et lokalt adresseringsproblem.}

{Husk den anden stak}

{IPv6 bruger ikke adresseopløsning i samme form; det bruger nabo-opdagelse. Det lagdelte spørgsmål består uændret: hvordan når den faktiske ydre pakke et lokalt næste hop, og hvad beviser, at svaret er aktuelt.}

{Kontrollér de samme to fakta på den anden stak, før du erklærer designet færdigt, fordi en tunnel, der bærer begge familier, har to ydre veje at overveje. Noter, hvilken du verificerede, og hvilken du antog.}