Isang Pi, Dalawang Instance ng OpenVPN: Ano ang Binabasa ng Bawat Unit
Dalawang daemon ng OpenVPN sa isang Pi ay nagbabasa ng magkaibang config file at lumalabas sa magkaibang hook. I-map ang bawat instance, pagkatapos ay subukan nang hiwalay ang landas ng payload.
Bilangin ang mga proseso ng OpenVPN bago mo hawakan ang isang profile. Ang Pi na tumatanggap ng roaming user at kasabay ay tumatawag sa isang upstream na serbisyo ay nagpapatakbo ng dalawang daemon, at bawat isa ay nagbabasa ng config file na pinili ng pangalan ng instance na na-type mo. Pagkatapos ay binibigyan ng mga template ng package ang bawat daemon ng sarili nitong working directory, sariling runtime status file at sariling tunnel device. Kung mali ang paghahati na ito, gugugol ka ng isang gabi sa pagbabago ng tamang setting sa loob ng file na hindi kailanman binubuksan ng tumatakbong proseso.
Pinipili ng bawat pangalan ng instance ang sarili nitong file
Sa mga unit file na kasama ng OpenVPN 2.6, may dalang instance placeholder ang mga start argument na pinupuno ng teksto pagkatapos ng tandang @. Ang template ng server ay tumatakbo mula sa config directory ng server at nilulutas ang argumento nito laban sa %i.conf doon, habang ang template ng client ay gumagawa ng pareho mula sa directory ng client. Kaya binabasa ng [email protected] ang admits.conf sa directory ng server at binabasa ng [email protected] ang uplink.conf sa directory ng client, at wala sa mga pangalang ito ang may anumang kahulugan sa kabilang directory.
Tiyakin ang mapping sa mismong makina sa halip na ipagpalagay na pinanatili ng package ang mga default ng upstream. Maaaring palitan ng drop-in ng distribution ang working directory o ang config argument nang buo.
systemctl cat [email protected]
systemctl cat [email protected]Basahin ang linyang WorkingDirectory at ang config argument sa output na iyon, dahil ang naka-enable na unit lang ang nagpapasya kung aling file ang nilo-load. Ang drop-in na nagdaragdag ng --config sa ExecStart ay nananalo sa template kahit mukhang tama ang landas ng template. Hingin ang mga landas ng fragment at drop-in kapag gusto mong malaman kung may lokal na override na nangyayari. Kung ang dalawang papel ay nalulutas sa isang file, mayroon kang isang proseso na sinusubukang maging server at client nang sabay, at ang huling opsyon sa file na iyon ay tahimik na nananalo.
Lokal na transport at forwarded payload ay tumatama sa magkaibang hook
Ang naka-encrypt na koneksyon ng server sa bawat roaming user ay nililikha sa Pi mismo, kaya ang mga panlabas na sagot nito ay lumalabas sa lokal na output hook. Ang koneksyon ng client sa upstream peer nito ay locally generated na output din, kahit umaabot ito sa malayong network. Ang forwarded payload ay ang ikatlong kategorya, at itinatapat ito ng kernel pagkatapos nitong pumili ng outgoing device para sa packet.
| 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 |
Ang rule na tumutugma sa isang outgoing interface sa loob ng forward chain ay maaaring payagan o i-drop ang packet na naitalaga na ng routing sa interface na iyon, ngunit hindi ito kailanman pumipili ng interface. Kapag tinapos ng isang host ang isang tunnel at nagpasimula ng isa pa, ang patakarang nagpapadala ng payload ng user sa upstream tunnel at ang patakarang nagpoprotekta sa sariling naka-encrypt na sagot ng Pi ay dalawang magkaibang desisyon. Nagkataon silang dumapo sa parehong pisikal na NIC, kaya napagkakamalan sila.
Ipinapaliwanag ng pagkakaibang iyon ang karaniwang kalahating pagkabigo. Kumokonekta ang mga user, natatapos ang handshake, at mali pa rin ang daan ng labasan ng traffic nila, dahil lokal ang handshake at forward ang payload at isa lang sa dalawa ang nasubukan.
Ang na-import na ruta ay maaaring lumamon ng sagot sa iyong mga user
Ang setting ng seguridad ng profile ng client ang nagpapasya kung ano ang maaaring itulak ng upstream sa routing table ng Pi, at ang malawak na redirect ang opsyong nagpapabagsak sa isang gumaganang host na may dalawang papel. Kung saklaw ng itinulak na ruta ang mga pampublikong address ng roaming user, ang mga sagot na nililikha ng server para sa kanila ay maaaring sumunod sa bagong ruta papasok sa upstream tunnel sa halip na lumabas sa underlay. Madalas tiyakin ng mga tao na gumagana pa ang tunnel patungo sa provider at huminto doon, dahil ang traffic na iyon ay ang sariling transport ng tunnel at patuloy itong dumadaloy habang mali ang inaasal ng lahat ng iba.
Ang patakarang nakabatay sa source o mark ang paraan para manatiling magkahiwalay ang dalawang stream. Ang mark na opsyon ng Linux sa OpenVPN ay naglalagay ng firewall mark sa sariling naka-encrypt na packet ng daemon, na maaaring ipadala ng routing rule sa isang dedikadong table. Gumagana rin nang maayos ang mga source address kapag ang mga panlabas na sagot ng server ay laging lumalabas mula sa isang underlay address. Kailangan ng alinmang paraan ang valid na ruta sa table na pinipili nito at exception para sa endpoint ng provider, kung hindi ay hindi na bumabangon ang tunnel mismo.
Tanungin ang kernel kung anong landas ang talagang tatahakin ng isang sagot bago sumulat ng anumang rule. Ang mga address sa ibaba ay placeholder para sa underlay address ng Pi at sa pampublikong address ng isang roaming user.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10I-verify ang paghahati, pagkatapos ay itigil ang isang papel sa isang pagkakataon
Subukan nang hiwalay ang tatlong flow, dahil ang gumaganang handshake ay walang pinapatunayan tungkol sa dalawa pa. Tumanggap ng bagong inbound na koneksyon, magpadala ng isang pinapayagang application sa labasan ng upstream, at tiyakin na naaabot pa rin ng dalawang proseso ang kani-kanilang peer.
Pagkatapos ay itigil ang papel ng client at tingnan kung ano ang pinananatili ng papel ng server. Ito ang pinakamurang paraan para mahanap ang rule ng ruta o mark na para sa isang instance ngunit inilapat sa dalawa.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerAng gusto mong makita ay nakatali pa rin ang listener, naroon pa rin ang tunnel device, at malinis ang log sa mga bagong error habang patay ang papel ng client. Kung ang pagtigil sa client ay pumuputol din sa mga sagot ng server sa mga kasalukuyang user, may pinagsasaluhan ang dalawang papel na dapat ay limitado sa isa lamang. Itala kung aling instance, aling config file at aling may-ari ng flow ang naapektuhan ng bawat pagbabago, dahil kung hindi ay uulitin ng susunod na magde-debug sa host na ito ang parehong natuklasan mula sa simula.