Å kopiere /32-en til tunnelen ruter ikkje kontorundernettet

VPN-en koplar til, grensesnittet viser ei adresse med ei trettito bits maske, og kontorserveren blir verande utilgjengeleg. Det neste trekket er ofte å bruke maska om att i ei rute, ut frå teorien om at grensesnittet skildrar kva tunnelen kan nå. Det gjer han ikkje. Adressa skildrar den lokale enden av ei punkt-til-punkt-lenkje, og destinasjonen du bryr deg om, ligg i eit anna prefiks på den andre sida.

To ulike ting blir blanda saman: adressa tunnelen gav deg, og nettverket du vil nå gjennom han.

To adresser, to jobbar

På ein punkt-til-punkt-tunnel er klientadressa ofte éi einskild vertsadresse fordi det er nøyaktig éin peer i den andre enden av lenkja. Det finst ikkje noko delt segment og ingen ARP, så ei maske som ville sett absurd ut på Ethernet, er heilt normal her.

Destinasjonsprefikset er eit faktum om kontornettverket, ikkje om tunnelen. Viss du treng éin server, er ruta ei vertsrute for den serveren. Viss du treng heile kontorundernettet, er ruta undernettet. Ingen av dei to svara kan lesast av grensesnittet, og å velje eitt fordi det dukka opp ved sida av tunneladressa, er korleis eit fungerande oppsett blir øydelagt.

Den tredje rada er der optimisme blir eit avbrot. Å rute eit heilt privat område inn i ein tunnel som berre tener éin stad, skuv framand trafikk inn på ein veg som ikkje kan levere han, og feila som følgjer, ser ut som ein øydelagd VPN snarare enn ei for brei rute.

Vel prefikset ut frå kravet

Skriv kravet som ei setning før du rører ein profil: kva vertar må vere nåbare, og kva er det smalaste prefikset som dekkjer dei? Éin server er ei vertsrute. Eit undernett er ei undernettsrute. Eit område med undernett er eit samandrag, og eit samandrag er eit løfte om at kvar adresse inni er nåbar, noko som sjeldan er sant.

Sjekk deretter talet mot det kontoret faktisk brukar. Å kopiere eit prefiks frå ei chatmelding utan å stadfeste det mot adresseringsplanen til staden, er korleis ei rute endar med å peike på eit undernett ingen eig.

Hugs òg at ei rute er ein veg, ikkje ei løyve. Gatewayen bestemmer framleis om klienten din kan bruke destinasjonen, og ein teneste kan framleis avvise deg. Å installere ruta rett får pakken dit og svarar ingenting om autorisasjon.

Legg til i profilen, erstatt han aldri

Ruter i ein NetworkManager-profil er ein fleirverdseigenskap, og skilnaden mellom å setje og å leggje til er eitt teikn. Bruk plussforma for å leggje til ei oppføring og behalde alt som allereie er lagra.

nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
  +ipv4.routes "10.40.20.9/32"

Utan plusset erstattar tildelinga heile lista. På ein profil som allereie ber fleire prefiks, slettar det stille dei som verka, og symptomet kjem seinare som ein teneste som tidlegare var nåbar frå denne laptopen.

Bruk UUID i staden for namnet. Namn blir dupliserte etter gjenoppretting, og tilkoplinga du redigerer er kanskje ikkje den som ber trafikken din. Sjekk først om det finst ei identisk oppføring, fordi det å leggje til ein duplikat er uryddig sjølv når det er harmlaust.

Den referansen for ruteeigenskapar dokumenterer destinasjonen, det valfrie neste hoppet, metrikken og attributtsyntaksen for den installerte versjonen. Les han før du legg til eit neste hopp, fordi om eitt er nødvendig avheng av integrasjonen og topologien, og å gjette det frå den første adressa i ei grensesnittliste er ikkje ein metode.

Standardrute og DNS er separate avgjerder

Adding an office prefix says nothing about where the rest of your traffic goes. If policy requires ordinary internet traffic to stay outside the tunnel, that is the ipv4.never-default decision, and it belongs to whoever owns the connection policy rather than to whoever is fixing one unreachable server.

Automatiske ruter er den andre tingen ein ikkje bør forstyrre lettvint. Å undertrykkje dei for å løyse éi manglande oppføring kan fjerne fleire fungerande, og personen som føreslo det, såg vanlegvis på ein annan profil med andre push.

DNS har sin eigen veg og sine eigne feil. Eit namn som blir løyst til rett adresse via feil resolver, eller ein resolver som ikkje kan svare for den private sona, vil sjå ut som eit ruteproblem medan ruta er perfekt. Test adressa og namnet kvar for seg, og avgjer deretter kva lag som faktisk feila.

Kontroller kva som vart brukt

Ei lagra endring er ikkje ei brukt endring. Kopla til på nytt gjennom den støtta livssyklusen til behandlaren, og sjå deretter på den faktiske ruta til den tiltenkte destinasjonen og på policyreglane som avgjer kva tabell som blir konsultert.

Viss prefikset er der og tilkoplinga framleis feilar, har du flytta deg til eit anna problem: val av kjeldeadresse, ei returrute i den fjerne enden, eller ein teneste som avviser klienten din. Kvar av dei er ein betre stad å sjå enn profilen du allereie har retta.