Kāpēc divas vietas ar vienu apakštīklu nav viens LAN

Divas birojas abas izmanto 192.168.77.0/24, un kāds ierosina tuneli, lai tās būtu viens tīkls. Teikums izklausās vienkārši un slēpj trīs atšķirīgus risinājumus: divus neatkarīgus LAN, kas saduras, vienu apzināti pār WAN izstieptu Ethernet segmentu un proxy-ARP izkārtojumu, kas atbild uz attālinātām adresēm. Kurš jums ir, nosaka, ko resursdators dara ar pakešu, un atbilde ir redzama pirms VPN vārtejas iesaistīšanās.

Resursdators izlemj pirms maršrutētāja

Resursdators ar adresi 192.168.77.10/24 salīdzina galamērķi ar savu prefiksu. Viss šajā prefiksā ir tiešajā saitē, tāpēc resursdators tieši atrisina galamērķa saites slāņa adresi. Viss ārpus tā iet uz noklusējuma vārteju.

Šis lēmums tiek pieņemts resursdatora stekā, nevis tunelī. Vārtejā pievienots maršruts nevar izglābt pakešu, ko resursdators tur nekad nesūta.

Tāpēc, ja 192.168.77.20 pastāv tikai otrā vietā, vietējais resursdators to jautā ar ARP un nesaņem atbildi. VPN rokasspiediens var būt pilnīgi vesels, kamēr šis neizdodas. Kļūme izskatās kā miris resursdators, nevis maršrutēšanas problēma. Šīs pazīmes atpazīšana ietaupa stundu tuneļa atkļūdošanas.

ARP ir vietējās saites jautājums

ARP jautā, kam pieder adrese šajā saitē, un atbildei jānāk no kaut kā, kas dzird apraidi. Maršrutētājs IPsec tuneļa otrā galā to nedzird, ja vien risinājums abas vietas nepārvērš vienā apraides domēnā.

Divas ierīces ar vienu un to pašu adresi padara to sliktāku: pat veiksmīgs risinājums nevar pateikt, kura atbildēja.

Divkārša adresācija nav maršrutēšanas kļūda, un neviens maršruts to nelabo. Vai nu vietas tiek pārnumurētas atšķirīgos prefiksos, vai arī tās apzināti kļūst par vienu saites slāņa domēnu.

Izstiepts segments pārvadā kadrus, nevis maršrutus

Tunelis, kas pārvadā Ethernet un ir pievienots tiltiem, abas vietas padara par vienu saites slāņa domēnu. ARP apraides sasniedz otru pusi, un katrs tilts iemācās, kur atrodas kuras MAC adreses. Linux tilta dokumentācija apraksta šo MAC balstīto pārsūtīšanas robežu.

Šeit attālā vārteja nemaz nemaršrutē starp diviem identiskiem apakštīkliem. Kadri šķērso apakšslāni, kas pats maršrutē IP, bet tilti pagarina Ethernet sarunu.

Cena ir lielāks ietekmes rādiuss. Plūdi uz nezināmiem galamērķiem, cilpas, DHCP piešķiršana un unikāla adresācija visi prasa vienu plānu, kas aptver abas vietas. Kad WAN krīt, resursdatori zaudē trafiku, ko uzskata par vietēju. Filtrēšana uz tilta un VLAN noteikumi var ierobežot, kas pāriet, bet pārvade joprojām nesola, ka katrs vietējais vadības kadrs nonāks.

Proxy ARP ir trešais risinājums

Maršrutētājs var atbildēt uz ARP par attālinātu adresi un pēc tam maršrutēt uz to. Tas liek attālajam resursdatoram sūtītājam izskatīties kā tiešajā saitē, neizstiepjot apraides domēnu.

Šis ir šaurāks rīks nekā tiltu veidošana: tas ir atkarīgs no pārsūtīšanas, atpakaļceļa maršrutiem un skaidra īpašnieka katrai adresei.

Tas arī nepadara patvaļīgus ne-IP protokolus maršrutējamus, un tas neatveido Ethernet apraides domēnu. Izmantojiet to, kad prasība ir tieši šī aizstāšana, nevis kā saīsni atliktai pārnumurēšanai.

Izvēlieties pēc prasības, pēc tam pārbaudiet

Parastai starpbiroju lietotņu piekļuvei atšķirīgi prefiksi un skaidri maršruti dod skaidrāku robežu. Veidojiet tiltu, kad prasība patiešām ir saites slāņa blakusums. Pārnumurējiet, kad vienīgais kopējā prefiksa iemesls ir tas, ka neviens to vēl nav izdarījis.

Pārliecinieties, kāds risinājums jums patiešām ir jautājot resursdatoram, ko tas dara ar galamērķi:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Tiešās saites rezultāts ar neizdevušos kaimiņa ierakstu norāda uz trūkstošu saites slāņa ceļu. via rezultāts nosauc vārteju un pārvieto jautājumu uz maršrutēšanu. Uz tilta pārbaudiet pārsūtīšanas datubāzi, lai redzētu, vai MAC tika iemācīts caur tuneli. Katra izvade sašaurina dizaina jautājumu, nevis sāk to no jauna.