Å kopiere tunnelens /32 ruter ikke kontorundernettet

VPN-en kobler til, grensesnittet viser en adresse med en trettito bits maske, og kontorserveren forblir utilgjengelig. Det neste trekket er ofte å gjenbruke masken i en rute, ut fra teorien om at grensesnittet beskriver hva tunnelen kan nå. Det gjør den ikke. Adressen beskriver den lokale enden av en punkt-til-punkt-lenke, og destinasjonen du bryr deg om, ligger i et annet prefiks på den andre siden.

To forskjellige ting blandes sammen: adressen tunnelen ga deg, og nettverket du vil nå gjennom den.

To adresser, to jobber

På en punkt-til-punkt-tunnel er klientadressen ofte en enkelt vertsadresse fordi det er nøyaktig én peer i den andre enden av lenken. Det finnes ikke noe delt segment og ingen ARP, så en maske som ville sett absurd ut på Ethernet, er helt normal her.

Destinasjonsprefikset er et faktum om kontornettverket, ikke om tunnelen. Hvis du trenger én server, er ruten en vertsrute for den serveren. Hvis du trenger hele kontorundernettet, er ruten undernettet. Ingen av de to svarene kan leses av grensesnittet, og å velge ett fordi det dukket opp ved siden av tunneladressen, er hvordan et fungerende oppsett blir ødelagt.

Den tredje raden er der optimisme blir et avbrudd. Å rute et helt privat område inn i en tunnel som bare betjener ett sted, skyver uvedkommende trafikk inn på en vei som ikke kan levere den, og feilene som følger, ser ut som en ødelagt VPN snarere enn en for bred rute.

Velg prefikset ut fra kravet

Skriv kravet som en setning før du rører en profil: hvilke verter må være nåbare, og hva er det smaleste prefikset som dekker dem? Én server er en vertsrute. Et undernett er en undernettsrute. Et område med undernett er et sammendrag, og et sammendrag er et løfte om at hver adresse inni er nåbar, noe som sjelden er sant.

Sjekk deretter tallet mot det kontoret faktisk bruker. Å kopiere et prefiks fra en chatmelding uten å bekrefte det mot stedets adresseringsplan, er hvordan en rute ender med å peke på et undernett ingen eier.

Husk også at en rute er en vei, ikke en tillatelse. Gatewayen bestemmer fortsatt om klienten din kan bruke destinasjonen, og en tjeneste kan fortsatt avvise deg. Å installere ruten riktig får pakken dit og svarer ingenting om autorisasjon.

Legg til i profilen, erstatt den aldri

Ruter i en NetworkManager-profil er en flerverdiegenskap, og forskjellen mellom å sette og å legge til er ett tegn. Bruk plussformen for å legge til en oppføring og beholde alt som allerede er lagret.

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

Uten plusset erstatter tilordningen hele listen. På en profil som allerede bærer flere prefikser, sletter det stille dem som virket, og symptomet kommer senere som en tjeneste som tidligere var nåbar fra denne laptopen.

Bruk UUID i stedet for navnet. Navn dupliseres etter gjenoppretting, og tilkoblingen du redigerer er kanskje ikke den som bærer trafikken din. Sjekk først om det finnes en identisk oppføring, fordi det å legge til en duplikat er uryddig selv når det er harmløst.

Den referansen for ruteegenskaper dokumenterer destinasjonen, det valgfrie neste hoppet, metrikken og attributtsyntaksen for den installerte versjonen. Les den før du legger til et neste hopp, fordi om ett er nødvendig avhenger av integrasjonen og topologien, og å gjette det fra den første adressen i en grensesnittliste er ikke en metode.

Standardrute og DNS er separate beslutninger

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 man ikke bør forstyrre lettvint. Å undertrykke dem for å løse én manglende oppføring kan fjerne flere fungerende, og personen som foreslo det, så vanligvis på en annen profil med andre push.

DNS har sin egen vei og sine egne feil. Et navn som løses til riktig adresse via feil resolver, eller en resolver som ikke kan svare for den private sonen, vil se ut som et ruteproblem mens ruten er perfekt. Test adressen og navnet hver for seg, og bestem deretter hvilket lag som faktisk feilet.

Kontroller hva som ble brukt

En lagret endring er ikke en brukt endring. Koble til på nytt gjennom behandlerens støttede livssyklus, og se deretter på den faktiske ruten til den tiltenkte destinasjonen og på policyreglene som avgjør hvilken tabell som konsulteres.

Hvis prefikset er der og tilkoblingen fortsatt feiler, har du flyttet deg til et annet problem: valg av kildeadresse, en returrute i den fjerne enden, eller en tjeneste som avviser klienten din. Hver av dem er et bedre sted å se enn profilen du allerede har rettet.