Þjónn eða biðlari: hver OpenVPN-eining á Pi með tvöfalt hlutverk
Tvö OpenVPN-tilvik deila einni Pi: eitt tekur við flökkunarnotendum, hitt hringir í veitandann fyrir ofan. Lestu nafn einingarinnar og möppuna áður en þú endarræsir hvort sem er.
Tvö OpenVPN-ferli keyra á Pi sem bæði tekur við flökkunarnotendum og nær til veitanda fyrir ofan, og þau deila næstum engu nema vélbúnaðinum. Annað hlustar á innkomandi göng en hitt hringir út. Hvort um sig les sína möppu, og hvort hefur sinn eigin bilunarham. Að endarræsa ranga einingu er algengasta leiðin sem biðlaraviðgerð endar með að hrista hlustandann í staðinn.
Paraðu nafn einingarinnar við möppuna sem hún hleður
Upstream 2.6 sendir tvær sniðmátseiningar, [email protected] og [email protected]. Sniðmát þjónsins byrjar í /etc/openvpn/server og hleður %i.conf þaðan. Sniðmát biðlarans byrjar í /etc/openvpn/client. Tilvik að nafni roaming getur verið á báðum stöðum í einu, sem þjónn og sem biðlari, með tvær ótengdar stillingar og enga tengingu milli þeirra nema strenginn.
Spyrðu systemd frekar en skráarkerfið, því pökkunarfólk bætir við skrám sem geta breytt vinnumöppunni eða rökunum sem tvíundarforritið fær.
systemctl list-units --type=service 'openvpn-*@*' systemctl cat [email protected] systemctl show -p WorkingDirectory -p ExecStart [email protected]
Fyrsta skipunin listar hverja tilviksskapaða einingu, þar á meðal þær sem mistókust og voru áfram hlaðnar. Önnur prentar einingarskrána ásamt hvers kyns yfirskrift. Þriðja er fljótlegasta leiðin til að sjá þær tvær staðreyndir sem ráða spurningunni: möppuna sem ferlið byrjar í, og stillingarslóðina sem því var gefin.
Ákveddu eftir stefnu pakkanna, ekki eftir nafni viðmótsins
Þjónstilvik á sér hlustandi sæti og tekur við tengingum. Dulkóðuð flutningur þess er staðbundin inntak og staðbundin úttak á Pi, en umferðin sem það sendir áfram fyrir notendur fylgir áframsendingarleiðinni og hlýðir öðru reglusetti. Biðlaratilvik á sér ekki hlustanda í þeim skilningi: það hringir í jafningja, svo dulkóðuð flutningur þess er staðbundin úttak til undirlagsins.
Sá munur segir þér hvar regla á heima. Regla sem passar við viðmót innan áframsendingarkeðju leyfir aðeins umferð sem leiðsögnin hefur þegar valið; hún velur aldrei leiðina. Þegar pakkar flökkunarnotanda fara út um ranga leið, er keðjan sem á að skoða forward, ekki output.
Líttu á sætin áður en þú færir í fræði. Þjónn sem er bundinn við udp/1194 sýnir hlustandi sæti. Biðlarinn sýnir tengsl við vistfang veitandans og ekkert sem hlustar.
ss -lunp | grep openvpn ss -unp state established '( dport = :1194 or sport = :1194 )'
Sjálfgefna leið eins tilviks getur gripið svör hins
redirect-gateway sem hinu efra biðlara er ýtt inn setur sjálfgefna leið sem keppir við allt annað á vélinni, þar á meðal svörin sem þjónninn sendir flökkunarnotendum. OpenVPN gerir undantekningu fyrir eigið jafningjavistfang svo göngin haldist aðgengileg, en sú undantekning segir ekkert um síma á hótelneti.
Einkennin eru venjulega ósamhverf. Handabandið klárast, biðlarinn tilkynnir tengingu, og umferðin deyr eftir fyrsta svarpakkann. Stefnumiðuð leiðsögn byggð á uppruna, eða pakkamark sett á þjónstilvikið með --mark, heldur ferðunum tveimur aðskildum; hvort tveggja er ekki heilt reglusett út af fyrir sig, og bæði þurfa gildar leiðir í þeirri töflu sem þau velja.
Prófaðu staðbundna ákvörðun frekar en ástand ganganna, því kjarninn velur uppruna og viðmót áður en OpenVPN sér pakkann.
ip route get 203.0.113.44 ip rule show
Endarræstu eitt hlutverk og sýndu fram á að hitt lifði af
Röðin skiptir máli þegar bæði hlutverkin ráðast af sama undirlaginu. Endarræstu biðlarann fyrst ef leiðin fyrir ofan verður að vera til áður en hægt er að senda notendaumferð áfram, og endarræstu þjóninn fyrst þegar þú breytir aðeins hlustandanum hans eða lauginni. Í öllum tilvikum staðfestu báðar einingarnar eftir á, því misheppnuð endarræsing getur látið hitt hlutverkið keyra á úreldu ástandi.
Skrifaðu niður stöðvunarskilyrðið fyrir breytinguna: hindrar tap á göngunum fyrir ofan flökkunarnotendur, eða fellur það aftur á eigin upptengingu Pi? DNS og IPv6 þurfa líka skýrt svar, því ýttri leysir lifir oft lengur en leiðin sem gerði hann nytsamlegan.
systemctl restart [email protected] systemctl is-active [email protected] journalctl -u [email protected] -n 20 --no-pager
Samþykktu breytinguna aðeins þegar þrír hlutir gilda samtímis: ný innkomandi tenging klárast, áframsent forrit nær áfangastað sínum um fyrirhugaða útgöngu, og bæði ferlin tilkynna enn væntanlegan jafningja sinn. Ef einn af þremur bregst, breyttir þú röngu tilviki eða rangri leið, og næsta skref er að lesa eininguna aftur í stað þess að endarræsa eitthvað annað.