Ruter OpenVPN skyver ut, blir ikke installert: tidspunkt, rettigheter eller policy

Serveren sier at den har pushet ruten, klienten sier at den er tilkoblet, og destinasjonen er fortsatt utilgjengelig. Tre årsaker gir nøyaktig det bildet. Rute-tilføyelsen kjørte før enheten fantes, klienten manglet rettigheter til å endre tabellen, eller en policy ba klienten ignorere pushede alternativer.

Utenfra ser de identiske ut og krever forskjellige rettelser. Les klientloggen på punktet der rutens beslutning tas.

Bevis at ruten mangler, ikke bare at den er ødelagt

Begynn med å bevise at ruten mangler i stedet for å være ødelagt. På Linux viser ip route show dev tun0 hva klienten har installert på tun-enheten. På Windows viser route print eller Get-NetRoute det samme i tabellform.

En rute som finnes, men ikke videresender trafikk, er et annet problem. Det flytter undersøkelsen til videresendings- og brannmurregler, ikke til ruteinstallasjon.

Tidspunkt: tilføyelsen kjørte før enheten fantes

Klienten analyserer serverens PUSH_REPLY etter at kontrollkanalen er oppe og etter at den har konfigurert grensesnittet. Først da berører den rutetabellen, med den mekanismen plattformen tilbyr. Linux går gjennom netlink; Windows bruker et API som krever et forhøyet token. Et skript eller en klient som legger til ruter så snart den leser konfigurasjonen, kan kjøre før TUN/TAP-enheten finnes, og kjernen avviser tilføyelsen.

Det samme kappløpet forklarer hvorfor en håndskrevet rute virker mens den automatiske ikke gjør: når du skriver den, er grensesnittet allerede oppe.

route-delay finnes for dette tilfellet, og route-up navngir et skript som kjører etter at grensesnittet og rutene er konfigurert. Legg ruter som avhenger av tunneladressen i den kroken, ikke i en tidlig fase.

Rettigheter: hvem kan endre tabellen

Å endre Windows-rutetabellen krever et forhøyet token. En GUI startet av en vanlig bruker kan sette adapteradressen gjennom tjenesten og likevel ikke kunne legge til en rute. Loggen viser da en feil av typen tilgang nektet i stedet for en manglende push.

Å starte GUI-en som administrator, eller bruke den tjenestebaserte klienten, endrer det resultatet. En planlagt oppgave som starter klienten uten det nødvendige tokenet, gjør det ikke.

Kontroller hvilken konto klienten faktisk kjører som før du endrer noe. Versjonen og tjenestemodusen avgjør hvilke årsaker som i det hele tatt er mulige, så noter begge ved siden av ruteutdataene.

Policy: pushede ruter kan forkastes med vilje

route-nopull får klienten til å ignorere ruter serveren skyver ut, inkludert en pushet standardrute, mens tunneladressen fortsatt godtas. Pushede DNS- og DHCP-alternativer forkastes av samme direktiv. En slik klient er ikke defekt; den forventer eksplisitte rutelinjer i sin egen konfigurasjon.

route-noexec er en annen kontroll: den stopper klienten helt fra å utføre ruteendringer. En topologi klienten ikke kan kartlegge, kan gi et lignende resultat, og ruten logges som avvist i stedet for lagt til. Les logglinjen som rapporterer beslutningen, i stedet for å gjette hvilken av de tre som gjelder. Kontroller deretter den effektive profilen, fordi en importør eller et administrasjonsverktøy kan legge til alternativer brukeren aldri har redigert.

En profil som ser ren ut i en teksteditor, kan fortsatt bære et tilføyd direktiv under kjøring.

Sammenlign pushlisten med tabellen

Etter tilkobling setter du serverens pushliste ved siden av klientens tabell. På Linux er det ip route show dev tun0; på Windows route print eller Get-NetRoute. Hvis ruten mangler, rett installasjonen først. Hvis den finnes og trafikken svikter, gå videre til videresendings- og brannmurpolicy.

Noter klientversjonen, kontoen den kjører som, og om den er tjenestebasert. De tre faktaene forteller neste person hvilke årsaker som er utelukket.