Tas tunelio adresas yra partneris, o ne naršytinas potinklis
Taško taškas nuorodos kaukė aprašo tolimąjį galą, o ne kaimynų diapazoną. Perskaitykite partnerio adresą, prieš nuspręsdami, kad potinklis atrodo neteisingai.
Jūsų klientas prisijungia ir rodo adresų porą arba vieną adresą su 255.255.255.255 kauke, ir pirmoji reakcija yra, kad serveris išdavė ką nors sulaužyta. Niekas nesulaužyta: tunelio sąsaja yra taško taškas nuoroda, o kaukė aprašo tolimąjį tos vienos nuorodos galą, o ne kaimynų diapazoną. Poros skaitymas kaip vietinio ir partnerio paaiškina keistą kaukę, šalia esantį vieno mazgo maršrutą ir trūkstamą kaimynų lentelę. Ko ta pati skaitymo logika nepateisina, tai adresų planas, kuris persidengia su biuro tinklu.
Kodėl kaukė tunelio nuorodoje atrodo neteisingai
Ethernet sąsajoje adresas ir kaukė teigia du dalykus: šis mazgas valdo adresą, o viskas priešdėlio viduje yra tiesioginis kaimynas. Branduolys iš šių dviejų faktų išveda maršrutą nuorodoje ir tada sprendžia nuorodos adresus tiems kaimynams, kuriuos laiko esančiais. Taško taškas sąsaja išlaiko nuosavybę ir atmeta kaimynus, todėl antrasis adresas kliento eilutėje yra tolimasis galas, o ne kitas mazgas bendrame segmente. Nėra aparatinio adresavimo, sprendimo srauto ir transliacijos srities, prie kurios prisijungti, todėl sąsaja elgiasi kaip vamzdis su tiksliai vienu tikslu.
Štai kodėl vieno mazgo maršrutas šalia plačios kaukės čia yra normalus, o ne simptomas. Pasiekiamumas šioje nuorodoje reiškia vieną adresą, ir branduolys užrašo būtent tai. Skaitykite abu adresus kartu prieš nuspręsdami, kad konfigūracija neteisinga, nes kiekvienas atskirai atrodo kaip klaida.
Dvi topologijos, dvi adreso formos
Senoji taško taškas topologija kiekvienam klientui duoda mažą bloką ir naudoja du vidurinius adresus, todėl kaukė atrodo kaip tinklo gabalas, o ne kaip telkinys. Potinklio topologija iš telkinio duoda adresą su telkinio kauke ir serverio tunelio adresą vadina partneriu. Abi sukuria galiojančią nuorodą, ir jos skiriasi tik tuo, kurie adresai atsiranda profilyje ir kurią kaukę naudotojas greičiausiai kvestionuos.
| 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 |
Kuri eilutė atitinka jūsų klientą, pirmiausia skaitykite partnerį, nes jis įvardija tolimąjį galą ir todėl paaiškina kaukę. Profilis, nukopijuotas tarp serverių su skirtingomis topologijomis, parodys neteisingą formą savo naujiems namams, ir tą neatitikimą lengva supainioti su serverio gedimu.
Kai telkinys ir biuro tinklas reikalauja tų pačių bitų
Kadangi nuoroda yra maršrutizuota, telkiniui reikia priešdėlio, kurio nėra nė viename tinkle, kurį serveris gali pasiekti. Pasidalykite vienu ir klientas turi vieną maršrutą diapazonui, kuris reiškia dvi vietas, o kuri vieta laimės, sprendžia paskutinį kartą įdiegtas maršrutas. Gedimas pasireiškia kliente, nors sprendimas už jo priklauso adresų planui. Naudotojai praneša, kad vietinis maršrutizatorius dingsta pakilus tuneliui arba atsako tik kai kurie biuro mazgai.
Priešdėliai, kurie tik atrodo panašūs, yra kitas atvejis, o oktetų lyginimas akimis nėra priešdėlių lyginimas. Užrašykite abu ir suskaičiuokite užmaskuotus bitus: 192.168.4.0/24 prieš 192.168.6.0/24 sutampa iki 22 bito ir išsiskiria ties 23 bitu, nes trečiasis oktetas skaitomas kaip 00000100 prieš 00000110, todėl tie du tinklai tikrai atskiri. Padėkite 10.8.0.0/24 prie kito 10.8.0.0/24 ir visi 24 užmaskuoti bitai sutampa, o tai reiškia, kad vienas maršrutas negali išreikšti abiejų vietų. Kaukės ilgis sprendžia, kur lyginimas sustoja, ir antras įdiegtas tinklas yra tas, kuris pralaimi.
Ko maršrutizuota nuoroda negali pristatyti
Transliacija ir daugiatransliacija nekeliauja per maršrutizuotą nuorodą, ir kelios pažįstamos funkcijos yra jomis pagrįstos. Naršymo sąrašai, vardų skelbimai ir paslaugų aptikimas visi numato bendrą segmentą, todėl failų serveris gali atsakyti į kiekvieną užklausą pagal adresą ir vis tiek niekada neatsirasti sąraše. Vardų sprendimas, priklausantis nuo nuorodos vietinės transliacijos, žlunga dėl tos pačios priežasties, ir joks profilio keitimas nepakeičia to, ką tunelis gali pernešti. Ar tai svarbu, yra reikalavimų, o ne maršrutizavimo klausimas.
Klientas, kuriam tikrai reikia tų pristatymų, reikalauja sujungtos sąsajos, kuri perneša Ethernet kadrus ir todėl išlaiko transliacijos sritį. Kaina yra triukšmingesnė nuoroda, aukščiau aprašyto švaraus adresavimo praradimas ir daug didesnis gedimų plotas, kai atsiranda kilpų. Pagrįskite reikalavimą prieš perjungdami ir pirmenybę teikite vardų tarnybai, kuri veikia per maršrutizuotas nuorodas, kai reikalavimas susijęs tik su vardais.
Sąsajos skaitymas prieš redaguojant profilį
Klauskite branduolio, ką jis įdiegė, o ne ką tarsi sako profilis. Adresų išvestis rodo partnerį, kuris paaiškina kaukę, o maršrutų išvestis rodo, ar yra kelias į jį. Abiejų paleidimas prieš tunelio įrenginį užima akimirką ir išsprendžia klausimą.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1
Jei šie trys sutampa, profilis daro tai, kam buvo sukonfigūruotas, o likusi problema yra kitur. Keiskite topologiją tik dėl priežasties, kuri įvardija trūkstamą galimybę, nes nepažįstama kaukė tokia nėra.