Tuo tunneliosoite on vastapuoli, ei selattava aliverkko
Piste-piste-linkin peite kertoo kauko päästä, ei naapurien vaihteluvälistä. Lue vastapuolen osoite ennen kuin päättelet, että aliverkko näyttää väärältä.
Asiakkaasi yhdistää ja näyttää osoiteparin, tai yhden osoitteen, jolla on 255.255.255.255 peite, ja ensimmäinen reaktio on, että palvelin antoi jotain rikkinäistä. Mikään ei ole rikki: tunneloidun rajapinnan linkki on piste-piste, ja peite kuvaa tuon yhden linkin kauko päätä, ei naapurien vaihteluväliä. Parin lukeminen paikallisena osoitteena ja vastapuolena selittää oudon peitteen, sen vieressä olevan yhden isännän reitin ja puuttuvan naapuritaulun. Sitä sama lukutapa ei anna anteeksi: osoitesuunnitelmaa, joka menee päällekkäin toimistoverkon kanssa.
Miksi peite näyttää väärältä tunnelilinkillä
Ethernet-rajapinnalla osoite ja peite sanovat kaksi asiaa: tämä isäntä omistaa osoitteen, ja kaikki etuliitteen sisällä on suora naapuri. Ydin johtaa näistä kahdesta tosiasiasta linkin reitin ja ratkaisee sitten linkin osoitteet naapureille, joiden uskoo olevan läsnä. Piste-piste-rajapinta säilyttää omistuksen ja pudottaa naapurit, joten asiakasrivin toinen osoite on kauko pää, ei toinen isäntä jaetulla segmentillä. Laitteisto-osoitusta, ratkaisuliikennettä ja liittymiskelpoista lähetysaluetta ei ole, minkä vuoksi rajapinta käyttäytyy kuin putki, jolla on täsmälleen yksi kohde.
Siksi myös yhden isännän reitti leveän peitteen vieressä on täällä normaali, ei oire. Tavoitettavuus tällä linkillä tarkoittaa yhtä osoitetta, ja ydin kirjaa juuri sen. Lue kaksi osoitetta yhdessä ennen kuin päättelet, että kokoonpano on väärä, koska kumpikin yksin näyttää virheeltä.
Kaksi topologiaa, kaksi osoitemuotoa
Vanhempi piste-piste-topologia antaa jokaiselle asiakkaalle pienen lohkon ja käyttää kahta keskimmäistä osoitetta, joten peite näyttää verkon kappaleelta eikä poolilta. Aliverkkotopologia jakaa osoitteen poolista poolin peitteellä ja nimeää palvelimen tunneliosoitteen vastapuoleksi. Molemmat tuottavat kelvollisen linkin, ja ne eroavat vain siinä, mitkä osoitteet näkyvät profiilissa ja mitä peitettä käyttäjä todennäköisesti kyseenalaistaa.
| 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 |
Mikä tahansa rivi sopii asiakkaaseesi, lue ensin vastapuoli, koska se nimeää kauko pään ja selittää siksi peitteen. Erilaisten topologioiden palvelimien välillä kopioitu profiili näyttää väärän muodon uudelle kodilleen, ja tuo epäsuhta sekoitetaan helposti palvelinvikaan.
Kun pooli ja toimistoverkko vaativat samoja bittejä
Koska linkki on reititetty, pooli tarvitsee etuliitteen, jota ei esiinny missään verkoista, joihin palvelin pääsee. Jaa yksi, ja asiakkaalla on yksi reitti vaihteluvälille, joka tarkoittaa kahta paikkaa, ja viimeksi asennettu reitti ratkaisee, kumpi paikka voittaa. Vika näkyy asiakkaalla, vaikka sen takana oleva päätös kuuluu osoitesuunnitelmaan. Käyttäjät raportoivat, että paikallinen reititin katoaa, kun tunneli nousee, tai että vain osa toimiston isännistä vastaa.
Etuliitteet, jotka vain näyttävät samanlaisilta, ovat toinen tapaus, eikä oktettien silmämääräinen vertailu ole etuliitteen vertailu. Kirjoita molemmat ja laske peitetyt bitit: 192.168.4.0/24 vastaan 192.168.6.0/24 täsmäävät bittiin 22 asti ja eroavat bitissä 23, koska kolmas oktetti luetaan 00000100 vastaan 00000110, joten nuo kaksi verkkoa ovat todella erillisiä. Aseta 10.8.0.0/24 toisen 10.8.0.0/24 viereen ja kaikki 24 peitettyä bittiä täsmäävät, mikä tarkoittaa, että yksi reitti ei voi ilmaista molempia paikkoja. Peitteen pituus ratkaisee, mihin vertailu pysähtyy, ja toiseksi asennettu verkko on se, joka häviää.
Mitä reititetty linkki ei voi toimittaa
Lähetys ja multicast eivät kulje reititetyn linkin yli, ja useat tutut ominaisuudet rakentuvat niiden varaan. Selausluettelot, nimitiedotukset ja palvelunhaku olettavat jaetun segmentin, joten tiedostopalvelin voi vastata jokaiseen pyyntöön osoitteella ja silti olla koskaan näkymättä luettelossa. Linkin paikallisesta lähetyksestä riippuva nimien ratkaisu epäonnistuu samasta syystä, eikä mikään profiilin muokkaus muuta sitä, mitä tunneli pystyy kuljettamaan. Onko sillä väliä, on vaatimuskysymys, ei reitityskysymys.
Asiakas, joka todella tarvitsee nuo toimitukset, vaatii sillatun rajapinnan, joka kuljettaa Ethernet-kehyksiä ja säilyttää siksi lähetysalueen. Hinta on meluisampi linkki, yllä kuvatun puhtaan osoituksen menetys ja paljon suurempi vikapinta, kun silmukoita ilmaantuu. Perustele vaatimus ennen vaihtamista ja suosi nimipalvelua, joka toimii reititettyjen linkkien yli, kun vaatimus koskee vain nimiä.
Rajapinnan lukeminen ennen profiilin muokkaamista
Kysy ytimeltä, mitä se asensi, älä sitä, mitä profiili näyttää sanovan. Osoitetuloste näyttää vastapuolen, joka selittää peitteen, ja reittituloste näyttää, onko sinne polkua. Molempien ajaminen tunnelilaitetta vasten vie hetken ja ratkaisee kysymyksen.
ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1Jos nuo kolme täsmäävät, profiili tekee sen, mihin se konfiguroitiin, ja jäljellä oleva ongelma on muualla. Vaihda topologiaa vain syystä, joka nimeää puuttuvan kyvyn, koska tuntematon peite ei ole sellainen.