Kur OpenVPN pieder maršruts: klientā vai serverī?
Kails maršruts servera konfigurācijā maina serveri, nevis klientu. Izvēlieties klienta failu, globālu push vai push vienam klientam un pārbaudiet, kas ieradās.
Jūs pievienojat route 10.60.0.0 255.255.255.0 servera konfigurācijai, restartējat, atkārtoti pievienojat klēpjdatoru, un apakštīkls joprojām nav sasniedzams no šī klēpjdatora. Rinda tika pieņemta, pakalpojums startēja tīri, un žurnālā nekas neizskatās nepareizi. Notika tas, ka maršruts tika instalēts tajā mašīnā, kuru jūs rediģējāt: vārteja tagad uzskata, ka var sasniegt šo prefiksu, bet klientam nekas netika pateikts. Izvietojums ir viss jautājums, un ir četras vietas, kur tā pati rinda var dzīvot.
Četras vietas un kas katru saņem
Maršrutu var pievienot ar paša klienta konfigurāciju, piedāvāt katram klientam ar globālu push, piedāvāt vienam klientam ar klientam specifisku failu vai ierakstīt paša servera maršrutēšanas kontekstā.
Šie četri gadījumi izmanto gandrīz identisku sintaksi un dod pilnīgi atšķirīgus rezultātus. Pirmie trīs ietekmē to, ko klients sūta tunelī; ceturtais ietekmē to, kā serveris sasniedz tīklu, kas ir noderīgi, ja pašam serverim vajag ceļu, un kaitīgi, ja to sajauc ar izplatīšanu.
Izlemiet, kuru no četriem vēlaties, pirms rakstīt rindu, pēc tam apstipriniet saņēmēju.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Kāpēc kails servera maršruts pārsteidz cilvēkus
Servera konfigurācija ir pirmā vieta, kur administratori skatās, un maršruta direktīva tur lasās kā apgalvojums par VPN tīklu. Tā nav. OpenVPN to uztver kā lokālu maršruta instalāciju mašīnā, kur darbojas dēmons, kas ir tieši tāda paša veida izmaiņa, ko jūs veiktu ar ip route un pēc tam aizmirstu.
Izplatīšana prasa, lai maršruts tiktu pushots, un push prasa, lai klients to pavelk. Klients, kas startēts ar izslēgtām pavelkamām opcijām, piedāvājumu pilnībā ignorē. Pārbaudiet abus šī rokasspiediena galus pirms servera faila pārrakstīšanas, jo servera žurnāls nepieprasīs: no tā puses piedāvājums tika nosūtīts. Pieņemts maršruts arī stājas spēkā tikai nākamajā savienojumā, nekad sesijā, kurā jūs jau esat.
Kad redzat abas kā atsevišķas darbības, kļūme pārstāj būt noslēpumaina: serveris sasniedz prefiksu, klients nevar, un abi apgalvojumi ir patiesi vienlaikus.
Klientam specifiski faili un identitāte, kam tie atbilst
Klientam specifisks fails tiek nosaukts pēc identitātes, ko serveris autentificēja, kas pēc noklusējuma ir sertifikāta vispārīgais nosaukums. Draudzīgs savienojuma nosaukums darbvirsmas klientā nav šī vērtība, un neatbilstība rada failu, kas nekad netiek lasīts.
Pārbaudiet direktoriju, ko serveris faktiski izmanto, pēc tam apstipriniet, ka faila nosaukums precīzi atbilst autentificētajai identitātei, ieskaitot lielos un mazos burtus.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Šajā failā maršruts joprojām ir jāpusho, jo klientam specifiskais konteksts ir opciju kopums, kas tiek piemērots šī klienta sesijai, nevis lokāla maršrutēšanas tabula. Kails maršruts tur rada tādu pašu problēmu kā kails maršruts globālajā failā.
Paša klienta fails un rīks, kam tas pieder
Maršruts, kas ievietots klienta konfigurācijā, tiek instalēts, kad šis klients pievienojas, un noņemts, kad tas atvienojas, kas ir pareizais dzīves cikls statiskam galamērķim.
Ja profilu pārvalda tīkla pārvaldnieks, tas var vienreiz importēt šīs opcijas un pēc tam paturēt savu kopiju. Lejupielādētā faila rediģēšana vēlāk neko nemaina, un tas ir biežs iemesls "maršruts ir, bet neattiecas".
Pārbaudiet aktīvo profilu, nevis lejupielādēto failu, un pārbaudiet importētos iestatījumus, ko rāda pārvaldnieks. Pēc tam pievienojieties un pajautājiet sistēmai, kuru ceļu izmanto konkrēta adrese, tā vietā lai pieņemtu, ka tunelis uzvarēja tāpēc, ka maršruts bija teksta failā.
Pārbaudiet klientā, pēc tam pārbaudiet atgaitas ceļu
Pajautājiet paša klienta maršrutēšanas tabulai par galamērķi, nevis servera tabulai. Meklēšana vienam resursdatoram prefiksa iekšienē ir pietiekama, lai parādītu saskarni un nākamo lēcienu, kas tiks izmantoti.
ip route get 10.60.0.10Ja meklēšana norāda uz tuneli, izplatīšana darbojās, un atlikusī problēma ir citur. Ja tā norāda uz noklusējuma vārteju, maršruts netika instalēts, to filtrēja klienta puses opcija, vai tas pieder profilam, kuru klients neizmanto.
Pieņemiet, ka izplatīšana darbojās, un joprojām nekas neatbild: tad pārbaudiet pārsūtīšanu vārtejā, pretējās puses atgaitas maršrutu un jebkuru ugunsmūri starp tiem. Maršruts izvēlas ceļu, tas nepiešķir piekļuvi.