Kva OpenVPN route-nopull faktisk hindrar serveren i å dytte ut

Du sette route-nopull i ein klientprofil for å hindre at tunnelen slukar standardruta di, og no er kontoret sitt subnett utilgjengeleg medan klienten framleis seier at han er tilkopla. Begge observasjonane er sanne, og ingenting har feila. Flagget fortel klienten å hoppe over rutene og DHCP-oppføringane som serveren dyttar ut, ein smalare instruks enn dei fleste ventar når dei legg han til. Det som står att er ein fungerande tunnel utan meining om kva mål som skal bruke han.

Det gapet er heile avgjerda denne artikkelen handlar om. Anten skildrar serveren nettet, eller så gjer klienten det, og flagget overlet den jobben til klienten utan å gjere noko av han for deg.

Kva flagget slår av ved tilkopling

Ein OpenVPN-klient som dreg, tek normalt imot ein pakke frå serveren etter autentisering: ruter, ei omdirigering av standardgatewayen, DNS-tenarar og nokre få justeringsdirektiv. Med route-nopull i kraft godtek klienten framleis økta, stadfestar framleis sertifikat, forhandlar framleis om chiffar og keepalives, og bringar framleis grensesnittet opp. Det han slepp, er bruken av dytta route-linjer og dytta dhcp-option-linjer, DNS inkludert.

Forvirringa kjem frå ein grøn indikator ved sida av ein daud applikasjon. Tunnelen finst; kartlegginga frå mål til den tunnelen gjer det ikkje. Ingenting i statuspanelet til klienten skil «tilkopla og ruter» frå «tilkopla og inaktiv», fordi begge er same tilstand sett frå tunnelen si side.

Kvifor ein levande tunnel framleis ikkje kan rute noko

Grensesnittet dukkar opp med si eiga adresse og har på ei punkt-til-punkt-lenke ofte ikkje noko meir spesifikt enn ei vertsrute til motparten. Eit privat subnett blir berre tilgjengeleg når ei eller anna rute peikar på det grensesnittet med rett prefiks, og med dyttinga slått av kjem den ruta aldri. Den nedlasta profilen kan vanlegvis heller ikkje hjelpe, fordi han vart skriven ut frå føresetnaden om at serveren ville levere akkurat denne informasjonen. Difor kan grensesnittet sjå sunt ut medan subnettet blir verande mørkt.

Å lese profilen beviser difor svært lite. Les den køyrande tilstanden i staden, på den tilkopla maskina:

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

Ei adresse utan subnett-rute i den andre kommandoen er signaturen på dette problemet. Den tredje kommandoen svarar deretter på spørsmålet brukarane faktisk bryr seg om, fordi han rapporterer grensesnittet kjernen ville valt for eit bestemt mål i staden for lista du vona han ville bruke. Svarar han gjennom den fysiske lenka di, er tunnelen ikkje på vegen i det heile.

Namneoppslag feilar av ein beslekta grunn, ikkje ein separat. Dytta dhcp-option DNS-oppføringar blir hoppa over av det same flagget, så spørjingar om interne vertar går til den resolveren det lokale nettet måtte ha stilt opp. Den resolveren har inga sone for kontoret, så spørjinga feilar eller returnerer eit offentleg svar, og feilen ser ut som eit serverproblem når det er eit klientkonfigurasjonsproblem. Å teste ei adresse før eit namn er det som skil dei to.

Valet mellom flagget og eit prefiksfilter

Dei to alternativa løyser ulike former for same klaga, og eit dårleg val er det som skaper tilstanden tilkopla-men-ubrukeleg. Den eine erstattar den dytta policyen heilt, medan den andre redigerer han etter prefiks. Tabellen gir kortversjonen, og avsnittet etter han dekkjer delen som fangar folk.

pull-filter er ein prefiksmatch med tre verb, så han kan godta ein familie av linjer, ignorere dei stille eller avvise tilkoplinga heilt når eit prefiks dukkar opp. Den siste åtferda er den som er verd å kjenne: ein avvisningsregel gjer ein policyusemje til eit mislukka handtrykk i staden for ei stille utelating. OpenVPN 2.6-handboka listar dei godtekne prefiksa og den nøyaktige semantikken til kvart verb.

Ein vanleg mellomveg er å avvise berre redirect-gateway og la rutene til kontoret og DNS kome som tiltenkt. Det held dyttinga fungerande for delane serveren forstår betre enn deg, samstundes som det hindrar den eine linja som ville teke over standardruta di.

Leggje til ruter og ein resolver for hand

Viss du behald flagget, må profilen seie det serveren ville sagt. Klientside-route-direktiv blir brukte etter at tilkoplinga er etablert, så dei verkar saman med flagget i staden for å bli blokkerte av det. Legg dei i profilen, ikkje på ei interaktiv kommandolinje, elles vil neste gjenoppkopling ikkje gjenskape den fungerande tilstanden.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS-linja står i ein vanskeleg posisjon: ho er eit klientside-direktiv, men nokre klientar brukar henne berre gjennom DNS-integreringa til plattformen, som kan skrive over henne når lenka endrar seg. På ein systemd-vert er det meir føreseieleg å setje resolveren direkte på tunnelgrensesnittet enn å håpe at klienten vinn prioritetskonkurransen:

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

Rutedomenet tyder like mykje som adressa. Utan det kan spørjingar om offentlege namn også bli sende til den interne resolveren, og ein kvar intern resolver som nektar rekursjon vil øydeleggje surfing medan den private sona held fram med å verke. Med det blir berre namn under det suffikset ruta til tunnelresolveren, og alt anna følgjer den fysiske lenka.

Kontrollere resultatet: adresse, namn og den ytre vegen

Tre testar skil dei moglege feila. Hent den private adressa via IP, deretter same vert via namn, deretter eit vanleg offentleg nettstad. Ein fungerande IP med eit feilande namn peikar på resolveren; ein feilande IP med eit fungerande namn peikar på rutinga; feilar begge, betyr det vanlegvis at tunnelen ikkje er på vegen.

Sjå deretter utover i staden for innover. Den eigne ruta til tunnelens endepunkt må overleve endringa, og ein kvar blokkerande feil må vere avgrensa til tunnelen utan å fange endepunktet. Ein klient som held fram med å surfe etter at tunnelen fell, er eit politikkproblem, ikkje eit rutingproblem, og det vil ikkje dukke opp i nokon av dei tre testane ovanfor.

Skriv den endelege lista inn i dokumentasjonen til profilen: rutene, resolveren, domenå og grunnen til at kvar einaste finst. Ei gjenoppkopling som gjenskaper den same tabellen, er det einaste beviset på at den lokale policyen er komplett. Viss applikasjonar framleis feilar med tunnelen oppe og alle tre testane bestått, er det neste staden å sjå klassen av tilkopla-men-offline-problem i staden for sertifikat som allereie er stadfesta.