Hva OpenVPN route-nopull faktisk hindrer serveren i å dytte ut

Du satte route-nopull i en klientprofil for å hindre at tunnelen sluker standardruten din, og nå er kontorets subnett utilgjengelig mens klienten fortsatt sier at den er tilkoblet. Begge observasjonene er sanne, og ingenting har feilet. Flagget forteller klienten å hoppe over rutene og DHCP-oppføringene som serveren dytter ut, en snevrere instruks enn de fleste forventer når de legger den til. Det som gjenstår er en fungerende tunnel uten mening om hvilke mål som skal bruke den.

Det gapet er hele avgjørelsen denne artikkelen handler om. Enten beskriver serveren nettverket, eller så gjør klienten det, og flagget overlater den jobben til klienten uten å gjøre noe av den for deg.

Hva flagget slår av ved tilkobling

En OpenVPN-klient som drar, mottar normalt en pakke fra serveren etter autentisering: ruter, en omdirigering av standardgatewayen, DNS-servere og noen få justeringsdirektiver. Med route-nopull i kraft godtar klienten fortsatt økten, verifiserer fortsatt sertifikater, forhandler fortsatt om chiffere og keepalives, og bringer fortsatt grensesnittet opp. Det den slipper, er bruken av dyttede route-linjer og dyttede dhcp-option-linjer, DNS inkludert.

Forvirringen kommer fra en grønn indikator ved siden av en død applikasjon. Tunnelen finnes; kartleggingen fra mål til den tunnelen gjør det ikke. Ingenting i klientens statuspanel skiller «tilkoblet og ruter» fra «tilkoblet og inaktiv», fordi begge er samme tilstand sett fra tunnelens side.

Hvorfor en levende tunnel fortsatt ikke kan rute noe

Grensesnittet dukker opp med sin egen adresse og har på en punkt-til-punkt-lenke ofte ikke noe mer spesifikt enn en vertsrute til motparten. Et privat subnett blir bare tilgjengelig når en eller annen rute peker på det grensesnittet med riktig prefiks, og med dyttingen slått av kommer den ruten aldri. Den nedlastede profilen kan vanligvis heller ikke hjelpe, fordi den ble skrevet ut fra antakelsen om at serveren ville levere akkurat denne informasjonen. Derfor kan grensesnittet se sunt ut mens subnettet forblir mørkt.

Å lese profilen beviser derfor svært lite. Les den kjørende tilstanden i stedet, på den tilkoblede maskinen:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

En adresse uten subnett-rute i den andre kommandoen er signaturen på dette problemet. Den tredje kommandoen svarer deretter på spørsmålet brukerne faktisk bryr seg om, fordi den rapporterer grensesnittet kjernen ville valgt for et bestemt mål i stedet for listen du håpet den ville bruke. Hvis den svarer gjennom den fysiske lenken din, er tunnelen ikke på veien i det hele tatt.

Navneoppslag feiler av en beslektet grunn, ikke en separat. Dyttede dhcp-option DNS-oppføringer hoppes over av det samme flagget, så spørringer om interne verter går til den resolveren det lokale nettverket måtte ha stilt opp. Den resolveren har ingen sone for kontoret, så spørringen feiler eller returnerer et offentlig svar, og feilen ser ut som et serverproblem når det er et klientkonfigurasjonsproblem. Å teste en adresse før et navn er det som skiller de to.

Valget mellom flagget og et prefiksfilter

De to alternativene løser ulike former for samme klage, og et dårlig valg er det som skaper tilstanden tilkoblet-men-ubrukelig. Den ene erstatter den dyttede policyen helt, mens den andre redigerer den etter prefiks. Tabellen gir kortversjonen, og avsnittet etter den dekker delen som fanger folk.

pull-filter er en prefiksmatch med tre verb, så den kan godta en familie av linjer, ignorere dem stille eller avvise tilkoblingen helt når et prefiks dukker opp. Den siste oppførselen er den som er verdt å kjenne: en avvisningsregel gjør en policyuenighet til et mislykket håndtrykk i stedet for en stille utelatelse. OpenVPN 2.6-håndboken lister de godtatte prefiksene og den nøyaktige semantikken til hvert verb.

En vanlig mellomvei er å avvise bare redirect-gateway og la kontorets ruter og DNS komme som tiltenkt. Det holder dyttingen fungerende for delene serveren forstår bedre enn deg, samtidig som det hindrer den ene linjen som ville tatt over standardruten din.

Legge til ruter og en resolver for hånd

Hvis du beholder flagget, må profilen si det serveren ville sagt. Klientside-route-direktiver brukes etter at tilkoblingen er etablert, så de virker sammen med flagget i stedet for å bli blokkert av det. Legg dem i profilen, ikke på en interaktiv kommandolinje, ellers vil neste gjenoppkobling ikke gjenskape den fungerende tilstanden.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS-linjen står i en vanskelig posisjon: den er et klientside-direktiv, men noen klienter bruker den bare gjennom plattformens DNS-integrasjon, som kan overskrive den når lenken endres. På en systemd-vert er det mer forutsigbart å sette resolveren direkte på tunnelgrensesnittet enn å håpe at klienten vinner prioritetskonkurransen:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Rutedomenet betyr like mye som adressen. Uten det kan spørringer om offentlige navn også bli sendt til den interne resolveren, og enhver intern resolver som nekter rekursjon vil ødelegge surfing mens den private sonen fortsetter å virke. Med det sendes bare navn under det suffikset til tunnelresolveren, og alt annet følger den fysiske lenken.

Kontrollere resultatet: adresse, navn og den ytre veien

Tre tester skiller de mulige feilene. Hent den private adressen via IP, deretter samme vert via navn, deretter et vanlig offentlig nettsted. En fungerende IP med et feilende navn peker på resolveren; en feilende IP med et fungerende navn peker på rutingen; feiler begge, betyr det vanligvis at tunnelen ikke er på veien.

Se deretter utover i stedet for innover. Tunnelens egen rute til endepunktet må overleve endringen, og enhver blokkerende feil må være begrenset til tunnelen uten å fange endepunktet. En klient som fortsetter å surfe etter at tunnelen faller, er et politikkproblem, ikke et rutingproblem, og det vil ikke dukke opp i noen av de tre testene ovenfor.

Skriv den endelige listen inn i profilens dokumentasjon: rutene, resolveren, domenene og grunnen til at hver enkelt finnes. En gjenoppkobling som gjenskaper den samme tabellen, er det eneste beviset på at den lokale policyen er komplett. Hvis applikasjoner fortsatt feiler med tunnelen oppe og alle tre testene bestått, er det neste stedet å se klassen av tilkoblet-men-offline-problemer i stedet for sertifikater som allerede er verifisert.