Vai ARP izslēgšana salauž jūsu VPN? Ārējā lēcienā tas var notikt

{Vienā savienojumā ceļo divas paketes, un tās pakļaujas dažādiem noteikumiem. Viena ir privātā paka, ko pārvieto tunelis un ko virtuālā saskarne apstrādā bez jebkādas Ethernet galvenes. Otra ir šifrētā paka, kas atstāj mašīnu pa piekļuves saiti, un tai joprojām nepieciešams lokāls nākamais lēciens, kas atrisināts uz aparatūras adresi. Šo divu sajaukšana ir iemesls, kāpēc cilvēki izslēdz adrešu atrisināšanu nepareizajā saskarnē un tad brīnās, kāpēc tunelis nekad nesāk darboties.}

{Viena paka otras iekšienē, divi piegādes modeļi}

{Virtuālā saskarne maršrutētā režīmā pieņem IP paketes. Tai nav Ethernet galvenes, nav apraides domēna un iekšienē nav atrisināmu adrešu, tāpēc iekšējo paku piegādā pats tunelis. Tas, kas notiek piekļuves tīklā, ir atsevišķa piegādes kārta.}

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

{Šī ārējā paka, atstājot Ethernet saskarni, ir parasts unicast kadrs, un tai nepieciešama sava nākamā lēciena galamērķa aparatūras adrese. Adrešu atrisināšana to nodrošina, un nākamais lēciens parasti ir vietējā vārteja, nevis attālinātais serveris. Sapratne, ka meklēšana attiecas uz vārteju, nevis uz galapunktu, ir lielākā daļa no diagnostikas. Pierakstiet abas adreses, pirms kaut ko maināt.}

{Atrodiet kaimiņu, kas patiešām ir svarīgs}

{Pajautājiet maršrutēšanas tabulai, kuru nākamo lēcienu izmanto galapunkts, pēc tam pārbaudiet kaimiņu tabulu šim lēcienam. Pats galapunkts tur parādās reti, jo tas nav vietējā saitē.}

ip route get 198.51.100.20
ip neigh show 192.168.0.1

{Ja ieraksts ir un ir sasniedzams, ārējais ceļš ir kārtībā un kļūme ir citur. Ja tā nav vai tas ir bojājuma stāvoklī, saite, vārtejas adrese vai atrisināšanu bloķējoša politika ir vieta, kur meklēt. Šifrēšanas iestatījumu maiņa tunelī nevar palīdzēt nevienā no abiem gadījumiem. Ievērojiet stāvokļa virkni, ko ziņo kaimiņu tabula, jo tā atšķir notiekošu mēģinājumu no pastāvīgas kļūmes.}

{Apgūts ieraksts var paslēpt atkarību}

{Kešatmiņā saglabātais ieraksts darbojas vēl kādu laiku pēc tam, kad pazudis tas, kas to radīja, tāpēc tests, kas veikts dažas minūtes pēc izmaiņām, var izdoties nepareiza iemesla dēļ. Pagaidiet, līdz ieraksts noveco, vai apzināti to izdzēsiet, pirms secināt, ka atrisināšana nav nepieciešama.}

{Pretējā kļūda ir tikpat izplatīta: neatrisināts ieraksts tiek uzskatīts par pierādījumu, ka tunelis ir salauzts. Praksē tas norāda uz vietējo segmentu, uz dublētu adresi vai uz porta drošības noteikumu, kas izmet atbildi nesošos kadrus. Pārbaudiet komutatora portu, pirms aiztiekat VPN konfigurāciju.}

{Lasiet laiku kā pierādījumu. Ieraksts, kas tiek atrisināts un pēc tam atkārtoti beidzas, liecina par svārstīgu saiti vai divām ierīcēm, kas atbild uz vienu adresi, savukārt ieraksts, kas nekad netiek atrisināts, norāda uz vārtejas adresi vai filtrēšanu piekļuves portā.}

{Izlemiet starp dinamisko risinājumu un fiksētu ierakstu}

{Dinamiskais risinājums ir noklusējums iemesla dēļ: tas seko aparatūrai, kad vārteja tiek nomainīta, un neprasa saskaņošanu ar nevienu. Statisks ieraksts ir attaisnojams, kad tīkls tiek apzināti pārvaldīts un adreses un aparatūras adreses savienošana pārī ir dokumentēta dizaina daļa.}

{Jebkurā gadījumā piemērojiet izvēli piekļuves saskarnei, kas pārvieto ārējo paku. Atrisināšanas izslēgšana šajā saskarnē tuneli nepadara drošāku; tā atņem klientam iespēju sasniegt vārteju, kas to pārvieto, un kļūme izskatās kā miris VPN, nevis kā vietēja adresācijas problēma.}

{Paturiet prātā arī otru steku}

{IPv6 neizmanto adrešu atrisināšanu tādā pašā formā; tas izmanto kaimiņu atklāšanu. Slāņu jautājums paliek nemainīgs: kā īstā ārējā paka nokļūst lokālā nākamajā lēcienā, un kas pierāda, ka atbilde ir aktuāla.}

{Pārbaudiet tos pašus divus faktus arī otrā stekā, pirms pasludināt dizainu pabeigtu, jo tunelim, kas pārvieto abas saimes, ir divi ārējie ceļi, kas jāapsver. Pierakstiet, kuru jūs pārbaudījāt un kuru pieņēmāt.}