Bryter det din VPN att stänga av ARP? Det kan, på det yttre hoppet

{Två paket färdas i samma anslutning och lyder under olika regler. Det ena är det privata paketet som tunneln bär, vilket det virtuella gränssnittet hanterar utan något Ethernet-huvud. Det andra är det krypterade paketet som lämnar maskinen över åtkomstlänken, och det behöver fortfarande ett lokalt nästa hopp upplöst till en hårdvaruadress. Att blanda ihop de två är hur folk stänger av adressupplösningen på fel gränssnitt och sedan undrar varför tunneln aldrig startar.}

{Ett paket inuti ett annat, två leveransmodeller}

{Det virtuella gränssnittet i routat läge tar emot IP-paket. Det har inget Ethernet-huvud, ingen broadcastdomän och inga adresser att lösa upp inuti sig, så det inre paketet levereras av tunneln själv. Det som händer på åtkomstnätet är ett separat leveranslager.}

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

{Det yttre paketet är en vanlig unicast-ram när det lämnar ett Ethernet-gränssnitt, och det behöver hårdvaruadressen för destinationen hos sitt nästa hopp. Adressupplösningen ger den, och nästa hopp är oftast den lokala gatewayen och inte fjärrservern. Att förstå att uppslagningen gäller gatewayen och inte slutpunkten är det mesta av diagnosen. Skriv ner båda adresserna innan du ändrar något.}

{Hitta grannen som faktiskt spelar roll}

{Fråga routingtabellen vilket nästa hopp slutpunkten använder och undersök sedan grannabellen för det hoppet. Själva slutpunkten dyker sällan upp där, eftersom den inte finns på den lokala länken.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Om posten finns och är nåbar är den yttre vägen i ordning och felet ligger någon annanstans. Om den saknas eller är i feltillstånd är länken, gatewayadressen eller en policy som blockerar upplösning platsen att titta på. Att ändra krypteringsinställningar på tunneln kan inte hjälpa i något av fallen. Notera tillståndssträngen som grannabellen rapporterar, eftersom den skiljer ett pågående försök från ett bestående fel.}

{En inlärd post kan dölja beroendet}

{En cachad post fortsätter att fungera ett tag efter att det som skapade den är borta, så ett test några minuter efter en ändring kan lyckas av fel anledning. Vänta tills posten blir gammal, eller ta bort den medvetet, innan du drar slutsatsen att upplösning är onödig.}

{Det omvända felet är lika vanligt: en oupplöst post behandlas som bevis för att tunneln är trasig. I praktiken pekar den på det lokala segmentet, på en dubblerad adress eller på en portssäkerhetsregel som kastar ramarna som bär svaret. Kontrollera switchporten innan du rör VPN-konfigurationen.}

{Läs tidpunkten som bevis. En post som löses upp och sedan löper ut gång på gång tyder på en fladdrande länk eller två enheter som svarar för en adress, medan en post som aldrig löses upp pekar på gatewayadressen eller på filtrering på åtkomstporten.}

{Välj mellan dynamisk upplösning och en fast post}

{Dynamisk upplösning är standard av en anledning: den följer hårdvaran när en gateway byts ut och kräver ingen samordning med någon. En statisk post är försvarbar när nätet sköts medvetet och parningen av adress och hårdvaruadress är en del av en dokumenterad design.}

{Hur som helst, tillämpa valet på åtkomstgränssnittet som bär det yttre paketet. Att stänga av upplösning på det gränssnittet härdar inte tunneln; det tar bort klientens förmåga att nå gatewayen som bär den, och felet ser ut som en död VPN i stället för ett lokalt adresseringsproblem.}

{Ha den andra stacken i åtanke}

{IPv6 använder inte adressupplösning i samma form; det använder grannupptäckt. Den skiktade frågan består oförändrad: hur når det faktiska yttre paketet ett lokalt nästa hopp, och vad bevisar att svaret är aktuellt.}

{Kontrollera samma två fakta på den andra stacken innan du förklarar designen klar, eftersom en tunnel som bär båda familjerna har två yttre vägar att överväga. Notera vilken du verifierade och vilken du antog.}