Het /32 van de tunnel kopiëren routeert het kantoorsubnet niet
Het adres dat de VPN je adapter geeft, beschrijft de link, niet de bestemming. Voeg het resourceprefix toe aan het profiel en laat de standaardroute met rust.
De VPN verbindt, de interface toont een adres met een tweeëndertig bits masker, en de kantoorserver blijft onbereikbaar. De volgende stap is vaak dat masker hergebruiken in een route, in de veronderstelling dat de interface beschrijft wat de tunnel kan bereiken. Dat doet hij niet. Dat adres beschrijft het lokale uiteinde van een punt-tot-punt-verbinding, en de bestemming die u belangrijk vindt, ligt in een ander prefix aan de andere kant.
Er worden twee verschillende dingen verward: het adres dat de tunnel u gaf, en het netwerk dat u erdoor wilt bereiken.
Twee adressen, twee taken
Bij een punt-tot-punt-tunnel is het clientadres vaak één enkel hostadres, omdat er precies één peer aan de andere kant van de verbinding is. Er is geen gedeeld segment en geen ARP, dus een masker dat op Ethernet absurd zou lijken, is hier volkomen normaal.
Het bestemmingsprefix is een feit over het kantoornetwerk, niet over de tunnel. Als u één server nodig hebt, is de route een hostroute voor die server. Als u het hele kantoorsubnet nodig hebt, is de route het subnet. Geen van beide antwoorden is van de interface af te lezen, en er één kiezen omdat het naast het tunneladres verscheen, is hoe een werkende configuratie kapotgaat.
| What you need to reach | What to install |
|---|---|
| One server, nothing else | A host route for that address |
| The office subnet | A route for the subnet prefix |
| Everything in the private space | Only if the requirement says so, and only with the owner's approval |
Die derde rij is waar optimisme een storing wordt. Een heel privébereik in een tunnel routeren die maar één locatie bedient, duwt ongerelateerd verkeer naar een pad dat het niet kan afleveren, en de daaruit voortkomende fouten lijken op een kapotte VPN in plaats van een te brede route.
Kies het prefix uit de eis
Schrijf de eis als een zin voordat u een profiel aanraakt: welke hosts moeten bereikbaar zijn, en wat is het smalste prefix dat ze dekt? Eén server is een hostroute. Een subnet is een subnetroute. Een reeks subnetten is een samenvatting, en een samenvatting is een belofte dat elk adres erbinnen bereikbaar is, wat zelden waar is.
Controleer daarna het getal tegen wat het kantoor werkelijk gebruikt. Een prefix uit een chatbericht kopiëren zonder het te bevestigen tegen het adresseringsplan van de locatie, is hoe een route uiteindelijk naar een subnet wijst dat niemand bezit.
Bedenk ook dat een route een pad is, geen toestemming. De gateway beslist nog steeds of uw client de bestemming mag gebruiken, en een dienst kan u nog steeds weigeren. De route correct installeren brengt het pakket daar en beantwoordt niets over autorisatie.
Voeg toe aan het profiel, vervang het nooit
Routes in een NetworkManager-profiel zijn een eigenschap met meerdere waarden, en het verschil tussen instellen en toevoegen is één teken. Gebruik de plusvorm om een item toe te voegen en alles te behouden wat al is opgeslagen.
nmcli connection modify uuid 11111111-2222-4333-8444-555555555555 \
+ipv4.routes "10.40.20.9/32"Zonder de plus vervangt de toewijzing de hele lijst. Op een profiel dat al meerdere prefixen draagt, verwijdert dat stil degenen die werkten, en het symptoom komt later als een dienst die voorheen vanaf deze laptop bereikbaar was.
Gebruik de UUID in plaats van de naam. Namen worden na herstel gedupliceerd, en de verbinding die u bewerkt is misschien niet degene die uw verkeer draagt. Controleer eerst of er al een identiek item bestaat, want een duplicaat toevoegen is slordig, zelfs als het onschadelijk is.
De referentie voor route-eigenschappen documenteert de bestemming, de optionele volgende hop, de metriek en de attribuutsyntaxis voor de geïnstalleerde versie. Lees die voordat u een volgende hop toevoegt, want of er een nodig is, hangt af van de integratie en de topologie, en dat raden uit het eerste adres in een interfacelijst is geen methode.
Standaardroute en DNS zijn aparte beslissingen
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.
Automatische routes zijn het andere dat u niet lichtvaardig moet verstoren. Ze onderdrukken om één ontbrekend item op te lossen kan meerdere werkende verwijderen, en degene die dat voorstelde, keek meestal naar een ander profiel met andere pushes.
DNS heeft zijn eigen pad en zijn eigen fouten. Een naam die via de verkeerde resolver naar het juiste adres wordt omgezet, of een resolver die niet voor de privézone kan antwoorden, zal op een routeringsprobleem lijken terwijl de route perfect is. Test het adres en de naam afzonderlijk en beslis dan welke laag werkelijk faalde.
Controleer wat er is toegepast
Een opgeslagen wijziging is geen toegepaste wijziging. Maak opnieuw verbinding via de ondersteunde levenscyclus van de beheerder en kijk dan naar de werkelijke route naar de beoogde bestemming en naar de beleidsregels die bepalen welke tabel wordt geraadpleegd.
Als het prefix er is en de verbinding nog steeds mislukt, bent u naar een ander probleem overgestapt: keuze van bronadres, een retourroute aan de verre kant, of een dienst die uw client weigert. Elk daarvan is een betere plek om te kijken dan het profiel dat u al hebt gecorrigeerd.