Daardie tonneladres is ’n eweknie, nie ’n subnet wat jy kan verken nie
Die masker op ’n punt-tot-punt-skakel beskryf die verre ent, nie ’n reeks bure nie. Lees die eweknie-adres voordat jy besluit die subnet lyk verkeerd.
Jou kliënt maak verbinding en wys ’n adrespaar, of een adres met ’n 255.255.255.255 masker, en die eerste reaksie is dat die bediener iets stukkends uitgedeel het. Niks is stukkend nie: ’n tonnelkoppelvlak is ’n punt-tot-punt-skakel, en die masker beskryf die verre ent van daardie een skakel eerder as ’n reeks bure. Om die paar as plaaslik en eweknie te lees, verduidelik die vreemde masker, die een-gasheerroete daarlangs en die ontbrekende buretabel. Wat dieselfde lees nie verskoon nie, is ’n adresplan wat die kantoornetwerk oorvleuel.
Waarom die masker verkeerd lyk op ’n tonnelkoppelvlak
Op ’n Ethernet-koppelvlak sê ’n adres en ’n masker twee dinge: hierdie gasheer besit die adres, en alles binne die voorvoegsel is ’n direkte buur. Die kern lei ’n op-skakel-roete uit daardie twee feite af en los dan skakeladresse op vir die bure wat hy meen teenwoordig is. ’n Punt-tot-punt-koppelvlak behou die eienaarskap en laat vaar die bure, so die tweede adres op die kliëntlyn is die verre ent eerder as nog ’n gasheer op ’n gedeelde segment. Daar is geen hardeware-adressering, geen oplossingsverkeer en geen uitsaaidomein om by aan te sluit nie, en daarom gedra die koppelvlak hom soos ’n pyp met presies een bestemming.
Dit is ook waarom ’n gasheerroete langs ’n wye masker hier normaal is eerder as ’n simptoom. Bereikbaarheid op hierdie skakel beteken een adres, en die kern skryf presies dit neer. Lees die twee adresse saam voordat jy besluit die konfigurasie is verkeerd, want elkeen op sy eie lyk soos ’n fout.
Twee topologieë, twee adresvorms
Die ouer punt-tot-punt-topologie gee elke kliënt ’n klein blok en gebruik die twee middelste adresse, so die masker lyk soos ’n brokkie van ’n netwerk eerder as ’n poel. Die subnet-topologie deel ’n adres uit die poel met die poelmasker uit en noem die bediener se tonneladres die eweknie. Albei lewer ’n geldige skakel, en hulle verskil net in watter adresse in die profiel verskyn en in die masker wat ’n gebruiker waarskynlik sal bevraagteken.
| 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 |
Watter ry ook al by jou kliënt pas, lees eers die eweknie, want dit benoem die verre ent en verduidelik dus die masker. ’n Profiel wat tussen bedieners met verskillende topologieë gekopieer word, sal die verkeerde vorm vir sy nuwe tuiste wys, en daardie wanverhouding word maklik vir ’n bedienerfout aangesien.
Wanneer die poel en die kantoornetwerk dieselfde bisse opeis
Omdat die skakel gerouteer is, het die poel ’n voorvoegsel nodig wat nêrens onder die netwerke wat die bediener kan bereik, voorkom nie. Deel een en die kliënt hou ’n enkele roete vir ’n reeks wat twee plekke beteken, en die roete wat laas geïnstalleer is, besluit watter plek wen. Die fout wys hom op die kliënt, alhoewel die besluit daaragter aan die adresplan behoort. Wat gebruikers rapporteer, is dat die plaaslike router verdwyn wanneer die tonnel opkom, of dat net sommige kantoor-gashere antwoord.
Voorvoegsels wat bloot soos mekaar lyk, is ’n ander geval, en om oktette met die oog te vergelyk is nie ’n voorvoegselvergelyking nie. Skryf albei uit en tel gemaskeerde bisse: 192.168.4.0/24 teen 192.168.6.0/24 stem ooreen tot by bis 22 en wyk af by bis 23, want die derde okteet lees 00000100 teen 00000110, dus is daardie twee netwerke werklik apart. Sit 10.8.0.0/24 langs nog ’n 10.8.0.0/24 en al 24 gemaskeerde bisse stem ooreen, wat beteken een roete kan nie albei plekke uitdruk nie. Die maskerlengte besluit waar die vergelyking stop, en die netwerk wat tweede geïnstalleer is, is die een wat verloor.
Wat ’n gerouteerde skakel nie kan lewer nie
Uitsending en multicast beweeg nie oor ’n gerouteerde skakel nie, en verskeie bekende funksies is daarop gebou. Blaailyste, naamkondigings en diensontdekking veronderstel almal ’n gedeelde segment, so ’n lêerbediener kan elke versoek per adres beantwoord en tog nooit in ’n lys verskyn nie. Naamoplossing wat van skakelplaaslike uitsending afhang, misluk om dieselfde rede, en geen profielwysiging verander wat die tonnel kan dra nie. Of dit saak maak, is ’n vereiste-vraag eerder as ’n roetevraag.
’n Kliënt wat daardie aflewerings werklik nodig het, vereis ’n oorbrugde koppelvlak, wat Ethernet-raampies dra en dus die uitsaaidomein behou. Die prys is ’n lawaaieriger skakel, die verlies van die skoon adressering hierbo beskryf, en ’n veel groter foutoppervlak sodra lusse verskyn. Regverdig die vereiste voordat jy oorskakel, en verkies ’n naambediens wat oor gerouteerde skakels werk wanneer die vereiste net oor name gaan.
Lees die koppelvlak voordat jy die profiel wysig
Vra die kern wat hy geïnstalleer het eerder as wat die profiel blykbaar sê. Die adres-uitset wys die eweknie wat die masker verduidelik, en die roete-uitset wys of daar ’n pad daarheen bestaan. Om albei teen die tonnelkoppelvlak te laat loop, neem ’n oomblik en besleg die vraag.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1
As daardie drie ooreenstem, doen die profiel wat dit gekonfigureer is om te doen, en die oorblywende probleem lê elders. Verander die topologie net om ’n rede wat ’n ontbrekende vermoë noem, want ’n onbekende masker is nie een nie.