Ien Pi, twa OpenVPN-eksimplaren: wat elke ienheid lêst
Twa OpenVPN-daemons op ien Pi lêze ferskate konfiguraasjebestanden en geane derút fia ferskate heakken. Map elk eksimplaar, test dan it paad fan 'e lading apart.
Tel de OpenVPN-prosessen foardat jo in profyl oanreitsje. In Pi dy't roaming-brûkers talit en ek in upstream-tsjinst opskillet, rint twa daemons, en elk fan har lêst in konfiguraasjebestand dat keazen wurdt troch de eksimplaarnamme dy't jo yntypen. De ferpakte sjabloanen jouwe dan elke daemon syn eigen wurkmap, syn eigen runtime-statusbestân en syn eigen tunnelapparaat. Krijst jo dy splitsing ferkeard, dan bringt jo in jûn troch mei it feroarjen fan in korrekte ynstelling yn in bestân dat it rinnende proses nea iepenet.
Elke eksimplaarnamme kiest syn eigen bestân
Yn 'e ienheidsbestannen dy't mei OpenVPN 2.6 levere wurde, drage de startarguminten in eksimplaar-plakhâlder dy't folle wurdt út 'e tekst nei it teken @. It server-sjabloan rint út 'e konfiguraasjemap fan 'e server en lost syn argumint op tsjin %i.conf dêr, wylst it kliïntsjabloan itselde docht út 'e kliïntmap. Sa lêst [email protected] admits.conf yn 'e servermap en [email protected] lêst uplink.conf yn 'e kliïntmap, en gjinien fan 'e nammen hat ek mar ien betsjutting yn 'e oare map.
Befêstigje de mapping op 'e masine ynstee fan oan te nimmen dat it pakket de upstream-standertweis bewarre hat. In distribúsje-drop-in mei de wurkmap of it konfiguraasje-argumint daliks ferfange.
systemctl cat [email protected]
systemctl cat [email protected]Lês de rigel WorkingDirectory en it konfiguraasje-argumint yn dy útfier, want de ynskeakele ienheid is it iennige ding dat beslút hokker bestân laden wurdt. In drop-in dy't --config oan ExecStart taheakket, wint fan it sjabloan sels as it sjabloanpaad goed liket. Freegje de paden fan it fragmint en de drop-in as jo witte wolle oft in lokale oerskriuwing yn it spul is. As beide rollen op ien bestân útdraaie, hawwe jo ien proses dat besiket sawol server as kliïnt te wêzen, en de lettere opsje yn dat bestân wint stil.
Lokaal ferfier en trochstjoerde lading reitsje ferskate heakken
De fersifere ferbining fan 'e server mei elke roaming-brûker wurdt op 'e Pi sels makke, dat syn bûtenste antwurden geane derút fia de lokale útfierheak. De ferbining fan 'e kliïnt mei syn upstream-peer is ek lokaal makke útfier, al berikt er in ôfstânnetwurk. Trochstjoerde lading is in tredde kategory, en de kernel koppelet dy pas neidat er al in útgeand apparaat foar it pakket keazen hat.
| 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 |
In regel dy't in útgeande ynterface yn in trochstjoerkeatling koppelet, kin in pakket tastean of falle litte dat routing al oan dy ynterface tawiisd hat, mar hy kiest de ynterface nea. As ien host ien tunnel einiget en in oare begjint, dan binne it belied dat brûkerslading yn 'e upstream-tunnel stjoert en it belied dat de eigen fersifere antwurden fan 'e Pi beskermet aparte besluten. Se bedarje tafallich op deselde fysike netkaart, en dêrom wurde se trochinoar helle.
Dy ûnderskied ferklearret in gewoane heal-mislear. Brûkers ferbine, de hânskutel foltôget, en har ferkear giet noch altyd de ferkearde kant út, om't de hânskutel lokaal wie en de lading trochstjoerd wie en mar ien fan 'e twa ea test waard.
In ymportearre rûte kin antwurden oan jo brûkers opslokke
De feiligensynstelling fan it kliïntprofyl beslút wat de upstream yn 'e routingstabel fan 'e Pi triuwe mei, en in brede omstrui is de opsje dy't in wurkjende dûbele-rol-host yn in brutsen ien feroaret. As de trúste rûte de iepenbiere adressen fan roaming-brûkers dekt, kinne de antwurden dy't de server nei har ta makket de nije rûte folgje de upstream-tunnel yn ynstee fan fia de ûnderlaach fuort te gean. Minsken befêstigje faak dat de tunnel nei de provider noch wurket en stopje dêr, om't dat ferkear it eigen ferfier fan 'e tunnel is en it trochrint wylst al it oare him misdraacht.
Belied basearre op boarne of mark is de manier om de twa streamen apart te hâlden. De Linux-mark-opsje fan OpenVPN stimpelet de eigen fersifere pakketten fan in daemon mei in firewallmark, dy't in routingregel dan nei in tawijde tabel stjoere kin. Boarne-adressen wurkje like goed as de bûtenste antwurden fan 'e server altyd fan ien ûnderlaachadres ôf geane. Beide oanpakken hawwe jildige rûtes nedich yn 'e tabel dy't se kiest en in útsûndering foar it einpunt fan 'e provider, oars hâldt de tunnel sels op mei omheech kommen.
Freegje de kernel nei it paad dat in antwurd wier nimme soe foardat jo in regel skriuwe. De adressen hjirûnder binne plakhâlders foar in ûnderlaachadres fan 'e Pi en it iepenbiere adres fan ien roaming-brûker.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Ferifiearje de splitsing en stopje dan ien rol tagelyk
Test trije streamen apart, want in wurkjende hânskutel bewiist neat oer de oare twa. Akseptearje in nije ynkommende ferbining, stjoer ien tastiene applikaasje fia de upstream-útgong en befêstigje dat beide prosessen noch har eigen peers berikke.
Stopje dan de kliïntrol en sjoch wat de serverrol hâldt. Dit is de goedkeapste manier om in rûte- of markregel te finen dy't foar ien eksimplaar bedoeld wie en op beide tapast is.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerWat jo sjogge wolle, is de listener noch bûn, it tunnelapparaat noch oanwêzich en it logfrij fan nije flaters wylst de kliïntrol del is. As it stopjen fan 'e kliïnt ek de antwurden fan 'e server oan besteande brûkers ôfsnijt, diele de twa rollen wat ta ien fan har beheind wêze moatten hie. Skriuw op hokker eksimplaar, hokker konfiguraasjebestân en hokker stream-eigner elke feroaring rekke, want de folgjende persoan dy't dizze host debugt, sil oars deselde ûntdekking fan nul ôf werhelje.