Vad OpenVPN route-nopull egentligen hindrar servern från att skjuta ut

Du satte route-nopull i en klientprofil för att hindra tunneln från att svälja din standardrutt, och nu är kontorets subnät onåbart medan klienten fortfarande säger att den är ansluten. Båda observationerna är sanna, och ingenting har misslyckats. Flaggan säger åt klienten att hoppa över de rutter och DHCP-poster som servern skjuter ut, en snävare instruktion än de flesta förväntar sig när de lägger till den. Det som återstår är en fungerande tunnel utan åsikt om vilka destinationer som ska använda den.

Det gapet är hela beslutet som den här artikeln handlar om. Antingen beskriver servern nätet, eller så gör klienten det, och flaggan lämnar det jobbet till klienten utan att göra något av det åt dig.

Vad flaggan stänger av vid anslutning

En OpenVPN-klient som drar tar normalt emot ett paket från servern efter autentisering: rutter, en omdirigering av standardgatewayen, DNS-servrar och några justeringsdirektiv. Med route-nopull i kraft accepterar klienten fortfarande sessionen, verifierar fortfarande certifikat, förhandlar fortfarande om chiffer och keepalives, och tar fortfarande upp gränssnittet. Det den släpper är tillämpningen av pushade route-rader och pushade dhcp-option-rader, DNS inkluderat.

Förvirringen kommer från en grön indikator bredvid en död applikation. Tunneln finns; mappningen från destinationer till den tunneln gör det inte. Ingenting i klientens statuspanel skiljer »ansluten och routar« från »ansluten och inaktiv«, eftersom båda är samma tillstånd sett från tunnelns sida.

Varför en levande tunnel fortfarande inte kan routa något

Gränssnittet dyker upp med sin egen adress och har på en punkt-till-punkt-länk ofta inget mer specifikt än en värdrutt till motparten. Ett privat subnät blir bara nåbart när någon rutt pekar på det gränssnittet med rätt prefix, och med pushningen avstängd kommer den rutten aldrig. Den nedladdade profilen kan vanligtvis inte heller hjälpa, eftersom den skrevs utifrån antagandet att servern skulle leverera exakt den här informationen. Därför kan gränssnittet se friskt ut medan subnätet förblir mörkt.

Att läsa profilen bevisar därför mycket lite. Läs det körande tillståndet i stället, på den anslutna maskinen:

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

En adress utan subnät-rutt i det andra kommandot är signaturen på det här problemet. Det tredje kommandot svarar sedan på frågan som användarna faktiskt bryr sig om, eftersom det rapporterar det gränssnitt som kärnan skulle välja för en viss destination i stället för listan du hoppades att den skulle använda. Om det svarar genom din fysiska länk är tunneln inte på vägen alls.

Namnuppslagning misslyckas av ett besläktat skäl, inte ett separat. Pushade dhcp-option DNS-poster hoppas över av samma flagga, så frågor om interna värdar går till vilken resolver det lokala nätet nu har tillhandahållit. Den resolvern har ingen zon för kontoret, så frågan misslyckas eller returnerar ett offentligt svar, och felet ser ut som ett serverproblem när det är ett klientkonfigurationsproblem. Att testa en adress före ett namn är det som skiljer de två.

Valet mellan flaggan och ett prefixfilter

De två alternativen löser olika former av samma klagomål, och ett dåligt val är det som skapar tillståndet ansluten-men-oanvändbar. Den ena ersätter den pushade policyn helt, den andra redigerar den per prefix. Tabellen ger kortversionen, och stycket efter den täcker delen som fångar folk.

pull-filter är en prefixmatchning med tre verb, så den kan acceptera en familj av rader, ignorera dem tyst eller avvisa anslutningen helt när ett prefix dyker upp. Det sista beteendet är det som är värt att känna till: en avvisningsregel gör en policyoenighet till ett misslyckat handskakning i stället för en tyst utelämning. OpenVPN 2.6-handboken listar de accepterade prefixen och den exakta semantiken för varje verb.

En vanlig mellanväg är att avvisa bara redirect-gateway och låta kontorets rutter och DNS komma som tänkt. Det håller pushningen fungerande för de delar som servern förstår bättre än du, samtidigt som det förhindrar den enda raden som skulle ta över din standardrutt.

Lägga till rutter och en resolver för hand

Om du behåller flaggan, måste profilen säga det servern skulle ha sagt. Klientsidans route-direktiv tillämpas efter att anslutningen upprättats, så de fungerar vid sidan av flaggan i stället för att blockeras av den. Lägg dem i profilen, inte på en interaktiv kommandorad, annars återställer nästa återanslutning inte det fungerande tillståndet.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS-raden står i en besvärlig position: den är ett klientsidans direktiv, men vissa klienter tillämpar det bara via plattformens DNS-integration, som kan skriva över det när länken ändras. På en systemd-värd är det mer förutsägbart att sätta resolvern direkt på tunnelgränssnittet än att hoppas att klienten vinner prioritetstävlingen:

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

Ruttdomänen betyder lika mycket som adressen. Utan den kan frågor om offentliga namn också skickas till den interna resolvern, och vilken intern resolver som helst som nekar rekursion kommer att förstöra surfningen medan den privata zonen fortsätter att fungera. Med den skickas bara namn under det suffixet till tunnelresolvern och allt annat följer den fysiska länken.

Kontrollera resultatet: adress, namn och den yttre vägen

Tre tester skiljer de möjliga felen. Hämta den privata adressen via IP, sedan samma värd via namn, sedan en vanlig offentlig webbplats. En fungerande IP med ett misslyckat namn pekar på resolvern; en misslyckad IP med ett fungerande namn pekar på routningen; misslyckas båda betyder det oftast att tunneln inte är på vägen.

Titta sedan utåt i stället för inåt. Tunnelns egen rutt till slutpunkten måste överleva ändringen, och varje blockerande fel måste begränsas till tunneln utan att fånga slutpunkten. En klient som fortsätter surfa efter att tunneln faller är ett policyproblem, inte ett routningsproblem, och det kommer inte att dyka upp i något av de tre testerna ovan.

Skriv den slutliga listan i profilens dokumentation: rutterna, resolvern, domänerna och skälet till att var och en finns. En återanslutning som återskapar samma tabell är det enda beviset på att den lokala policyn är komplett. Om applikationer fortfarande misslyckas med tunneln uppe och alla tre testerna godkända, är nästa ställe att titta klassen ansluten-men-offline-problem i stället för certifikat som redan verifierats.