Ai adresë tuneli është një palë, jo një nënrrjet që mund ta shfletosh
Maska në një lidhje pikë-për-pikë përshkruan skajin e largët, jo një varg fqinjësh. Lexo adresën e palës përpara se të vendosësh që nënrrjeti duket i gabuar.
Klienti yt lidhet dhe shfaq një çift adresash, ose një adresë të vetme me 255.255.255.255 maskë, dhe reagimi i parë është se serveri dha diçka të prishur. Asgjë nuk është e prishur: një ndërfaqe e tunelizuar është një lidhje pikë-për-pikë, dhe maska përshkruan skajin e largët të asaj lidhjeje të vetme, jo një varg fqinjësh. Leximi i çiftit si adresë vendore dhe palë shpjegon maskën e çuditshme, rrugën për një host të vetëm pranë saj dhe tabelën e fqinjëve që mungon. Ajo që i njëjti lexim nuk e justifikon është një plan adresash që mbivendoset me rrjetin e zyrës.
Pse maska duket e gabuar në një lidhje tuneli
Në një ndërfaqe Ethernet, një adresë dhe një maskë pohojnë dy gjëra: ky host zotëron adresën, dhe gjithçka brenda prefiksit është fqinj i drejtpërdrejtë. Bërthama nxjerr një rrugë në lidhje nga këto dy fakte dhe më pas zgjidh adresat e lidhjes për fqinjët që mendon se janë të pranishëm. Një ndërfaqe pikë-për-pikë ruan pronësinë dhe i heq fqinjët, prandaj adresa e dytë në rreshtin e klientit është skaji i largët dhe jo një host tjetër në një segment të përbashkët. Nuk ka adresim harduerik, trafik zgjidhjeje dhe as një domen transmetimi për t’u bashkuar, prandaj ndërfaqja sillet si një tub me saktësisht një destinacion.
Kjo është arsyeja pse një rrugë për një host të vetëm pranë një maske të gjerë është normale këtu dhe jo një simptomë. Arritshmëria në këtë lidhje do të thotë një adresë, dhe bërthama shkruan pikërisht atë. Lexo të dyja adresat bashkë përpara se të vendosësh që konfigurimi është i gabuar, sepse secila më vete duket si gabim.
Dy topologji, dy forma adrese
Topologjia më e vjetër pikë-për-pikë i jep çdo klienti një bllok të vogël dhe përdor dy adresat e mesit, prandaj maska duket si fragment i një rrjeti dhe jo si pishinë. Topologjia e nënrrjetit jep një adresë nga pishina me maskën e pishinës dhe e quan adresën e tunelit të serverit pala. Të dyja prodhojnë një lidhje të vlefshme, dhe ndryshojnë vetëm në atë se cilat adresa shfaqen në profil dhe në maskën që një përdorues ndoshta do ta vërë në pikëpyetje.
| 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 |
Cilido rresht që përputhet me klientin tënd, lexo fillimisht palën, sepse emërton skajin e largët dhe prandaj shpjegon maskën. Një profil i kopjuar midis serverëve me topologji të ndryshme do të tregojë formën e gabuar për shtëpinë e tij të re, dhe ajo mospërputhje ngatërrohet lehtë me një defekt serveri.
Kur pishina dhe rrjeti i zyrës kërkojnë të njëjtat bit
Meqenëse lidhja është e rrugëzuar, pishina ka nevojë për një prefiks që nuk shfaqet askund midis rrjeteve që serveri mund të arrijë. Ndaj një dhe klienti mban një rrugë të vetme për një varg që nënkupton dy vende, dhe cili vend fiton e vendos rruga e instalur e fundit. Defekti shfaqet te klienti, ndonëse vendimi pas tij i përket planit të adresave. Ajo që raportojnë përdoruesit është se ruteri vendor zhduket kur tuneli ngrihet, ose se përgjigjen vetëm disa host-e zyre.
Prefikset që thjesht duken të ngjashëm janë një rast tjetër, dhe krahasimi i okteteve me sy nuk është krahasim prefiksesh. Shkruaj të dyja dhe numëro bit-et e maskuar: 192.168.4.0/24 kundrejt 192.168.6.0/24 përputhen deri në bit 22 dhe ndryshojnë në bit 23, sepse okteti i tretë lexohet si 00000100 kundrejt 00000110, prandaj ato dy rrjete janë vërtet të ndara. Vendos 10.8.0.0/24 pranë një 10.8.0.0/24 tjetër dhe të gjitha 24 bit-et e maskuar përputhen, që do të thotë se një rrugë nuk mund të shprehë të dyja vendet. Gjatësia e maskës vendos ku ndalon krahasimi, dhe rrjeti i instalur i dyti është ai që humbet.
Çfarë një lidhje e rrugëzuar nuk mund të dorëzojë
Transmetimi dhe multicast nuk kalojnë një lidhje të rrugëzuar, dhe disa funksione të njohura ndërtohen mbi to. Listat e shfletimit, shpalljet e emrave dhe zbulimi i shërbimeve të gjitha supozojnë një segment të përbashkët, prandaj një server skedarësh mund t’i përgjigjet çdo kërkese sipas adresës dhe gjithsesi nuk shfaqet kurrë në një listë. Zgjidhja e emrave që varet nga transmetimi lokal i lidhjes dështon për të njëjtën arsye, dhe asnjë redaktim i profilit nuk ndryshon atë që tuneli mund të mbajë. Nëse kjo ka rëndësi është çështje kërkesash, jo rrugëzimi.
Një klient që ka vërtet nevojë për ato dorëzime kërkon një ndërfaqe të urëzuar, e cila mbart kuadro Ethernet dhe prandaj ruan domenin e transmetimit. Çmimi është një lidhje më e zhurmshme, humbja e adresimit të pastër të përshkruar më sipër, dhe një sipërfaqe dështimesh shumë më e madhe sapo shfaqen sythe. Arsyeto kërkesën përpara se të ndërrosh, dhe prefero një shërbim emrash që funksionon mbi lidhje të rrugëzuara kur kërkesa ka të bëjë vetëm me emra.
Leximi i ndërfaqes përpara redaktimit të profilit
Pyet bërthamën se çfarë instaloi, jo çfarë duket se thotë profili. Dalja e adresave tregon palën që shpjegon maskën, dhe dalja e rrugëve tregon nëse ekziston një rrugë drejt saj. Ekzekutimi i të dyjave kundrejt pajisjes së tunelit merr një moment dhe e zgjidh çështjen.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1
Nëse këto tri përputhen, profili bën atë për të cilën u konfigurua, dhe problemi i mbetur është diku tjetër. Ndrysho topologjinë vetëm për një arsye që emërton një aftësi që mungon, sepse një maskë e panjohur nuk është e tillë.