Miks kaks sama alamvõrguga kohta ei ole üks LAN
Host otsustab otseühenduse ja järgmise hüppe vahel enne, kui ükski VPN-marsruuter paketti näeb. Kaks kohta, mis jagavad sama prefiksit, vajavad venitatud ühendust või ümbernummerdamise plaani.
Kaks kontorit kasutavad mõlemad 192.168.77.0/24 ja keegi pakub tunnelit, et neist saaks üks võrk. See lause kõlab lihtsalt ja peidab kolme erinevat lahendust: kaks sõltumatut LAN-i, mis põrkuvad, üks meelega üle WAN-i venitatud Etherneti segment ja proxy-ARP lahendus, mis vastab kaughostide eest. Milline neist teil on, määrab, mida host paketiga teeb, ja vastus on nähtav enne, kui VPN-lüüs sekkub.
Host otsustab enne marsruuterit
Host aadressiga 192.168.77.10/24 võrdleb sihtmärki oma prefiksiga. Kõik selle prefiksi sees on otseühenduses, seega lahendab host sihtmärgi lülitasandi aadressi otse. Kõik väljaspool läheb vaikelüüsi.
See otsus tehakse hosti virnas, mitte tunnelis. Lüüsile lisatud marsruut ei päästa paketti, mida host sinna kunagi ei saada.
Kui 192.168.77.20 on ainult teises kohas, küsib kohalik host seda ARP-iga ja ei saa vastust. VPN-i kätlus võib olla täiesti terve, samal ajal kui see ei õnnestu. Tõrge näeb välja nagu surnud host, mitte nagu marsruutimise probleem. Selle signatuuri äratundmine säästab tunni tunelli silumist.
ARP on kohaliku lüli küsimus
ARP küsib, kellele kuulub aadress sellel lülil, ja vastus peab tulema millestki, mis kuuleb ringhäälingut. IPsec-tunneli teises otsas olev marsruuter ei kuule seda, kui lahendus ei tee kahest kohast üht ringhäälingu domeeni.
Kaks sama aadressiga seadet teevad asja hullemaks: isegi õnnestunud lahendus ei ütle, milline neist vastas.
Dubldresseerimine ei ole marsruutimise viga ja ükski marsruut seda ei paranda. Kas kohad nummerdatakse ümber erinevatesse prefiksitesse või saavad neist meelega üks lülitasandi domeen.
Venitatud segment kannab kaadreid, mitte marsruute
Etherneti kandev tunnel, mis on sildadega ühendatud, teeb mõlemad kohad ühe lülitasandi domeeni osaks. ARP-ringhäälingud jõuavad teisele poole ja iga sild õpib, kus asuvad millised MAC-aadressid. Linuxi silla dokumentatsioon kirjeldab seda MAC-põhist edastuspiiri.
Siin ei marsruudi kauge lüüs üldse kahe identse alamvõrgu vahel. Kaadrid läbivad alusvõrku, mis marsruudib IP-d ise, samal ajal kui sillad pikendavad Etherneti vestlust.
Hind on suurem mõjuraadius. Uputus tundmatute sihtmärkide jaoks, silmused, DHCP-jaotus ja unikaalne adresseerimine vajavad kõik üht plaani, mis katab mõlemad kohad. Kui WAN langeb, kaotavad hostid liiklust, mida nad peavad kohalikuks. Sillal filtreerimine ja VLAN-i reeglid võivad piirata, mis läbi pääseb, kuid vedu ei taga ikkagi, et iga kohalik juhtkaader kohale jõuab.
Proxy ARP on kolmas lahendus
Marsruuter saab vastata ARP-ile kauge aadressi eest ja seejärel sinna marsruutida. See paneb kauge hosti saatja jaoks otseühendusse paistma ilma ringhäälingu domeeni venitamata.
See on kitsam tööriist kui sildamine: see sõltub edastamisest, tagasiteedest ja iga aadressi selgest omanikust.
See ei tee ka suvalisi mitte-IP protokolle marsruuditavaks ega taasta Etherneti ringhäälingu domeeni. Kasutage seda siis, kui nõue on täpselt see asendus, mitte edasilükatud ümbernummerdamise otsetee.
Vali nõude järgi, siis kontrolli
Tavalise kontoritevahelise rakendusjuurdepääsu jaoks annavad erinevad prefiksid ja otsesed marsruudid selgema piiri. Silla, kui nõue on tõesti lülitasandi külgnevus. Nummerda ümber, kui ühise prefiksi ainus põhjus on see, et keegi pole seda veel teinud.
Kinnitage, milline lahendus teil tegelikult on, küsides hostilt, mida see sihtmärgiga teeb:
ip route get 192.168.77.20
ip neigh show 192.168.77.20
Otseühenduse tulemus ebaõnnestunud naaberkirjega osutab puuduvale lülitasandi teele. via tulemus nimetab lüüsi ja viib küsimuse marsruutimisse. Sillal kontrollige edastustabelit, et näha, kas MAC õpiti tunnelist. Iga väljund kitsendab lahenduse küsimust, selle asemel et seda uuesti alustada.