Viens Pi, divi OpenVPN eksemplāri: ko lasa katra vienība
Divi OpenVPN dēmoni vienā Pi lasa dažādus konfigurācijas failus un iziet caur dažādiem āķiem. Kartējiet katru eksemplāru un pēc tam atsevišķi pārbaudiet kravnesas ceļu.
Saskaitiet OpenVPN procesus, pirms pieskaraties profilam. Pi, kas uzņem klejojošus lietotājus un vienlaikus zvana uz augšupēju pakalpojumu, palaiž divus dēmonus, un katrs no tiem lasa konfigurācijas failu, ko izvēlas ievadītais eksemplāra nosaukums. Pakotnes veidnes pēc tam katram dēmonam piešķir savu darba direktoriju, savu izpildlaika statusa failu un savu tuneļa ierīci. Ja šo sadalījumu izdarīsit nepareizi, pavadīsit vakaru, mainot pareizu iestatījumu failā, kuru darbojošais process nekad neatver.
Katrs eksemplāra nosaukums izvēlas savu failu
OpenVPN 2.6 piegādātajos vienību failos palaišanas argumenti satur eksemplāra vietturi, ko aizpilda ar tekstu aiz @ zīmes. Servera veidne darbojas no servera konfigurācijas direktorijas un atrisina savu argumentu pret tur esošo %i.conf, savukārt klienta veidne dara to pašu no klienta direktorijas. Tāpēc [email protected] lasa admits.conf servera direktorijā, un [email protected] lasa uplink.conf klienta direktorijā, un nevienam no šiem nosaukumiem nav nekādas nozīmes otrā direktorijā.
Pārbaudiet atbilstību pašā mašīnā, nevis pieņemiet, ka pakotne ir saglabājusi augšupējas noklusējuma vērtības. Distribūcijas drop-in drīkst pilnībā aizstāt darba direktoriju vai konfigurācijas argumentu.
systemctl cat [email protected]
systemctl cat [email protected]Lasiet WorkingDirectory rindu un konfigurācijas argumentu šajā izvadē, jo tikai iespējotā vienība nosaka, kurš fails tiek ielādēts. Drop-in, kas pievieno --config ExecStart, uzvar pār veidni pat tad, ja veidnes ceļš izskatās pareizs. Jautājiet fragmentu un drop-in ceļus, ja gribat zināt, vai darbojas vietēja pārrakstīšana. Ja abas lomas atrisinās uz vienu failu, jums ir viens process, kas cenšas būt gan serveris, gan klients, un vēlākā opcija šajā failā klusi uzvar.
Vietējais transports un pārsūtītā kravnesa nonāk dažādos āķos
Servera šifrētais savienojums ar katru klejojošo lietotāju tiek ģenerēts pašā Pi, tāpēc tā ārējās atbildes iziet caur vietējo izvades āķi. Klienta savienojums ar augšupējo partneri arī ir lokāli ģenerēta izvade, lai gan tā sasniedz attālu tīklu. Pārsūtītā kravnesa ir trešā kategorija, un kodols to saskaņo tikai pēc tam, kad jau ir izvēlējies pakešu izejošo ierīci.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Noteikums, kas forward ķēdē atbilst izejošajai saskarnei, var atļaut vai nomest paketi, kuru maršrutēšana jau ir piešķīrusi šai saskarnei, taču tas nekad neizvēlas saskarni. Kad viens resursdators pārtrauc vienu tuneli un sāk otru, politika, kas sūta lietotāju kravnesu augšupējā tunelī, un politika, kas aizsargā Pi paša šifrētās atbildes, ir divi atsevišķi lēmumi. Tie nejauši nonāk uz vienas fiziskās NIC, tāpēc tos jauc.
Šī atšķirība izskaidro biežu pusceļa kļūmi. Lietotāji pieslēdzas, rokasspiediens pabeidzas, un viņu trafiks tomēr iziet nepareizajā virzienā, jo rokasspiediens bija lokāls, bet kravnesa forward un tika pārbaudīts tikai viens no diviem.
Importēts maršruts var aprīt atbildes taviem lietotājiem
Klienta profila drošības iestatījums nosaka, ko augšupējā puse drīkst iespiest Pi maršrutēšanas tabulā, un plašs pārvirzījums ir opcija, kas strādājošu divu lomu resursdatoru pārvērš salūzušā. Ja iespiestais maršruts aptver klejojošo lietotāju publiskās adreses, servera ģenerētās atbildes uz viņiem var sekot jaunajam maršrutam augšupējā tunelī, nevis iziet caur pamatkārtu. Cilvēki bieži pārliecinās, ka tunelis uz pakalpojumu sniedzēju joprojām strādā, un apstājas pie tā, jo šis trafiks ir paša tuneļa transports un turpina plūst, kamēr viss pārējais darbojas nepareizi.
Politika, kas balstīta uz avotu vai mark, ir veids, kā divas plūsmas paliek atsevišķi. OpenVPN Linux mark opcija atzīmē paša dēmona šifrētās paketes ar ugunsmūra mark, ko maršrutēšanas noteikums pēc tam var nosūtīt uz īpašu tabulu. Avota adreses darbojas tikpat labi, ja servera ārējās atbildes vienmēr iziet no vienas pamatkārtas adreses. Abām pieejām ir vajadzīgi derīgi maršruti izvēlētajā tabulā un izņēmums pakalpojumu sniedzēja endpoint, citādi pats tunelis vairs neceļas.
Pirms rakstāt jebkuru noteikumu, pajautājiet kodolam, pa kādu ceļu atbilde patiešām aizies. Tālāk norādītās adreses ir vietturi Pi pamatkārtas adresei un viena klejojošā lietotāja publiskajai adresei.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Pārbaudi sadalījumu, pēc tam apturi pa vienai lomai
Pārbaudiet trīs plūsmas atsevišķi, jo strādājošs rokasspiediens neko nepierāda par pārējām divām. Pieņemiet jaunu ienākošo savienojumu, nosūtiet vienu atļautu lietojumprogrammu caur augšupējo izeju un apstipriniet, ka abi procesi joprojām sasniedz savus partnerus.
Pēc tam apturiet klienta lomu un vērojiet, ko servera loma saglabā. Tas ir lētākais veids, kā atrast maršruta vai mark noteikumu, kas bija domāts vienam eksemplāram, bet piemērots abiem.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerJūs gribat redzēt, ka klausītājs joprojām ir piesaistīts, tuneļa ierīce joprojām pastāv un žurnālā nav jaunu kļūdu, kamēr klienta loma ir apturēta. Ja klienta apturēšana pārtrauc arī servera atbildes esošajiem lietotājiem, abas lomas dala kaut ko, kam vajadzēja būt ierobežotam ar vienu no tām. Pierakstiet, kuru eksemplāru, kuru konfigurācijas failu un kuru plūsmas īpašnieku skāra katra izmaiņa, jo citādi nākamais cilvēks, kas atkļūdos šo resursdatoru, to pašu atklājumu sāks no nulles.