VPN ansluter, gränssnittet visar en adress med en trettiotvåbitars mask, och kontorsservern förblir onåbar. Nästa steg är ofta att återanvända masken i en rutt, utifrån teorin att gränssnittet beskriver vad tunneln kan nå. Det gör den inte. Adressen beskriver den lokala änden av en punkt-till-punkt-länk, och destinationen du bryr dig om ligger i ett annat prefix på andra sidan.

Två olika saker blandas ihop: adressen tunneln gav dig och nätverket du vill nå genom den.

Två adresser, två uppgifter

På en punkt-till-punkt-tunnel är klientadressen ofta en enda värdadress eftersom det finns exakt en peer i andra änden av länken. Det finns inget delat segment och ingen ARP, så en mask som skulle se absurd ut på Ethernet är helt normal här.

Destinationsprefixet är ett faktum om kontorsnätet, inte om tunneln. Om du behöver en server är rutten en värdrutt för den servern. Om du behöver hela kontorssubnätet är rutten subnätet. Ingen av de två svaren kan läsas av från gränssnittet, och att välja ett för att det dök upp bredvid tunneladressen är hur en fungerande konfiguration går sönder.

What you need to reachWhat to install
One server, nothing elseA host route for that address
The office subnetA route for the subnet prefix
Everything in the private spaceOnly if the requirement says so, and only with the owner's approval

Den tredje raden är där optimism blir ett avbrott. Att routa ett helt privat område in i en tunnel som bara betjänar en plats knuffar orelaterad trafik in på en väg som inte kan leverera den, och felen som följer ser ut som en trasig VPN snarare än en för bred rutt.

Välj prefixet utifrån kravet

Skriv kravet som en mening innan du rör en profil: vilka värdar måste vara nåbara, och vilket är det smalaste prefixet som täcker dem? En server är en värdrutt. Ett subnät är en subnätsrutt. Ett område av subnät är en sammanfattning, och en sammanfattning är ett löfte att varje adress inom den är nåbar, vilket sällan stämmer.

Kontrollera sedan talet mot vad kontoret faktiskt använder. Att kopiera ett prefix från ett chattmeddelande utan att bekräfta det mot platsens adresseringsplan är hur en rutt till slut pekar på ett subnät som ingen äger.

Kom också ihåg att en rutt är en väg, inte ett tillstånd. Gatewayen avgör fortfarande om din klient får använda destinationen, och en tjänst kan fortfarande neka dig. Att installera rutten korrekt får paketet dit och svarar ingenting om auktorisering.

Lägg till i profilen, ersätt den aldrig

Rutter i en NetworkManager-profil är en flervärdsegenskap, och skillnaden mellan att sätta och att lägga till är ett tecken. Använd plusformen för att lägga till en post och behålla allt som redan är sparat.

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

Utan pluset ersätter tilldelningen hela listan. På en profil som redan bär flera prefix raderar det tyst dem som fungerade, och symptomet kommer senare som en tjänst som tidigare var nåbar från den här laptopen.

Använd UUID i stället för namnet. Namn dupliceras efter återställningar, och anslutningen du redigerar är kanske inte den som bär din trafik. Kontrollera först om det redan finns en identisk post, eftersom det är slarvigt att lägga till en dubblett även när den är harmlös.

Den referens för ruttsegenskaper dokumenterar destinationen, nästa hopp som valfri, metrik och attributsyntax för den installerade versionen. Läs den innan du lägger till ett nästa hopp, eftersom om ett behövs beror på integrationen och topologin, och att gissa det från den första adressen i en gränssnittslista är inte en metod.

Standardväg och DNS är separata beslut

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.

Automatiska rutter är det andra som man inte bör störa lättvindigt. Att undertrycka dem för att lösa en saknad post kan ta bort flera fungerande, och personen som föreslog det tittade oftast på en annan profil med andra push.

DNS har sin egen väg och sina egna fel. Ett namn som löses till rätt adress via fel resolver, eller en resolver som inte kan svara för den privata zonen, kommer att se ut som ett routingproblem medan rutten är perfekt. Testa adressen och namnet separat och avgör sedan vilket lager som faktiskt misslyckades.

Verifiera vad som tillämpades

En sparad ändring är inte en tillämpad ändring. Anslut igen via hanterarens stödda livscykel och titta sedan på den faktiska rutten till den avsedda destinationen och på policyreglerna som avgör vilken tabell som konsulteras.

Om prefixet finns där och anslutningen fortfarande misslyckas har du flyttat till ett annat problem: val av källadress, en returrutt i den bortre änden eller en tjänst som nekar din klient. Var och en av dem är en bättre plats att titta på än profilen du redan har rättat.

Relaterade artiklar