Ko OpenVPN route-nopull patiesībā neļauj serverim nosūtīt

Jūs ievietojāt route-nopull klienta profilā, lai tunelis neaprij jūsu noklusējuma maršrutu, un tagad biroja apakštīkls nav sasniedzams, kamēr klients joprojām saka, ka ir savienots. Abi novērojumi ir patiesi, un nekas nav sabojājies. Šis karogs liek klientam izlaist servera nosūtītos maršrutus un DHCP ierakstus, kas ir šaurāka instrukcija, nekā vairums cilvēku gaida to pievienojot. Paliek strādājošs tunelis, kuram nav viedokļa par to, kuras galamērķa vietas to izmantos.

Šī plaisa ir viss lēmums, par ko ir šis raksts. Vai nu serveris apraksta tīklu, vai to dara klients, un karogs nodod šo darbu klientam, neko no tā jūsu vietā neizdarot.

Ko karogs izslēdz savienošanās laikā

Velkošais OpenVPN klients parasti pēc autentifikācijas saņem no servera saiņu: maršrutus, noklusējuma vārtejas pārvirzīšanu, DNS serverus un dažas regulēšanas direktīvas. Kad route-nopull ir spēkā, klients joprojām pieņem sesiju, joprojām pārbauda sertifikātus, joprojām vienojas par šifriem un keepalive, un joprojām paceļ saskarni. Tas, ko tas izmet, ir nosūtīto route rindu un nosūtīto dhcp-option rindu piemērošana, ieskaitot DNS.

Apjukums nāk no zaļa indikatora blakus mirušai programmai. Tunelis pastāv; galamērķu kartējums uz šo tuneli nepastāv. Nekas klienta statusa panelī neatšķir «savienots un maršrutē» no «savienots un neaktīvs», jo no tuneļa viedokļa abi ir viens un tas pats stāvoklis.

Kāpēc dzīvs tunelis tomēr nevar neko maršrutēt

Saskarne parādās ar savu adresi, un punktpunkta savienojumā bieži nav nekā konkrētāka par maršrutu uz saimnieku pie partnera. Privāts apakštīkls kļūst sasniedzams tikai tad, kad kāds maršruts ar pareizo prefiksu norāda uz šo saskarni, un ar izslēgtu nosūtīšanu šis maršruts nekad nepienāk. Lejupielādētais profils arī parasti nevar palīdzēt, jo tas rakstīts, pieņemot, ka serveris sniegs tieši šo informāciju. Tāpēc saskarne var izskatīties vesela, kamēr apakštīkls paliek tumšs.

Tātad profila lasīšana pierāda ļoti maz. Tā vietā lasiet darbojošos stāvokli savienotajā mašīnā:

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

Adrese bez apakštīkla maršruta otrajā komandā ir šīs problēmas paraksts. Trešā komanda tad atbild uz jautājumu, kas lietotājiem patiešām rūp, jo tā ziņo par saskarni, ko kodols izvēlētos konkrētam galamērķim, nevis sarakstu, uz kuru jūs cerējāt, ka tas izmantos. Ja tā atbild caur jūsu fizisko savienojumu, tunelis vispār nav ceļā.

Vārdu izšķiršana neizdodas saistīta iemesla dēļ, nevis atsevišķa. Nosūtītie dhcp-option DNS ieraksti tiek izlaisti ar to pašu karogu, tāpēc vaicājumi par iekšējiem saimniekiem dodas uz to risinātāju, ko nodrošināja vietējais tīkls. Tam risinātājam nav zonas birojam, tāpēc vaicājums neizdodas vai atgriež publisku atbildi, un kļūme izskatās kā servera problēma, lai gan tā ir klienta konfigurācijas problēma. Adreses pārbaude pirms vārda ir tas, kas abus atdala.

Izvēle starp karogu un prefiksa filtru

