L2 VPN vagy L3-alagút: öt ellenőrzés, mielőtt hidat építesz egy telephelyhez

Azért építesz hidat egy telephelyhez, mert valamelyik eszköz ragaszkodik hozzá, hogy ugyanabban a hálózatban kell lennie, és három héttel később hajnali kettőkor kapcsolónaplókat olvasol. Az ilyen megérzés túl sok Ethernet-over-IP kapcsolatról dönt. Itt valójában csak egyetlen különbség számít: hogy egész keretek utaznak-e végtől végig, vagy csak IP-csomagok. Futtasd végig az alábbi öt ellenőrzést sorrendben, és állj meg az elsőnél, amelyik elbukik.

Ellenőrizd, mit tesz valójában a vezetékre az alkalmazás

Mielőtt bármilyen terméknév bekerül a beszélgetésbe, rögzíts egy percet abból a forgalomból, amelynek át kell haladnia a kapcsolaton: tcpdump -i eth0 -nn -e 'not ip'. A kapcsoló -e kiírja az adatkapcsolati réteg fejlécét, és pontosan ezt dobja el egy irányított alagút. Ha a rögzítés üres marad, az alkalmazásod IP-t beszél, és egy L3-alagút változatlanul szállítja. Ha mégis megjelennek keretek, jegyezd fel az EtherType-ot, mert 0x0806 az ARP, 0x88cc az LLDP, és egy szállítói érték általában IP-tartalék nélküli felderítő protokollt jelent. Ezen a ponton egy közönséges tun interfész már nem elég.

Ismételd meg a rögzítést a túlsó oldalon is. Egy keret, amely csak egyetlen gazdagép virtuális kapcsolójában létezik, nem ok arra, hogy egy üzenetszóró tartományt kinyújts egy WAN fölé.

Ellenőrizd, át kell-e haladnia a felderítésnek a kapcsolaton

Egy irányított alagútnak nincs közös szegmense, ezért semmi, ami csoporthoz címzett, nem ér el a másik végére. Az ARP, a DHCP-üzenetszórások, a mDNS a következőn: 224.0.0.251, az SSDP és a NetBIOS-névlekérdezések mind olyan kapcsolatot feltételeznek, amelyet több gazdagép egyszerre hall.

Kérdezd meg, melyiküktől függ valójában az alkalmazás, és létezik-e már hozzá proxy. A DHCP-relay, az mDNS-tükrözés és a statikus ARP-bejegyzések egyenként egy-egy függőséget szüntetnek meg, és mindegyik egy újabb szolgáltatás, amelyet futtatni és figyelni kell. Ha kettő vagy három marad, a hidazás a tisztességes válasz.

Ellenőrizd, mennyibe kerül a plusz fejléc

A kereteknek kell valahol lakniuk, ezért minden, amit küldesz, kap maga köré egy második fejlécvermet. Egy VXLAN-fedésben ez egy külső IP-fejlécet, egy UDP-fejlécet és egy 8 bájtos VXLAN-fejlécet jelent, ami egy teljes méretű 1,500 bájtos terhelést egy közönséges 1,500 bájtos internetkapcsolat útvonal-MTU-ján túlra tolr. Az OpenVPN tap módban a saját többletét ugyanebbe az irányba teszi hozzá. Ha a belső oldalon nincs alacsonyabb MTU, olyan kapcsolatot kapsz, amely válaszol a pingre, és az első nagy átvitelnél elakad.

A számla nem áll meg a fejlécbájtoknál. Az üzenetszórás és a multicast, amelyet a kapcsoló hardverben kezel, most a WAN-on utazik, és minden hidazott telephely ugyanazt a címtervet, DHCP-tartományt és ismétlődő címekkel kapcsolatos viselkedést örökli. Ez a kapcsolatot jóval nehezebben auditálhatóvá teszi, mint egy irányított pool, amelyben telephelyenként egy előtag van.

Számolj, mielőtt választasz. Egy forgalmas szegmens, amelyet három telephelyre replikálnak, több üzenetszóró forgalmat mozgathat, mint azok a fájlátvitelek, amelyekre épült.

Ellenőrizd, milyen fajta L2 VPN-t kínálnak neked

Maga a kifejezés kétértelmű, és a kétértelműség dönti el, ki szállítja a forgalmadat. Néha a terhelést írja le: Ethernet-keretek IP-ben, az interneten át küldve, mint bármely más alagút, ahogy a VXLAN, a ZeroTier és az OpenVPN tap módja teszi. Néha egy megvásárolt szolgáltatást ír le: egy szolgáltatói Ethernet-kört vagy egy MPLS-álvezetéket, amely két telephelyet köt össze egyetlen szolgáltatói hálózaton belül.

Mindkettő szegmenst ad, ezért az alkalmazás nem tudja megkülönböztetni őket, de az üzemeltetési különbség nagy. A fedés nálad hagyja az MTU, a titkosítás és az alatta lévő útvonal felelősségét. A szolgáltatói szolgáltatás ezeket átveszi és kiszámlázza, és a kereteidet egyáltalán nem irányítja át a nyilvános interneten. Melyiket akarod, attól függ, hogy a két telephely osztozik-e egy üzemeltetőn, vagy csak egy cégen.

Ellenőrizd az olcsóbb megoldást, mielőtt hidat építesz

A hidazott kapcsolatra vonatkozó kérések többsége egyetlen elromlott névfeloldásból jön, nem olyan protokollból, amelynek valóban keretek kellenek. Először a feloldót és a keresési tartományt küldd át az irányított alagúton: dhcp-option DNS 10.8.0.1 együtt dhcp-option DOMAIN internal.example egy OpenVPN-kiszolgáló konfigurációjában meglepően sokukat megoldja. Egy helyi továbbító a túlsó oldalon ugyanezt a munkát végzi anélkül, hogy üzenetszóró forgalmat mozgatna.

Ha egy régi eszköz továbbra is elbukik, tedd azt az eszközt proxy vagy ugrógép mögé a cél-szegmensen. Egyetlen TCP-továbbítót olcsóbb üzemeltetni, mint egy hidazott WAN-t.

Zárd le a döntést sorrendben: hordoz-e a forgalom nem IP EtherType-ot, át kell-e haladnia a felderítésnek, fel tudja-e venni az MTU a plusz fejléceket, tényleg elérhető-e szolgáltatói kör, és elbukott-e az irányított megoldás olyan okból, amelyet meg tudsz nevezni? Bármelyik lépésnél egy nem lezárja a vitát a már meglévő alagút javára. Archiváld a rögzítést és az EtherType-listát a változási rekorddal, mert a következő ember ugyanezt a kérdést teszi fel, és nem akarja megismételni a mérést.