Unu Pi, du OpenVPN-kazoj: kion legas ĉiu unuo

Kalkulu la OpenVPN-procezojn antaŭ ol tuŝi profilon. Pi, kiu akceptas migrantajn uzantojn kaj ankaŭ alvokas supran servon, funkciigas du demonojn, kaj ĉiu el ili legas agordan dosieron elektitan per la kaza nomo, kiun vi tajpis. Poste la pakitaj ŝablonoj donas al ĉiu demono sian propran laboran dosierujon, sian propran stata dosieron de runtipo kaj sian propran tunelan aparaton. Se vi eraras pri tiu divido, vi pasigos vesperon ŝanĝante ĝustan agordon en dosiero, kiun la kuranta procezo neniam malfermas.

Ĉiu kaza nomo elektas sian propran dosieron

En la unuaj dosieroj liveritaj kun OpenVPN 2.6, la startaj argumentoj portas kazan anstataŭigilon, kiu pleniĝas el la teksto post la signo @. La servila ŝablono funkcias el la servila agorda dosierujo kaj solvas sian argumenton kontraŭ %i.conf tie, dum la klienta ŝablono faras la samon el la klienta dosierujo. Do [email protected] legas admits.conf en la servila dosierujo, kaj [email protected] legas uplink.conf en la klienta dosierujo, kaj neniu el la nomoj havas signifon en la alia dosierujo.

Konfirmu la mapadon sur la maŝino anstataŭ supozi, ke la pakaĵo konservis la suprajn defaŭltojn. Distribua aldonaĵo rajtas anstataŭigi la laboran dosierujon aŭ la agordan argumenton tute.

systemctl cat [email protected]
systemctl cat [email protected]

Legu la linion WorkingDirectory kaj la agordan argumenton en tiu eligo, ĉar la ebligita unuo estas la sola afero, kiu decidas, kiu dosiero ŝargiĝas. Aldonaĵo, kiu aldonas --config al ExecStart, venkas la ŝablonon eĉ kiam la ŝablona vojo aspektas ĝusta. Petu la vojojn de la fragmento kaj de la aldonaĵo, kiam vi volas scii, ĉu loka anstataŭigo ludas. Se ambaŭ roloj solviĝas al unu dosiero, vi havas unu procezon, kiu provas esti servilo kaj kliento, kaj la posta opcio en tiu dosiero silente venkas.

Loka transporto kaj plusendita ŝarĝo trafas malsamajn hokojn

La ĉifrita ligo de la servilo al ĉiu migranta uzanto estas generata sur la Pi mem, do ĝiaj eksteraj respondoj eliras tra la loka eliga hoko. La ligo de la kliento al sia supra kunulo ankaŭ estas loke generata eligo, kvankam ĝi atingas malproksiman reton. Plusendita ŝarĝo estas tria kategorio, kaj la kerno kongruigas ĝin nur post kiam ĝi jam elektis eligan aparaton por la pakaĵo.

Regulo, kiu kongruigas eligan interfacon ene de plusenda ĉeno, povas permesi aŭ forĵeti pakaĵon, kiun enkursigado jam atribuis al tiu interfaco, sed ĝi neniam elektas la interfacon. Kiam unu gastiganto finas unu tunelon kaj komencas alian, la politiko, kiu sendas uzantan ŝarĝon en la supran tunelon, kaj la politiko, kiu protektas la proprajn ĉifritajn respondojn de la Pi, estas apartaj decidoj. Ili hazarde surteriĝas sur la sama fizika retkarto, kaj tial ili konfuziĝas.

Tiu distingo klarigas oftan duonan malsukceson. Uzantoj konektiĝas, la manpremo finiĝas, kaj ilia trafiko ankoraŭ eliras la malĝustan vojon, ĉar la manpremo estis loka kaj la ŝarĝo estis plusendita, kaj nur unu el la du estis iam testita.

Enportita vojo povas engluti respondojn al viaj uzantoj

La sekureca agordo de la klienta profilo decidas, kion la supra flanko rajtas puŝi en la enkursigan tabelon de la Pi, kaj larĝa redirektado estas la opcio, kiu igas funkciantan duoblan-rolan gastiganton rompita. Se la puŝita vojo kovras la publikajn adresojn de migrantaj uzantoj, la respondoj, kiujn la servilo generas al ili, povas sekvi la novan vojon en la supran tunelon anstataŭ eliri tra la suba tavolo. Homoj ofte konfirmas, ke la tunelo al la provizanto ankoraŭ funkcias, kaj haltas tie, ĉar tiu trafiko estas la propra transporto de la tunelo kaj ĝi daŭre fluas dum ĉio alia miskondutas.

Politiko bazita sur fonto aŭ marko estas la maniero teni la du fluojn aparte. La Linuksa marka opcio de OpenVPN markas la proprajn ĉifritajn pakaĵojn de demono per fajroŝirma marko, kiun enkursiga regulo poste povas sendi al dediĉita tabelo. Fontadresoj funkcias same bone, kiam la eksteraj respondoj de la servilo ĉiam eliras el unu suba-tavola adreso. Ĉiu aliro bezonas validajn vojojn en la tabelo, kiun ĝi elektas, kaj escepton por la finpunkto de la provizanto, alie la tunelo mem ĉesas leviĝi.

Demandu la kernon, kiun vojon respondo efektive prenus, antaŭ ol skribi ajnan regulon. La adresoj sube estas anstataŭigiloj por suba-tavola adreso de Pi kaj la publika adreso de unu migranta uzanto.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Kontrolu la dividon, poste haltigu unu rolon samtempe

Testu tri fluojn aparte, ĉar funkcianta manpremo pruvas nenion pri la aliaj du. Akceptu novan envenan ligon, sendu unu permesitan aplikaĵon tra la supra eliro, kaj konfirmu, ke ambaŭ procezoj ankoraŭ atingas siajn proprajn kunulojn.

Poste haltigu la klientan rolon kaj observu, kion la servila rolo konservas. Tio estas la plej malmultekosta maniero trovi vojan aŭ markan regulon, kiu estis destinita al unu kazo kaj aplikita al ambaŭ.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

Kion vi volas vidi estas la aŭskultanto ankoraŭ ligita, la tunela aparato ankoraŭ ĉeesta, kaj la protokolo libera de novaj eraroj dum la klienta rolo estas mallevita. Se haltigi la klienton ankaŭ fortranĉas la respondojn de la servilo al ekzistantaj uzantoj, la du roloj dividas ion, kio devintus esti limigita al unu el ili. Notu, kiun kazon, kiun agordan dosieron kaj kiun fluposedanton ĉiu ŝanĝo tuŝis, ĉar la venonta persono, kiu sencimigos ĉi tiun gastiganton, alie ripetos la saman malkovron de nulo.