Per què dos llocs amb la mateixa subxarxa no són una sola LAN

Dos despatxos utilitzen tots dos 192.168.77.0/24, i algú proposa un túnel perquè siguin una sola xarxa. La frase sona senzilla i amaga tres dissenys diferents: dues LAN independents que xoquen, un segment Ethernet estès deliberadament per una WAN i un arranjament de proxy-ARP que respon per adreces remotes. Quin dels tres teniu decideix què fa un amfitrió amb el paquet, i la resposta és visible abans que hi intervingui la passarel·la VPN.

L’amfitrió decideix abans que l’encaminador

Un amfitrió amb adreça 192.168.77.10/24 compara la destinació amb el seu propi prefix. Tot el que hi ha dins d’aquest prefix és a l’enllaç directe, així que l’amfitrió resol directament l’adreça de capa d’enllaç de la destinació. Tot el que en queda fora va a la passarel·la per defecte.

Aquesta decisió passa a la pila de l’amfitrió, no al túnel. Una ruta afegida a la passarel·la no pot salvar un paquet que l’amfitrió no hi envia mai.

Així, quan 192.168.77.20 només existeix a l’altre lloc, l’amfitrió local el demana per ARP i no rep cap resposta. L’apretada de mans VPN pot ser perfectament saludable mentre això falla. La fallada sembla un amfitrió mort més que un problema d’encaminament. Reconèixer aquest senyal estalvia una hora de depuració del túnel.

L’ARP és una pregunta d’enllaç local

L’ARP pregunta qui posseeix una adreça en aquest enllaç, i la resposta ha de venir d’alguna cosa que senti la difusió. Un encaminador a l’altre extrem d’un túnel IPsec no la sent, tret que el disseny faci dels dos llocs un sol domini de difusió.

Dos dispositius amb la mateixa adreça ho empitjoren: ni una resolució correcta pot dir quin dels dos ha respost.

L’adreçament duplicat no és un error d’encaminament i cap ruta el corregeix. O els llocs es renumeren en prefixos diferents, o esdevenen deliberadament un sol domini de capa d’enllaç.

Un segment estès transporta trames, no rutes

Un túnel que transporta Ethernet i s’adjunta a ponts fa que els dos llocs formin part d’un sol domini de capa d’enllaç. Les difusions ARP arriben a l’altre costat, i cada pont aprèn quines adreces MAC són on. La documentació del pont de Linux descriu aquesta frontera de reenviament basada en MAC.

Aquí la passarel·la remota no encamina gens entre dues subxarxes idèntiques. Les trames travessen una capa inferior que encamina IP pel seu compte, mentre els ponts allarguen la conversa Ethernet.

El preu és un radi d’impacte més gran. La inundació per a destinacions desconegudes, els bucles, l’assignació DHCP i l’adreçament únic necessiten tots un sol pla que abasti els dos llocs. Quan la WAN cau, els amfitrions perden trànsit que consideren local. El filtratge al pont i les regles VLAN poden restringir què travessa, però el transport encara no promet que hi arribi cada trama de control d’enllaç local.

El proxy ARP és un tercer disseny

Un encaminador pot respondre l’ARP per una adreça remota i després encaminar-hi. Això fa que l’amfitrió remot aparegui a l’enllaç directe per al remitent sense estendre cap domini de difusió.

És una eina més estreta que el pontatge: depèn del reenviament, de les rutes de tornada i d’un propietari clar per a cada adreça.

Tampoc no fa encaminables protocols arbitraris que no siguin IP, ni reprodueix un domini de difusió Ethernet. Feu-lo servir quan el requisit sigui exactament aquesta substitució, no com a drecera per ajornar la renumeració.

Trieu segons el requisit i després verifiqueu

Per a l’accés ordinari d’aplicacions entre despatxos, prefixos diferents i rutes explícites donen una frontera més clara. Ponteu quan el requisit sigui realment una adjacència de capa d’enllaç. Renumereu quan l’única raó del prefix compartit sigui que ningú encara no ho ha fet.

Confirmeu quin disseny teniu realment preguntant a un amfitrió què fa amb la destinació:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Un resultat d’enllaç directe amb una entrada de veí fallida assenyala un camí de capa d’enllaç absent. Un resultat via nomena la passarel·la i mou la pregunta a l’encaminament. En un pont, consulteu la base de dades de reenviament per veure si la MAC s’ha après a través del túnel. Cada sortida estreny la pregunta de disseny en lloc de reiniciar-la.