Du OpenVPN-tuneloj sur unu Linuksa gastiganto: kiu posedas la itineron?

Du profiloj estas konektitaj, kaj unu el ili kviete portas trafikon destinatan al la alia. Linuksa gastiganto povas samtempe ruli ambaŭ OpenVPN-klientojn sen malfacilo. Kion ĝi ne povas fari, estas decidi anstataŭ vi, kiu procezo rajtas postuli kiun prefikson. Tiu decido devas esti farita antaŭ ol la dua tunelo supreniĝos, ne post kiam rimedo ĉesas respondi.

Komencu de la tasko, kiun la dua ligo devas plenumi

Oficejo atingebla per unu profilo kaj laboratorio atingebla per alia bezonas ambaŭ tunelojn supraj kaj neniun el ili postulantan ĉion. Unu obstina aplikaĵo, kiu devas eliri per la dua profilo, bezonas politikan regulon anstataŭ duan implicitan itineron. Rezerva ligo bezonas nur unu tunelon funkciantan samtempe, do la rezerva ne devus starti kun la maŝino.

Tiuj estas tri malsamaj agordaroj, kaj ili konfuziĝas ĉar ĉiuj tri komenciĝas same: dua profilo kaj sukcesa konekto. Unue skribu la intencatan aranĝon, poste agordu al ĝi. Unu frazo pri intenco ŝparas horon da paketa kaptado.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

La unua komando listigas la funkciantajn instancojn, inkluzive tiujn startitajn mane ekster la administrilo. La dua presas la nunan implicitan postulon, kaj tio estas la stato, kiun vi devos klarigi poste.

Interkovrantaj naĝejoj rompiĝas antaŭ ol la enkursigo

Du serviloj volonte disdonos adresojn el la sama 10.8.0.0/24. La kliento tiam tenas du interfacojn ene de unu prefikso sen io ajn diranta, kiu celo apartenas al kiu, kaj la rezulta konduto similas enkursigan fuŝon sed fakte estas numerada fuŝo. Renumeri naĝejon kostas unu agordan redakton; ĉiu posta enkursiga provizora solvo kostas semajnfinon. Kontrolu la naĝejon antaŭ ol aldoni itineron por ĝi.

Rigardu ankaŭ la lokan LAN. Hejma LAN numerita 192.168.1.0/24, kiun unu tunelo ankaŭ elmetas, produktas la saman ambiguecon, kaj la simptomo estas gastigantnomo, kiu solviĝas dum la konekto neniam finiĝas. Tio aspektas kiel nomosolva fuŝo ĝis vi presos la itinerojn.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Komparu ambaŭ eligojn kun la du servilaj agordaroj antaŭ ol tuŝi la klienton. Se la prefiksoj interkovriĝas, haltu kaj renumera, ĉar neniu kvanto da restartigoj apartigos ilin.

Donu al ĉiu profilo sian unuon kaj al ĉiu prefikso posedanton

Ĉiu profilo ricevas sian propran instancan nomon kaj sian propran agordan dosieron, do la instanco nomata office ŝargas office.conf dum tiu nomata lab ŝargas lab.conf. Konfirmu tiun mapadon per la servadministrilo anstataŭ fidi dosierujan listigon, ĉar drop-in povas ŝanĝi kiun dosieron oni ŝargas. Erara mapado signifas, ke vi agordas la profilon, kiu ne funkcias.

Poste decidu, kiu instalas itinerojn. Kiam la serviloj puŝas malkongruajn arojn, aŭ rifuzu la puŝon kaj listigu la prefiksojn mem, aŭ lasu unu profilon teni la implicitan kaj direktu la alian per politikaj reguloj. Du procezoj, kiuj ambaŭ instalas implicitan itineron, finiĝas per silenta venkinto kaj sen skriba registro pri la decido.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

La unua montras la unuon kun ajna anstataŭigo, kiu ŝanĝas ĝiajn argumentojn. La dua montras, ĉu la profilo entute akceptas puŝitajn itinerojn, kaj tio estas la ŝaltilo, kiu decidas ĉion malsupren.

Markoj tenas respondojn sur la interfaco, de kiu ili alvenis

Kiam ĉiu tunelo servas malsamajn fontojn, respondo povas eliri per la malĝusta ligo kaj la konekto mortas post la unua paketo. La ŝablono, kiu teniĝas, estas marki alvenantajn paketojn laŭ eniga interfaco, restarigi tiun markon sur la respondo, kaj doni al ĉiu marko tabelon kun sia propra implicita enirejo.

Laksa inversa voja filtrado kutime devas esti malstreĉita por la koncernaj interfacoj, ĉar respondo leĝe alvenas per ligo, kiun la ĉefa tabelo neniam elektus. Tenu la markojn mallarĝaj por ke ili neniam kaptu la propran ĉifritan trafikon de la tuneloj, kio sendus la tunelon tra ĝi mem.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Legi la ekzistantajn regulojn antaŭ ol aldoni alian. Duplikataj prioritatoj kaj forgesitaj tabeloj estas la kutima kaŭzo, kial marka politiko ŝajnas tute sen efiko.

Pruvu izolecon haltigante unu ligon

Kun ambaŭ tuneloj supraj, registru la adreson de ĉiu interfaco, la itineron al unu gastiganto malantaŭ ĉiu tunelo, kaj la vojon, kiun prenas neligita celo. Petu la serĉadon de la kerno anstataŭ legi unu tabelon, ĉar unu tabelo neniam montras la finan decidon.

Poste haltigu unu instancon kaj observu ĝian interfacon kaj itinerojn malaperi dum la alia daŭras. Rompo en la postvivanto signifas, ke la du ankoraŭ dividas aparatan nomon, itineron aŭ fajroŝirman regulon, kiun neniu apartigis.

Redonu la haltigitan profilon kaj ripetu la samajn kontrolojn. Kiam tunelo postvivas nur la unuan starton post restartigo, vi rigardas vivciklan difekton, ne enkursigan dezajnon.