Kas ARP-i väljalülitamine rikub teie VPN-i? Välisel hüppel võib küll

{Samas ühenduses liigub kaks paketti ja need järgivad erinevaid reegleid. Üks on privaatne pakett, mida tunnel kannab ja mida virtuaalne liides töötleb ilma ühegi Etherneti päiseta. Teine on krüpteeritud pakett, mis lahkub masinast juurdepääsulüli kaudu, ja see vajab endiselt kohalikku järgmist hüpet, mis on lahendatud riistvara-aadressiks. Nende kahe segamini ajamine on põhjus, miks inimesed lülitavad aadresside lahendamise välja vale liidese peal ja imestavad siis, miks tunnel kunagi ei käivitu.}

{Üks pakett teise sees, kaks kohaletoimetamise mudelit}

{Virtuaalne liides marsruuditud režiimis võtab vastu IP-pakette. Sellel pole Etherneti päist, ülekande domeeni ega aadresse, mida sees lahendada, seega toimetab sisemise paketi kohale tunnel ise. See, mis toimub juurdepääsuvõrgus, on eraldi kohaletoimetamise kiht.}

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

{See väline pakett on tavaline unicast-kaader, kui see lahkub Etherneti liidesest, ja see vajab oma järgmise hüppe sihtriistvara aadressi. Aadresside lahendamine annab selle, ja järgmine hüpe on tavaliselt kohalik lüüs, mitte kaugserver. Arusaamine, et otsing on lüüsi jaoks, mitte lõpp-punkti jaoks, on suurem osa diagnoosist. Kirjutage mõlemad aadressid üles enne, kui midagi muudate.}

{Leidke naaber, mis tegelikult loeb}

{Küsige marsruutimistabelilt, millist järgmist hüpet lõpp-punkt kasutab, ja seejärel uurige selle hüppe naabritabelit. Lõpp-punkt ise ilmub sinna harva, sest see ei asu kohalikus lülis.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Kui kirje on olemas ja kättesaadav, on väline tee korras ja viga on mujal. Kui see puudub või on tõrkeseisundis, tuleb vaadata lüli, lüüsi aadressi või poliitikat, mis lahendamise blokeerib. Šifri seadete muutmine tunnelil ei aita kummalgi juhul. Pange kirja olekustring, mida naabritabel teatab, sest see eristab käimasolevat katset püsivast tõrkest.}

{Õpitud kirje võib sõltuvuse peita}

{Vahemällu salvestatud kirje töötab mõnda aega pärast seda, kui see, mis selle lõi, on kadunud, nii et mõni minut pärast muudatust tehtud test võib läbida vale põhjuse tõttu. Oodake, kuni kirje aegub, või kustutage see meelega, enne kui järeldate, et lahendamine pole vajalik.}

{Vastupidine viga on sama tavaline: lahendamata kirjet peetakse tõestuseks, et tunnel on katki. Praktikas osutab see kohalikule segmendile, dubleeritud aadressile või pordi turvareeglile, mis viskab vastust kandvad kaadrid kõrvale. Kontrollige kommutaatori porti enne, kui VPN-i konfiguratsiooni puudutate.}

{Lugege ajastust tõendina. Kirje, mis lahendatakse ja seejärel korduvalt aegub, viitab värelevale lülile või kahele seadmele, mis vastavad ühe aadressi eest, samas kui kirje, mida kunagi ei lahendata, osutab lüüsi aadressile või juurdepääsupordi filtreerimisele.}

{Otsustage dünaamilise lahenduse ja fikseeritud kirje vahel}

{Dünaamiline lahendus on vaikimisi mõjuval põhjusel: see järgib riistvara, kui lüüs välja vahetatakse, ja ei vaja kellegagi kooskõlastamist. Staatiline kirje on põhjendatud siis, kui võrku hallatakse teadlikult ja aadressi ning riistvara-aadressi paar on dokumenteeritud disaini osa.}

{Mõlemal juhul rakendage valikut juurdepääsuliidesele, mis kannab välist paketti. Lahendamise väljalülitamine sellel liidesel ei tee tunnelit tugevamaks; see võtab kliendilt võimaluse jõuda lüüsini, mis teda kannab, ja tõrge näeb välja nagu surnud VPN, mitte nagu kohalik aadressiprobleem.}

{Pidage silmas ka teist virna}

{IPv6 ei kasuta aadresside lahendamist samal kujul; see kasutab naabrite avastamist. Kihiline küsimus jääb muutumatuks: kuidas jõuab tegelik väline pakett kohaliku järgmise hüppeni ja mis tõestab, et vastus on ajakohane.}

{Kontrollige samu kahte fakti ka teisel virnal enne, kui kuulutate disaini valmis, sest mõlemat perekonda kandval tunnelil on kaks välist teed, mida kaaluda. Märkige üles, millise kontrollisite ja millise eeldasite.}