Miért nem egyetlen LAN két telephely ugyanazzal az alhálózattal

Két iroda mindkettő a 192.168.77.0/24 címet használja, és valaki alagutat javasol, hogy egy hálózat legyenek. A mondat egyszerűnek tűnik és három különböző tervet rejt: két független LAN, amelyek ütköznek, egy szándékosan WAN-on át nyújtott Ethernet-szegmens, és egy proxy-ARP elrendezés, amely távoli címek helyett válaszol. Hogy melyik van Önnél, eldönti, mit tesz a gazdagép a csomaggal, és a válasz már a VPN-átjáró részvétele előtt látható.

A gazdagép az útválasztó előtt dönt

A 192.168.77.10/24 című gazdagép összehasonlítja a célt a saját előtagjával. Minden, ami ezen az előtagon belül van, közvetlen kapcsolaton van, ezért a gazdagép közvetlenül oldja fel a cél kapcsolati rétegbeli címét. Minden, ami kívül esik, az alapértelmezett átjáróra megy.

Ez a döntés a gazdagép veremében születik, nem az alagútban. Az átjárón hozzáadott útvonal nem menthet meg egy csomagot, amelyet a gazdagép soha nem küld oda.

Amikor tehát a 192.168.77.20 csak a másik telephelyen létezik, a helyi gazdagép ARP-pal kérdezi, és nem kap választ. A VPN-kézfogás teljesen egészséges lehet, miközben ez meghiúsul. A hiba halott gazdagépnek látszik, nem útválasztási problémának. Ennek a mintának a felismerése egy óra alagút-hibakeresést takarít meg.

Az ARP helyi kapcsolat kérdése

Az ARP azt kérdezi, ki birtokolja a címet ezen a kapcsolaton, és a válasznak olyasmitől kell jönnie, ami hallja a szórást. Egy IPsec-alagút túlsó végén lévő útválasztó nem hallja, hacsak a terv nem tesz a két telephelyből egy szórási tartományt.

Két eszköz ugyanazzal a címmel még rosszabbá teszi: még egy sikeres feloldás sem mondja meg, melyik válaszolt.

A duplikált címzés nem útválasztási hiba, és egyetlen útvonal sem javítja meg. Vagy újraszámozzák a telephelyeket külön előtagokra, vagy szándékosan egy kapcsolati rétegbeli tartománnyá válnak.

A nyújtott szegmens kereteket visz, nem útvonalakat

A hidakhoz kapcsolt Ethernetet vivő alagút mindkét telephelyet egy kapcsolati rétegbeli tartomány részévé teszi. Az ARP-szórások elérik a túlsó oldalt, és minden híd megtanulja, mely MAC-címek hol vannak. A Linux híd dokumentációja leírja ezt a MAC-alapú továbbítási határt.

Itt a távoli átjáró egyáltalán nem útválaszt két azonos alhálózat között. A keretek olyan alrétegen haladnak át, amely maga útválasztja az IP-t, miközben a hidak meghosszabbítják az Ethernet-beszélgetést.

Az ár a nagyobb hatókör. Az ismeretlen célok felé irányuló elárasztás, a hurkok, a DHCP-kiosztás és az egyedi címzés mind egyetlen tervet igényel, amely mindkét telephelyre kiterjed. Ha a WAN kiesik, a gazdagépek elveszítik a forgalmat, amelyet helyinek tekintenek. A hídon végzett szűrés és a VLAN-szabályok korlátozhatják, mi halad át, de a szállítás még mindig nem ígéri, hogy minden helyi vezérlőkeret megérkezik.

A proxy ARP egy harmadik terv

Az útválasztó válaszolhat az ARP-ra egy távoli címért, majd odairányíthat. Ettől a távoli gazdagép a feladó számára közvetlen kapcsolaton lévőnek látszik anélkül, hogy szórási tartományt nyújtana.

Szűkebb eszköz a hídépítésnél: a továbbítástól, a visszirányú útvonalaktól és minden cím egyértelmű tulajdonosától függ.

Az sem tesz tetszőleges nem IP-protokollokat útválaszthatóvá, és nem hoz létre Ethernet-szórási tartományt. Akkor használja, amikor a követelmény pontosan ez a helyettesítés, nem pedig a halasztott újraszámozás rövidítéseként.

A követelményből válasszon, majd ellenőrizzen

A szokásos irodák közötti alkalmazáseléréshez a külön előtagok és a kifejezett útvonalak tisztább határt adnak. Hidaljon, amikor a követelmény valóban kapcsolati rétegbeli szomszédság. Számozzon újra, amikor a közös előtag egyetlen oka az, hogy ezt még senki nem tette meg.

Erősítse meg, melyik terv van valójában Önnél azzal, hogy megkérdez egy gazdagépet, mit tesz a céllal:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

A közvetlen kapcsolatra utaló eredmény sikertelen szomszédbejegyzéssel hiányzó kapcsolati rétegbeli útra mutat. A via eredmény megnevezi az átjárót, és a kérdést az útválasztáshoz tereli. Hídon ellenőrizze a továbbítási adatbázist, hogy a MAC megtanulása megtörtént-e az alagúton át. Minden kimenet szűkíti a tervezési kérdést ahelyett, hogy újraindítaná.