Tiu tunela adreso estas samtavolano, ne subreto, kiun vi povas foliumi
La masko sur punkt-al-punkta ligo priskribas la malproksiman finon, ne gamon da najbaroj. Legu la adreson de la samtavolano antaŭ ol decidi, ke la subreto aspektas malĝuste.
Via kliento konektiĝas kaj montras adresan paron, aŭ unu adreson portantan 255.255.255.255 maskon, kaj la unua reago estas, ke la servilo donis ion rompitan. Nenio estas rompita: tunela interfaco estas punkt-al-punkta ligo, kaj la masko priskribas la malproksiman finon de tiu unu ligo, ne gamon da najbaroj. Legi la paron kiel loka adreso kaj samtavolano klarigas la strangan maskon, la unu-gastigan itineron apud ĝi kaj la mankantan najbaran tabelon. Kion la sama legado ne pardonas, estas adresa plano, kiu interkovras la oficejan reton.
Kial la masko aspektas malĝuste sur tunela ligo
Sur Ethernet-interfaco, adreso kaj masko asertas du aferojn: ĉi tiu gastiganto posedas la adreson, kaj ĉio ene de la prefikso estas rekta najbaro. La kerno derivas itineron sur la ligo el tiuj du faktoj kaj poste solvas ligajn adresojn por la najbaroj, kiujn ĝi kredas ĉeestaj. Punkt-al-punkta interfaco konservas la posedon kaj forlasas la najbarojn, do la dua adreso en la klienta linio estas la malproksima fino, ne alia gastiganto en komuna segmento. Mankas aparatara adresado, solva trafiko kaj dissenda domajno por aliĝi, kaj tial la interfaco kondutas kiel tubo kun ekzakte unu celo.
Tial ankaŭ gastiga itinero apud larĝa masko estas ĉi tie normala, ne simptomo. Atingebleco sur ĉi tiu ligo signifas unu adreson, kaj la kerno skribas ĝuste tion. Legu la du adresojn kune antaŭ ol decidi, ke la agordo estas malĝusta, ĉar ĉiu el ili sola aspektas kiel eraro.
Du topologioj, du adresaj formoj
La pli malnova punkt-al-punkta topologio donas al ĉiu kliento malgrandan blokon kaj uzas la du mezajn adresojn, do la masko aspektas kiel fragmento de reto, ne kiel provizo. La subreta topologio disdonas adreson el la provizo kun la proviza masko kaj nomas la tunelan adreson de la servilo la samtavolano. Ambaŭ produktas validan ligon, kaj ili diferencas nur en kiuj adresoj aperas en la profilo kaj en la masko, kiun uzanto verŝajne pritaksos.
| 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 |
Kiun ajn vicon kongruas via kliento, legu unue la samtavolanon, ĉar ĝi nomas la malproksiman finon kaj tial klarigas la maskon. Profilo kopiita inter serviloj kun malsamaj topologioj montros la malĝustan formon por sia nova hejmo, kaj tiu miskongruo facile konfuziĝas kun servila paneo.
Kiam la provizo kaj la oficeja reto postulas la samajn bitojn
Ĉar la ligo estas itinerigita, la provizo bezonas prefikson, kiu aperas nenie inter la retoj, kiujn la servilo povas atingi. Kunhavigu unu kaj la kliento tenas ununuran itineron por gamo, kiu signifas du lokojn, kaj la lastatempe instalita itinero decidas, kiu loko venkas. La paneo montriĝas ĉe la kliento, kvankam la decido malantaŭ ĝi apartenas al la adresa plano. Kion raportas uzantoj, estas malaperanta loka enkursigilo kiam la tunelo leviĝas, aŭ ke nur kelkaj oficejaj gastigantoj respondas.
Prefiksoj, kiuj nur aspektas similaj, estas alia kazo, kaj kompari okedojn per la okulo ne estas prefiksa komparo. Skribu ambaŭ kaj kalkulu la maskitajn bitojn: 192.168.4.0/24 kontraŭ 192.168.6.0/24 kongruas ĝis bito 22 kaj diverĝas ĉe bito 23, ĉar la tria okedo legeblas 00000100 kontraŭ 00000110, do tiuj du retoj estas vere apartaj. Metu 10.8.0.0/24 apud alian 10.8.0.0/24 kaj ĉiuj 24 maskitaj bitoj kongruas, kio signifas, ke unu itinero ne povas esprimi ambaŭ lokojn. La maska longo decidas, kie la komparo haltas, kaj la reto instalita due estas tiu, kiu malvenkas.
Kion itinerigita ligo ne povas liveri
Dissendo kaj multdissendo ne vojaĝas trans itinerigitan ligon, kaj pluraj konataj funkcioj konstruiĝas sur ili. Foliumlistoj, nomaj anoncoj kaj serva eltrovo ĉiuj supozas komunan segmenton, do dosieruja servilo povas respondi ĉiun peton per adreso kaj tamen neniam aperi en listo. Noma solvo dependanta de loka dissendo de la ligo fiaskas pro la sama kialo, kaj neniu profila redakto ŝanĝas, kion la tunelo kapablas porti. Ĉu tio gravas, estas demando pri postuloj, ne pri itinerigado.
Kliento, kiu vere bezonas tiujn liverojn, postulas pontitan interfacon, kiu portas Ethernet-kadrojn kaj tial konservas la dissendan domajnon. La prezo estas pli brua ligo, la perdo de la pura adresado priskribita supre, kaj multe pli granda panea surfaco kiam aperas bukloj. Pravigu la postulon antaŭ ol ŝanĝi, kaj preferu noman servon, kiu funkcias super itinerigitaj ligoj, kiam la postulo temas nur pri nomoj.
Legi la interfacon antaŭ ol redakti la profilon
Demandu la kernon, kion ĝi instalas, anstataŭ kion la profilo ŝajne diras. La adresa eligo montras la samtavolanon, kiu klarigas la maskon, kaj la itinera eligo montras, ĉu ekzistas vojo al ĝi. Ruli ambaŭ kontraŭ la tunela aparato daŭras momenton kaj solvas la demandon.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1
Se tiuj tri kongruas, la profilo faras tion, por kio ĝi agordiĝis, kaj la restanta problemo kuŝas aliloke. Ŝanĝu la topologion nur pro kialo, kiu nomas mankan kapablon, ĉar nekonata masko ne estas tia.