OpenVPN-pushruter installeres ikke: timing, rettigheder eller politik

Serveren siger, at den har pushet ruten, klienten siger, at den er forbundet, og destinationen er stadig uopnåelig. Tre årsager giver præcis det billede. Rute-tilføjelsen kørte, før enheden fandtes, klienten manglede rettigheder til at ændre tabellen, eller en politik instruerede klienten i at ignorere pushede muligheder.

Udefra ser de identiske ud og kræver forskellige rettelser. Læs klientloggen på det punkt, hvor rutens beslutning træffes.

Bevis, at ruten mangler, ikke bare at den er brudt

Begynd med at bevise, at ruten mangler frem for at være brudt. På Linux viser ip route show dev tun0, hvad klienten har installeret på tun-enheden. På Windows viser route print eller Get-NetRoute det samme i tabelform.

En rute, der findes, men ikke videresender trafik, er et andet problem. Det flytter undersøgelsen til videresendelses- og firewallregler, ikke til ruteinstallation.

Timing: tilføjelsen kørte, før enheden fandtes

Klienten parser serverens PUSH_REPLY, efter at kontrolkanalen er oppe, og efter at den har konfigureret grænsefladen. Først da rører den rutetabellen med den mekanisme, platformen stiller til rådighed. Linux går gennem netlink; Windows bruger en API, der kræver et forhøjet token. Et script eller en klient, der tilføjer ruter, så snart den læser konfigurationen, kan køre, før TUN/TAP-enheden findes, og kernen afviser tilføjelsen.

Det samme kapløb forklarer, hvorfor en håndskrevet rute virker, mens den automatiske ikke gør: når du skriver den, er grænsefladen allerede oppe.

route-delay findes til netop dette tilfælde, og route-up peger på et script, der kører, efter at grænsefladen og ruterne er konfigureret. Læg ruter, der afhænger af tunneladressen, i det hook frem for i en tidlig fase.

Rettigheder: hvem må ændre tabellen

Ændring af Windows-rutetabellen kræver et forhøjet token. En GUI startet af en standardbruger kan sætte adapteradressen gennem tjenesten og stadig ikke kunne tilføje en rute. Loggen viser så en fejl af typen adgang nægtet i stedet for et manglende push.

At starte GUI'en som administrator eller bruge den tjenestebaserede klient ændrer det resultat. En planlagt opgave, der starter klienten uden det krævede token, gør det ikke.

Kontroller hvilken konto klienten faktisk kører som, før du ændrer noget. Versionen og tjenestetilstanden afgør, hvilke årsager der overhovedet er mulige, så notér begge ved siden af ruteoutputtet.

Politik: pushede ruter kan kasseres med vilje

route-nopull får klienten til at ignorere ruter, som serveren pusher, herunder en pushet standardrute, mens tunneladressen stadig accepteres. Pushede DNS- og DHCP-muligheder droppes af samme direktiv. En sådan klient er ikke defekt; den forventer eksplicitte rute-linjer i sin egen konfiguration.

route-noexec er en anden kontrol: den stopper klienten helt i at udføre ruteændringer. En topologi, som klienten ikke kan kortlægge, kan give et lignende resultat, hvor ruten logges som afvist i stedet for tilføjet. Læs den loglinje, der rapporterer beslutningen, i stedet for at gætte, hvilken af de tre der gælder. Kontroller derefter den effektive profil, fordi en importør eller et administrationsværktøj kan tilføje muligheder, som brugeren aldrig har redigeret.

En profil, der ser ren ud i en teksteditor, kan stadig bære et tilføjet direktiv under kørsel.

Sammenlign pushlisten med tabellen

Efter forbindelsen sætter du serverens pushliste ved siden af klientens tabel. På Linux er det ip route show dev tun0; på Windows route print eller Get-NetRoute. Hvis ruten mangler, så ret installationen først. Hvis den findes, og trafikken fejler, gå videre til videresendelses- og firewallpolitik.

Notér klientversionen, den konto den kører som, og om den er tjenestebaseret. De tre fakta fortæller den næste person, hvilke årsager der er udelukket.