OpenVPN-servilo kaj kliento sur unu gastiganto: kial klientoj falas
Gastiganto, kiu servas per OpenVPN kaj ankaŭ mem uzas ĝin, povas teni sian tunelon supren dum lokaj klientoj perdas respondojn. Du aferoj klarigas tion: komuna adresaro kaj nova implicita vojo.
Aldonu klientan profilon al maŝino, kiu jam funkciigas VPN-servilon, kaj la origina servo estos la unua viktimo. La nova tunelo eble neniam establiĝos, aŭ ĝi eble leviĝos dum la ekzistantaj klientoj de la servilo silente ĉesas ricevi respondojn. Du kolizioj produktas ambaŭ rezultojn: tunela adresaro jam uzata, kaj implicita vojo instalita de la nova klienta duono, kiu kovras la tutan tabelon. Neniu el ili produktas OpenVPN-erarmesaĝon, kaj tial la fiasko estas legata kiel servila problemo.
Unu maŝino, du roloj, kaj du neakordigeblaj respondoj pri tio, kien la respondoj devas iri.
Sama adresaro, du serviloj: kiu venkas
Ĉiu servila kazo bezonas propran tunelan subreton. Kopii linion kiel server 10.8.0.0 255.255.255.0 en la duan agordon donas al du kazoj la saman prefikson, kaj la rezulto estas aŭ rifuzo starti aŭ silenta konkurado, en kiu klientoj de unu servilo ricevas adresojn, kiujn la alia ankaŭ kredas siaj. Malsamaj UDP-pordoj kaj malsamaj aparataj nomoj ne helpas, ĉar nek unu nek la alia tuŝas la adresan spacon. Ŝanĝu la duan adresaron kaj ŝanĝu ĝin ĉie, kie la vojoj mencias ĝin.
Listigu, kio estas viva antaŭ redakti: ip -4 addr show listigas la tunelajn aparatojn, ss -lunp listigas la aŭskultantojn, kaj systemctl list-units nomas la unuojn. Unu rigardo al la tunelaj adresoj decidas, ĉu la adresaroj kolizias.
Kion la klienta profilo aldonas al la tabelo
La klienta duono skribas vojojn tuj kiam ĝi konektiĝas. redirect-gateway def1 dividas la implicitan vojon en 0.0.0.0/1 plus 128.0.0.0/1, ambaŭ enkursigitaj tra la nova aparato, kune kun gastiga vojo al la fora servilo, kiu estas intence fiksita al la fizika interfaco. Tiu fiksado ekzistas por ke la tunelo konservu vojon por sia propra transporto. Ĉio alia, inkluzive la respondojn, kiujn la loka servilo ŝuldas al siaj propraj klientoj, nun sekvas la novan implicitan vojon kaj eliras tra la fora ligilo.
Do la dua kolizio ne estas rompita tunelo. Ĝi estas funkcianta tunelo en la malĝusta loko de la tabelo.
Tri manieroj teni la rolojn apartaj
La malplej invada ripeto tenas la implicitan vojon ekster la klienta profilo: route-nopull plus eksplicitaj linioj route por la foraj prefiksoj, tiel ke la loka tabelo ŝanĝiĝas nur tie, kie vi petis. La sekva paŝo estas politika regulo, kiu esceptas la lokan tunelan subreton, lasante respondojn al lokaj klientoj eliri per la interfaco, per kiu ili alvenis, eĉ kiam implicita vojo ekzistas. La plej zorga estas aparta reta nomspaco por la klienta rolo, kiu tute forigas la komunan tabelon kaj kostas duan enkursigan kuntekston por prizorgi.
Kiun ajn vojon vi elektos, la escepto devas nomi la lokan tunelan subreton, ne la LAN. La respondo, kiun la loka servilo sendas, havas tunelan adreson kiel celon, do LAN-forma escepto neniam kongruas kun ĝi.
Kiu el la du kazoj kulpas
Haltigu la klientan kazon kaj retestu la originajn klientojn. Tuja resaniĝo signifas enkursigon, ne la servilon. Revenigu la klienton kaj spursekvu unu solan respondon per ip route get, al kiu doniĝas kaj fonta kaj cela adreso, kio montras la vojon, kiun la kerno elektus, kaj poste observu la interfacon, kiun la pakaĵoj vere uzas, per tcpdump -ni any port 1194. La statusa dosiero de la servilo, skribata ĉiujn kelkajn sekundojn per la direktivo status, enhavas la liston de konektitaj klientoj kaj bajtajn nombrilojn por ambaŭ direktoj.
Legu tiujn nombrilojn unu kontraŭ la alia. Trafiko, kiu eliras kaj neniam revenas, estas enkursiga respondo, ne manprema problemo.