Kodėl du objektai su tuo pačiu potinkliu nėra vienas LAN

Du biurai abu naudoja 192.168.77.0/24, ir kažkas siūlo tunelį, kad jie būtų vienas tinklas. Šis sakinys skamba paprastai ir slepia tris skirtingus sprendimus: du nepriklausomi LAN, kurie susiduria, vienas tyčia per WAN ištemptas Ethernet segmentas ir proxy-ARP sąranka, atsakanti už tolimus adresus. Kurį turite, nulemia, ką mazgas daro su paketu, o atsakymas matomas dar prieš įsitraukiant VPN tinklų sietuvui.

Mazgas nusprendžia anksčiau nei maršrutizatorius

Mazgas, kurio adresas 192.168.77.10/24, lygina paskirties vietą su savo priešdėliu. Viskas, kas yra tame priešdėlyje, yra tiesioginėje jungtyje, todėl mazgas tiesiogiai išsprendžia paskirties jungties sluoksnio adresą. Viskas, kas yra už jo, eina į numatytąją perėją.

Šis sprendimas priimamas mazgo kamino dalyje, o ne tunele. Maršrutas, pridėtas perėjoje, negali išgelbėti paketo, kurio mazgas niekada ten nesiunčia.

Taigi, kai 192.168.77.20 egzistuoja tik kitame objekte, vietinis mazgas jo klausia per ARP ir negauna atsakymo. VPN rankos paspaudimas gali būti visiškai sveikas, kol tai nepavyksta. Gedimas atrodo kaip miręs mazgas, o ne maršrutizavimo problema. Šio požymio atpažinimas sutaupo valandą tunelio derinimo.

ARP yra vietinės jungties klausimas

ARP klausia, kam priklauso adresas šioje jungtyje, ir atsakymas turi ateiti iš to, kas girdi transliaciją. Maršrutizatorius kitame IPsec tunelio gale jos negirdi, nebent sprendimas abu objektus paverčia viena transliacijos sritimi.

Du įrenginiai su tuo pačiu adresu padaro dar blogiau: net sėkmingas sprendimas nepasakys, kuris atsakė.

Dvigubas adresavimas nėra maršrutizavimo klaida ir joks maršrutas to neištaiso. Arba objektai pernumeruojami į skirtingus priešdėlius, arba tyčia tampa viena jungties sluoksnio sritimi.

Ištemptas segmentas neša kadrus, o ne maršrutus

Tunelis, nešantis Ethernet ir prijungtas prie tiltų, abu objektus paverčia vienos jungties sluoksnio srities dalimi. ARP transliacijos pasiekia kitą pusę, ir kiekvienas tiltas išmoksta, kur yra kokie MAC adresai. Linux tilto dokumentacija aprašo šią MAC pagrįstą persiuntimo ribą.

Čia tolimoji perėja visiškai nemaršrutizuoja tarp dviejų identiškų potinklių. Kadrai kerta apatinį sluoksnį, kuris pats maršrutizuoja IP, o tiltai prailgina Ethernet pokalbį.

Kaina yra didesnis poveikio spindulys. Plūdimas į nežinomas paskirtis, kilpos, DHCP paskirstymas ir unikalus adresavimas visi reikalauja vieno plano, apimančio abu objektus. Kai WAN nukrenta, mazgai praranda srautą, kurį laiko vietiniu. Filtravimas tilte ir VLAN taisyklės gali apriboti, kas praeina, bet perdavimas vis tiek nežada, kad kiekvienas vietinis valdymo kadras atvyks.

Proxy ARP yra trečiasis sprendimas

Maršrutizatorius gali atsakyti į ARP už tolimą adresą ir tada maršrutizuoti link jo. Tai leidžia tolimam mazgui siuntėjo atžvilgiu atrodyti kaip tiesioginėje jungtyje, neištempiant transliacijos srities.

Tai siauresnis įrankis nei tiltų jungimas: jis priklauso nuo persiuntimo, grįžimo maršrutų ir aiškaus kiekvieno adreso savininko.

Jis taip pat nepadaro savavališkų ne IP protokolų maršrutizuojamais ir neatkuria Ethernet transliacijos srities. Naudokite jį, kai poreikis yra būtent tas pakeitimas, o ne kaip atidėto pernumeravimo trumpinį.

Rinkitės pagal poreikį, tada patikrinkite

Įprastai tarpbiurinei prieigai prie programų skirtingi priešdėliai ir aiškūs maršrutai duoda aiškesnę ribą. Tiltą darykite, kai poreikis tikrai yra jungties sluoksnio kaimynystė. Pernumeruokite, kai vienintelė bendro priešdėlio priežastis yra ta, kad to dar niekas nepadarė.

Patvirtinkite, kokį sprendimą iš tikrųjų turite paklausdami mazgo, ką jis daro su paskirties vieta:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Tiesioginės jungties rezultatas su nepavykusiu kaimyno įrašu rodo trūkstamą jungties sluoksnio kelią. via rezultatas įvardija perėją ir perkelia klausimą į maršrutizavimą. Tilte patikrinkite persiuntimo duomenų bazę, ar MAC buvo išmoktas per tunelį. Kiekviena išvestis susiaurina sprendimo klausimą, o ne pradeda jį iš naujo.