Abas iespējas risina dažādas vienas un tās pašas sūdzības formas, un slikta izvēle ir tā, kas rada stāvokli savienots-bet-nederīgs. Viena aizstāj nosūtīto politiku pilnībā, otra to rediģē pēc prefiksa. Tabula sniedz īso versiju, un rindkopa pēc tās aptver daļu, kas cilvēkus pārsteidz.

pull-filter ir prefiksu saskaņotājs ar trim darbības vārdiem, tāpēc tas var pieņemt rindu saimi, tās klusi ignorēt vai pilnībā noraidīt savienojumu, kad parādās prefikss. Tieši pēdējā uzvedība ir tā, ko vērts zināt: noraidīšanas noteikums pārvērš politikas domstarpības neizdevušā rokasspiedienā, nevis klusā izlaidumā. OpenVPN 2.6 rokasgrāmata uzskaita pieņemtos prefiksus un katra darbības vārda precīzo nozīmi.

Bieži sastopams vidusceļš ir noraidīt tikai redirect-gateway un ļaut biroja maršrutiem un DNS pienākt kā paredzēts. Tas uztur nosūtīšanu strādājošu tām daļām, ko serveris saprot labāk par jums, un vienlaikus novērš to vienu rindu, kas pārņemtu jūsu noklusējuma maršrutu.

Maršrutu un risinātāja pievienošana ar roku

Ja paturat karogu, profilam jāsaka tas, ko būtu teicis serveris. Klienta puses route direktīvas tiek piemērotas pēc savienojuma izveides, tāpēc tās darbojas līdzās karogam, nevis karogs tās bloķē. Ievietojiet tās profilā, nevis interaktīvā komandu rindā, citādi nākamā atkārtotā savienošanās neatjaunos darbojošos stāvokli.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS rinda atrodas neērtā stāvoklī: tā ir klienta puses direktīva, bet daži klienti to piemēro tikai caur platformas DNS integrāciju, kas to var pārrakstīt, kad savienojums mainās. systemd saimniekā risinātāja iestatīšana tieši uz tuneļa saskarnes ir paredzamāka nekā cerība, ka klients uzvarēs prioritāšu sacensībā:

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

Maršrutēšanas domēns ir tikpat svarīgs kā adrese. Bez tā vaicājumi par publiskiem nosaukumiem var tikt sūtīti arī iekšējam risinātājam, un jebkurš iekšējais risinātājs, kas atsakās no rekursijas, salauzīs pārlūkošanu, kamēr privātā zona turpinās strādāt. Ar to tikai nosaukumi zem šī sufiksa tiek maršrutēti uz tuneļa risinātāju, un viss pārējais seko fiziskajam savienojumam.

Rezultāta pārbaude: adrese, vārds un ārējais ceļš

Trīs testi atdala iespējamās kļūmes. Iegūstiet privāto adresi pēc IP, pēc tam to pašu saimnieku pēc vārda, pēc tam parastu publisku vietni. Strādājošs IP ar neizdevušos vārdu norāda uz risinātāju; neizdevies IP ar strādājošu vārdu norāda uz maršrutēšanu; ja abi neizdodas, parasti tunelis nav ceļā.

Pēc tam skatieties uz āru, nevis uz iekšu. Tuneļa galapunkta pašam maršrutam jāiztur izmaiņas, un jebkurai bloķējošai kļūmei jābūt ierobežotai ar tuneli, neaizķerot galapunktu. Klients, kas turpina pārlūkot pēc tuneļa krišanas, ir politikas, nevis maršrutēšanas problēma, un tā neparādīsies nevienā no trim iepriekš minētajiem testiem.

Ierakstiet galīgo sarakstu profila dokumentācijā: maršrutus, risinātāju, domēnus un iemeslu, kāpēc katrs pastāv. Atkārtota savienošanās, kas atveido to pašu tabulu, ir vienīgais pierādījums, ka vietējā politika ir pilnīga. Ja programmas joprojām neizdodas, kad tunelis ir pacelts un visi trīs testi izturēti, nākamā vieta, kur skatīties, ir savienots-bet-nesaistīts problēmu klase, nevis jau pārbaudīti sertifikāti.