Kopiering af tunnellens /32 ruter ikke kontorundernettet

VPN’en forbinder, grænsefladen viser en adresse med en toogtredive bit maske, og kontorserveren forbliver uopnåelig. Det næste træk er ofte at genbruge masken i en rute, ud fra den teori at grænsefladen beskriver, hvad tunnelen kan nå. Det gør den ikke. Adressen beskriver den lokale ende af et punkt-til-punkt-link, og destinationen, du bekymrer dig om, ligger i et andet præfiks på den anden side.

To forskellige ting blandes sammen: adressen, som tunnelen gav dig, og netværket, du vil nå gennem den.

To adresser, to opgaver

På en punkt-til-punkt-tunnel er klientadressen ofte en enkelt værtsadresse, fordi der er præcis én peer i den anden ende af linket. Der er intet delt segment og ingen ARP, så en maske, der ville se absurd ud på Ethernet, er helt normal her.

Destinationspræfikset er et faktum om kontornetværket, ikke om tunnelen. Hvis du har brug for én server, er ruten en værtsrute til den server. Hvis du har brug for hele kontorundernettet, er ruten undernettet. Ingen af svarene kan læses af grænsefladen, og at vælge et af dem, fordi det dukkede op ved siden af tunneladressen, er hvordan et fungerende setup bliver ødelagt.

Den tredje række er, hvor optimisme bliver et afbrud. At rute et helt privat område ind i en tunnel, der kun betjener ét sted, skubber uvedkommende trafik ind i en vej, der ikke kan levere den, og de resulterende fejl ser ud som en ødelagt VPN snarere end en for bred rute.

Vælg præfikset ud fra kravet

Skriv kravet som en sætning, før du rører en profil: hvilke værter skal være nåbare, og hvad er det smalleste præfiks, der dækker dem? Én server er en værtsrute. Et undernet er en undernetsrute. Et interval af undernet er en opsummering, og en opsummering er et løfte om, at hver adresse indeni er nåbar, hvilket sjældent er sandt.

Kontroller derefter tallet mod det, kontoret faktisk bruger. At kopiere et præfiks ud af en chatbesked uden at bekræfte det mod stedets adresseringsplan er, hvordan en rute ender med at pege på et undernet, ingen ejer.

Husk også, at en rute er en vej, ikke en tilladelse. Gatewayen beslutter stadig, om din klient må bruge destinationen, og en tjeneste kan stadig afvise dig. At installere ruten korrekt får pakken derhen og svarer intet om autorisation.

Føj til profilen, erstat den aldrig

Ruter i en NetworkManager-profil er en flerværdiegenskab, og forskellen mellem at sætte og tilføje er ét tegn. Brug plusformen til at tilføje en post og bevare alt, der allerede er gemt.

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

Uden plus erstatter tildelingen hele listen. På en profil, der allerede bærer flere præfikser, sletter det lydløst dem, der virkede, og symptomet kommer senere som en tjeneste, der plejede at være nåbar fra denne laptop.

Brug UUID i stedet for navnet. Navne duplikeres efter gendannelse, og den forbindelse, du redigerer, er måske ikke den, der bærer din trafik. Kontroller først for en eksisterende identisk post, fordi det er sjusket at tilføje en dublet, selv når den er harmløs.

Den reference til rutegenskaber dokumenterer destinationen, det valgfrie næste hop, metrikken og egenskabssyntaksen for den installerede version. Læs den, før du tilføjer et næste hop, fordi om et er nødvendigt afhænger af integrationen og topologien, og at gætte det ud fra den første adresse i en grænsefladeliste 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 anden ting, man ikke skal forstyrre letsindigt. At undertrykke dem for at løse én manglende post kan fjerne flere fungerende, og personen, der foreslog det, kiggede normalt på en anden profil med andre pushes.

DNS har sin egen vej og sine egne fejl. Et navn, der opløses til den rigtige adresse via den forkerte resolver, eller en resolver, der ikke kan svare for den private zone, vil se ud som et ruteproblem, mens ruten er perfekt. Test adressen og navnet hver for sig, og beslut derefter, hvilket lag der faktisk fejlede.

Kontroller, hvad der blev anvendt

En gemt ændring er ikke en anvendt ændring. Genopret forbindelsen gennem managerens understøttede livscyklus, og se derefter på den faktiske rute til den tilsigtede destination og på de politikregler, der afgør, hvilken tabel der konsulteres.

Hvis præfikset er der, og forbindelsen stadig fejler, er du flyttet til et andet problem: valg af kildeadresse, en returrute i den fjerne ende eller en tjeneste, der afviser din klient. Hver af dem er et bedre sted at kigge end den profil, du allerede har rettet.