Aquesta adreça de túnel és un par, no una subxarxa que puguis navegar
La màscara en un enllaç punt a punt descriu l’extrem remot, no un rang de veïns. Llegeix l’adreça del par abans de decidir que la subxarxa sembla incorrecta.
El teu client es connecta i mostra un parell d’adreces, o una sola adreça amb una 255.255.255.255 màscara, i la primera reacció és que el servidor ha lliurat alguna cosa espatllada. No hi ha res espatllat: una interfície tunelada és un enllaç punt a punt, i la màscara descriu l’extrem remot d’aquest únic enllaç, no un rang de veïns. Llegir el parell com a local i par explica la màscara estranya, la ruta d’un sol host al seu costat i la taula de veïns absent. El que la mateixa lectura no excusa és un pla d’adreces que se solapa amb la xarxa de l’oficina.
Per què la màscara sembla incorrecta en un enllaç tunelat
En una interfície Ethernet, una adreça i una màscara afirmen dues coses: aquest host posseeix l’adreça, i tot el que hi ha dins del prefix és un veí directe. El nucli deriva una ruta enllaçada d’aquests dos fets i després resol les adreces d’enllaç dels veïns que creu presents. Una interfície punt a punt conserva la propietat i descarta els veïns, així que la segona adreça de la línia del client és l’extrem remot i no un altre host en un segment compartit. No hi ha adreçament de maquinari, ni trànsit de resolució, ni domini de difusió al qual unir-se, i per això la interfície es comporta com un conducte amb exactament una destinació.
També per això una ruta d’un sol host al costat d’una màscara àmplia és normal aquí i no un símptoma. L’abast en aquest enllaç vol dir una adreça, i el nucli escriu precisament això. Llegeix les dues adreces juntes abans de decidir que la configuració és incorrecta, perquè qualsevol de les dues per si sola sembla un error.
Dues topologies, dues formes d’adreça
La topologia punt a punt més antiga dona a cada client un bloc petit i fa servir les dues adreces del mig, així que la màscara sembla un fragment d’una xarxa i no un conjunt. La topologia de subxarxa lliura una adreça del conjunt amb la màscara del conjunt i anomena l’adreça de túnel del servidor el par. Totes dues produeixen un enllaç vàlid, i només difereixen en quines adreces apareixen al perfil i en la màscara que un usuari probablement qüestionarà.
| Topology | Client address shape | Peer | Route to expect |
|---|---|---|---|
| Point-to-point block per client | Two neighbouring addresses inside a small block | The far address of that block | A single host route on the tunnel device |
| Shared pool | One address carrying the pool mask | The server's tunnel address | A single host route on the tunnel device |
Sigui quina sigui la fila que encaixi amb el teu client, llegeix primer el par, perquè nomena l’extrem remot i per tant explica la màscara. Un perfil copiat entre servidors que fan servir topologies diferents mostrarà la forma incorrecta per al seu nou destí, i aquesta discrepància es confon fàcilment amb una fallada del servidor.
Quan el conjunt i la xarxa de l’oficina reclamen els mateixos bits
Com que l’enllaç és encaminat, el conjunt necessita un prefix que no aparegui enlloc entre les xarxes que el servidor pot assolir. Comparteix-ne un i el client tindrà una única ruta per a un rang que significa dos llocs, i la ruta instal·lada més recentment decideix quin lloc guanya. La fallada es presenta al client encara que la decisió que hi ha al darrere pertany al pla d’adreces. El que reporten els usuaris és que el router local desapareix quan s’aixeca el túnel, o que només responen alguns hosts de l’oficina.
Els prefixos que només s’assemblen són un altre cas, i comparar octets a ull no és una comparació de prefixos. Escriu tots dos i compta els bits emmascarats: 192.168.4.0/24 contra 192.168.6.0/24 coincideixen fins al bit 22 i divergeixen al bit 23, perquè el tercer octet es llegeix 00000100 contra 00000110, així que aquestes dues xarxes són realment separades. Posa 10.8.0.0/24 al costat d’una altra 10.8.0.0/24 i tots els 24 bits emmascarats coincideixen, cosa que vol dir que una ruta no pot expressar tots dos llocs. La longitud de la màscara decideix on s’atura la comparació, i la xarxa instal·lada en segon lloc és la que perd.
Què no pot lliurar un enllaç encaminat
La difusió i el multicast no travessen un enllaç encaminat, i diverses funcions conegudes hi estan construïdes. Les llistes de navegació, els anuncis de noms i la descoberta de serveis assumeixen un segment compartit, així que un servidor de fitxers pot respondre cada petició per adreça i tot i així no aparèixer mai en una llista. La resolució de noms que depèn de la difusió local d’enllaç falla pel mateix motiu, i cap edició del perfil canvia què pot transportar el túnel. Si això importa és una qüestió de requisits, no d’encaminament.
Un client que realment necessita aquests lliuraments requereix una interfície pont, que transporta trames Ethernet i per tant conserva el domini de difusió. El preu és un enllaç més sorollós, la pèrdua de l’adreçament net descrit més amunt i una superfície de fallada molt més gran quan apareixen bucles. Justifica el requisit abans de canviar, i prefereix un servei de noms que funcioni sobre enllaços encaminats quan el requisit només tracta de noms.
Llegeix la interfície abans d’editar el perfil
Pregunta al nucli què ha instal·lat, no què sembla dir el perfil. La sortida d’adreces mostra el par que explica la màscara, i la sortida de rutes mostra si hi ha un camí cap a ell. Executar les dues contra el dispositiu de túnel triga un moment i resol la qüestió.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1Si aquests tres coincideixen, el perfil fa allò per a què es va configurar i el problema restant és en un altre lloc. Canvia la topologia només per un motiu que anomeni una capacitat absent, perquè una màscara desconeguda no ho és.