Wijken geïmporteerde VPN-routes af van de werkende client? Vergelijk beide
Een opgeslagen NetworkManager-profiel en de daadwerkelijk geïnstalleerde routes zijn twee verschillende dingen. Vergelijk privé- en publieke bestemmingen voordat je iets wijzigt.
Een bepaalde privédienst antwoordt via de VPN terwijl gewoon internetverkeer zich heel anders gedraagt dan op de machine van een collega, en de verleiding is om te concluderen dat de Ubuntu-client kapot is. Die conclusie slaat een stap over. Een werkende privéoperatie en een afwijkend publiek pad zijn twee waarnemingen, en het verschil zit meestal in het verkeersbeleid dat elke client heeft geïnstalleerd, niet in de client zelf.
De opgeslagen configuratie vergelijken met de effectieve netwerkstatus kost drie commando’s en beantwoordt de vraag die het giswerk probeerde te beantwoorden.
Eerst het opgeslagen profiel, dan de effectieve status
Een geïmporteerde OpenVPN-verbinding wordt een eigen NetworkManager-profiel. Het .ovpn-bestand waaruit het kwam, is vanaf het moment dat de import klaar is niet langer de bron van waarheid, dus dat bestand later bewerken verandert niets aan de verbinding die je gebruikt. Dit is de eerste plek waar de vergelijking misgaat, en het gaat stil mis.
nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn
Lees de UUID als namen botsen; dubbele namen overleven herinstallaties en profielherstel, en je kunt een uur besteden aan het bewerken van de kopie die niet in gebruik is. De waarden die je ziet beschrijven de opgeslagen bedoeling: of het profiel de standaardroute mag nemen, welke routes zijn opgeslagen en welke resolvers en zoekdomeinen het vraagt. Ze beschrijven niet wat er gebeurde toen de verbinding werd geactiveerd, omdat een plugin of een push van de server status kan toevoegen die het profiel niet vermeldt. Daarom is het volgende commando belangrijk.
Kijk daarna wat het systeem werkelijk met die bedoeling heeft gedaan, inclusief beleidsregels en elke tabel in plaats van alleen de hoofdtabel. Opgeslagen eigenschappen zijn invoer, en de geïnstalleerde tabellen zijn het resultaat.
ip -4 rule show
ip -4 route show table all
Twee bestemmingen, één vergelijking
Kies één privébestemming die werkt en één gewone publieke bestemming en vraag de kernel welk pad elk zou nemen. Dit op beide machines doen is wat een vaag verschil in een concreet verschil verandert.
ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20
De adressen zijn voorbeelden die je door je eigen adressen vervangt; het gaat om het paar, niet om de getallen. Vergelijk de interface, het bronadres en de tabel die in elke uitvoer wordt genoemd. Wanneer de privé-opzoeking de tunnel noemt en de publieke opzoeking ook de tunnel noemt, heb je een volledige tunnel en heeft de andere client misschien een gesplitste, of omgekeerd.
Verlang niet dat de twee clients identieke tekst afdrukken. Een redirect-gateway def1 van OpenVPN wordt meestal uitgedrukt als twee halve-prefixroutes in plaats van één standaardroute, en een beheerder die ze anders weergeeft is daarmee niet fout. Beoordeel de dekking, die de opzoekingen laten zien, en niet de opmaak.
Waar de twee clients terecht verschillen
Clientstandaarden zijn beleidskeuzes en mogen van elkaar afwijken. Het ene product verkiest misschien een volledige tunnel, een ander houdt de lokale standaard en routeert alleen de privéprefixen, en een derde volgt wat de server heeft gepusht. Een verschil is pas een defect als het in tegenspraak is met de eis die je hebt gekregen.
Vergelijk elke client dus met de goedgekeurde bedoeling van gesplitste of volledige tunnel, niet met elkaar. Als de eis is dat privéverkeer de tunnel gebruikt en het lokale internetpad lokaal blijft, dan is een volledige tunnel de bug en is een gesplitste tunnel correct, ongeacht welke client wat deed. Schrijf de bedoeling op voordat je een van beide configuraties bekijkt, anders wordt de eerste client die je inspecteert stilletjes de standaard.
DNS is een tweede as en faalt onafhankelijk. Een correcte route kan nog steeds query’s sturen naar een resolver die de privézone niet kan beantwoorden, en een correcte resolver lost een verkeerde route niet op. Controleer beide, en beschouw een privénaam die wel resolvet terwijl een privéadres dat niet doet als bewijs dat de twee lagen afzonderlijk worden opgelost.
Houd de vergelijking schoon
Draai één verbindingseigenaar tegelijk. Een OpenVPN-sessie op de commandoregel naast het geïmporteerde profiel installeert zijn eigen routes en zijn eigen resolverstatus, en het resulterende mengsel is het gedrag van geen van beide clients. Breek de ene af voordat je de andere meet. Herstart als je niet zeker weet wat er nog status vasthoudt, want een verouderde route van een uur geleden ziet er precies uit als een beleidsprobleem.
Houd al het andere ook vast: hetzelfde endpoint, hetzelfde account, dezelfde softwareversies, hetzelfde netwerk. Een succes op de Windows-laptop van een collega test een andere client, een andere resolverintegratie en mogelijk een ander serverprofiel, dus het is geen bewijs over de Ubuntu-beheerder.
De IPv4-instellingenreferentie van NetworkManager definieert never-default en de opgeslagen route-eigenschappen precies, wat de moeite waard is om te lezen voordat je een beheerde waarde wijzigt. En onthoud de reikwijdte van deze vergelijking: die gaat over IPv4 en zegt niets over het bijbehorende IPv6-beleid, dat zijn eigen standaarden heeft en zijn eigen manier om je te verrassen.