Hvad OpenVPN route-nopull faktisk forhindrer serveren i at skubbe ud

Du satte route-nopull i en klientprofil for at forhindre tunnelen i at sluge din standardrute, og nu er kontorets undernet utilgængeligt, mens klienten stadig siger, at den er forbundet. Begge observationer er sande, og intet er gået i stykker. Flaget fortæller klienten at springe de ruter og DHCP-poster over, som serveren skubber ud, hvilket er en smallere instruks, end de fleste forventer, når de tilføjer den. Det, der er tilbage, er en fungerende tunnel uden nogen mening om, hvilke destinationer der skal bruge den.

Det hul er hele beslutningen, som denne artikel handler om. Enten beskriver serveren netværket, eller også gør klienten det, og flaget giver den opgave til klienten uden at gøre noget af det for dig.

Hvad flaget slår fra ved forbindelse

En OpenVPN-klient, der trækker, tager normalt imod en pakke fra serveren efter godkendelse: ruter, en omdirigering af standardgatewayen, DNS-servere og et par finjusteringsdirektiver. Med route-nopull i kraft accepterer klienten stadig sessionen, verificerer stadig certifikater, forhandler stadig ciphere og keepalives og bringer stadig interfacet op. Det, den dropper, er anvendelsen af push-baserede route-linjer og push-baserede dhcp-option-linjer, DNS inkluderet.

Forvirringen kommer fra en grøn indikator ved siden af en død applikation. Tunnelen findes; afbildningen fra destinationer til den tunnel gør ikke. Intet i klientens statuspanel skelner »forbundet og ruter« fra »forbundet og inaktiv«, fordi begge set fra tunnelens synspunkt er samme tilstand.

Hvorfor en levende tunnel stadig ikke kan rute noget

Interfacet dukker op med sin egen adresse og har på et punkt-til-punkt-link ofte ikke noget mere specifikt end en værtsrute til partneren. Et privat undernet bliver kun tilgængeligt, når en eller anden rute peger på det interface med det rigtige præfiks, og med pushet deaktiveret ankommer den rute aldrig. Den downloadede profil kan normalt heller ikke hjælpe, fordi den blev skrevet ud fra den antagelse, at serveren ville levere netop denne information. Derfor kan interfacet se sundt ud, mens undernettet forbliver mørkt.

At læse profilen beviser derfor meget lidt. Læs den kørende tilstand i stedet, på den forbundne maskine:

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

En adresse uden en undernetsrute i den anden kommando er signaturen på dette problem. Den tredje kommando svarer derefter på det spørgsmål, brugerne faktisk bekymrer sig om, fordi den rapporterer det interface, som kernen ville vælge til en bestemt destination snarere end den liste, du håbede, den ville bruge. Hvis den svarer gennem dit fysiske link, er tunnelen slet ikke på vejen.

Navneopløsning fejler af en beslægtet grund, ikke en separat. Push-baserede dhcp-option DNS-poster springes over af det samme flag, så forespørgsler om interne værter går til den resolver, det lokale netværk nu engang stillede til rådighed. Den resolver har ingen zone til kontoret, så forespørgslen fejler eller returnerer et offentligt svar, og fejlen ligner et serverproblem, når det er et klientkonfigurationsproblem. At teste en adresse før et navn er det, der skiller de to.

Valget mellem flaget og et præfiksfilter

De to muligheder løser forskellige former for den samme klage, og et dårligt valg er det, der skaber tilstanden forbundet-men-ubrugelig. Den ene erstatter den push-baserede politik helt, mens den anden redigerer den efter præfiks. Tabellen giver den korte version, og afsnittet efter den dækker den del, der fanger folk.

pull-filter er en præfiksmatchning med tre verber, så den kan acceptere en familie af linjer, ignorere dem lydløst eller afvise forbindelsen helt, når et præfiks dukker op. Den sidste adfærd er den, der er værd at kende: en afvisningsregel gør en politisk uenighed til et mislykket håndtryk i stedet for en stille udeladelse. OpenVPN 2.6-manualen lister de accepterede præfikser og den præcise semantik for hvert verbum.

En almindelig mellemvej er at afvise kun redirect-gateway og lade kontorets ruter og DNS ankomme som tilsigtet. Det holder pushet fungerende for de dele, som serveren forstår bedre end dig, samtidig med at det forhindrer den ene linje, der ville overtage din standardrute.

Tilføjelse af ruter og en resolver manuelt

Hvis du beholder flaget, skal profilen sige, hvad serveren ville have sagt. Klient-side route-direktiver anvendes, efter forbindelsen er etableret, så de virker sammen med flaget i stedet for at blive blokeret af det. Sæt dem i profilen, ikke på en interaktiv kommandolinje, ellers vil den næste genopkobling ikke genskabe den fungerende tilstand.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS-linjen står i en akavet position: den er et klient-side-direktiv, men nogle klienter anvender den kun gennem platformens DNS-integration, som kan overskrive den, når linket ændrer sig. På en systemd-vært er det mere forudsigeligt at sætte resolvers direkte på tunnelinterfacet end at håbe på, at klienten vinder prioritetskonkurrencen:

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

Rutningsdomænet betyder lige så meget som adressen. Uden det kan forespørgsler om offentlige navne også blive sendt til den interne resolver, og enhver intern resolver, der afviser rekursion, vil ødelægge browsing, mens den private zone bliver ved med at virke. Med det sendes kun navne under det suffiks til tunnelresolveren, og alt andet følger det fysiske link.

Kontrol af resultatet: adresse, navn og den ydre vej

Tre tests skiller de mulige fejl. Hent den private adresse via IP, derefter den samme vært via navn, derefter et almindeligt offentligt websted. En fungerende IP med et fejlende navn peger på resolveren; en fejlende IP med et fungerende navn peger på rutning; begge fejler betyder normalt, at tunnelen ikke er på vejen.

Se derefter udad i stedet for indad. Tunnelens egen rute til endepunktet skal overleve ændringen, og enhver blokeringsfejl skal begrænses til tunnelen uden at fange endepunktet. En klient, der fortsætter med at browse, efter tunnelen falder, er et politikproblem, ikke et rutningsproblem, og det vil ikke dukke op i nogen af de tre tests ovenfor.

Skriv den endelige liste ind i profilens dokumentation: ruterne, resolveren, domænerne og grunden til, at hver enkelt findes. En genopkobling, der genskaber den samme tabel, er det eneste bevis på, at den lokale politik er komplet. Hvis applikationer stadig fejler med tunnelen oppe og alle tre tests bestået, er det næste sted at kigge klassen af forbundet-men-offline-problemer i stedet for certifikater, der allerede er verificeret.