Kaks OpenVPN tunnelit ühel Linuxi hostil: kellele kuulub marsruut?

Kaks profiili on ühendatud ja üks neist kannab vaikselt liiklust, mis on mõeldud teisele. Linuxi host suudab mõlemat OpenVPN-klienti korraga probleemideta käitada. Mida ta teha ei suuda, on teie eest otsustada, milline protsess tohib millist prefiksit nõuda. See otsus tuleb teha enne, kui teine tunnel üles tuleb, mitte pärast seda, kui ressurs lakkab vastamast.

Alustage tööst, mida teine ühendus peab tegema

Ühe profiili kaudu kättesaadav kontor ja teise kaudu kättesaadav labor vajavad mõlemat tunnelit üleval ja mitte kumbagi neist kõike nõudmas. Üks kangekaelne rakendus, mis peab väljuma teise profiili kaudu, vajab poliitikareeglit, mitte teist vaikimisi marsruuti. Varuühendus vajab korraga ainult ühte töötavat tunnelit, seega ei peaks varu masinaga koos käivituma.

Need on kolm erinevat konfiguratsiooni ja neid aetakse segi, sest kõik kolm algavad ühtemoodi: teine profiil ja edukas ühendus. Kirjutage esmalt kavandatud paigutus üles ja seejärel seadistage selle poole. Üks lause kavatsusest säästab tunni paketipüügi aega.

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

Esimene käsk loetleb töötavad eksemplarid, sealhulgas need, mis on käsitsi väljaspool haldurit käivitatud. Teine trükib praeguse vaikimisi nõude, mis on olek, mida peate hiljem selgitama.

Kattuvad poolid purunevad enne marsruutimist

Kaks serverit jagavad mõnuga aadresse samast 10.8.0.0/24-st. Klient hoiab siis ühe prefiksi sees kahte liidest, ilma et miski ütleks, milline sihtkoht kuulub millisele, ja tulemuseks olev käitumine näeb välja nagu marsruutimise rike, kuid on tegelikult nummerdamise rike. Ümbernummerdamine maksab ühe konfiguratsioonimuudatuse; iga järgnev marsruutimise möödahiilimine maksab nädalavahetuse. Kontrollige pooli enne, kui lisate sellele marsruudi.

Vaadake ka kohalikku LAN-i. Kodune LAN numbriga 192.168.1.0/24, mille üks tunnel samuti paljastab, tekitab sama mitmetähenduslikkuse, ja sümptomiks on hostinimi, mis laheneb, kuid ühendus ei lõpe kunagi. See näeb välja nagu nimelahenduse rike, kuni trükite marsruudid.

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

Võrrelge mõlemat väljundit kahe serverikonfiguratsiooniga enne, kui puudutate klienti. Kui prefiksid kattuvad, peatuge ja nummerdage ümber, sest ükski arv taaskäivitusi ei eralda neid.

Andke igale profiilile oma üksus ja igale prefiksile omanik

Iga profiil saab oma eksemplarinime ja oma konfiguratsioonifaili, seega office-nimeline eksemplar laadib office.conf-i, samal ajal kui lab-nimeline laadib lab.conf-i. Kinnitage see vastendus teenusehalduri kaudu, selle asemel et usaldada katalooginimekirja, sest drop-in võib muuta, milline fail laaditakse. Vale vastendus tähendab, et te reguleerite profiili, mis ei tööta.

Seejärele otsustage, kes marsruute paigaldab. Kui serverid lükkavad kokkusobimatuid komplekte, siis kas keelduge lükkest ja loetlege prefiksid ise, või laske ühel profiilil vaikimisi marsruut hoida ja juhtige teist poliitikareeglitega. Kaks protsessi, mis mõlemad paigaldavad vaikimisi marsruudi, lõpevad vaikse võitja ja kirjaliku otsuseta.

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

Esimene näitab ühikut koos iga alistamisega, mis muudab selle argumente. Teine näitab, kas profiil üldse lähetatud marsruute aktsepteerib, ja see on lüliti, mis määrab kõik edasise.

Märgised hoiavad vastuseid liidesel, kust need saabusid

Kui iga tunnel teenindab erinevaid allikaid, võib vastus väljuda vale lingi kaudu ja ühendus sureb pärast esimest paketti. Muster, mis püsib, on saabuvate pakettide märgistamine sisendliidese järgi, selle märgise taastamine vastusel ja igale märgisele oma vaikimisi lüüsiga tabeli andmine.

Lõtv pöördtee filtreerimine tuleb tavaliselt mõjutatud liideste jaoks lõdvendada, sest vastus saabub õiguspäraselt lingi kaudu, mida põhitabel kunagi ei valiks. Hoidke märgised kitsad, et need ei haaraks kunagi tunnelite endi krüpteeritud liiklust, mis saadaks tunneli läbi iseenda.

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

Lugege olemasolevaid reegleid enne, kui lisate veel ühe. Dubleeritud prioriteedid ja unustatud tabelid on tavaline põhjus, miks märgisepoliitika näib üldse mõju puuduvat.

Tõestage isolatsiooni, peatades ühe lingi

Mõlema tunneli üleval olles registreerige iga liidese aadress, marsruut ühe hostini iga tunneli taga ja tee, mille võtab mitteseotud sihtkoht. Küsige otsingut tuumalt, selle asemel et lugeda ühte tabelit, sest üks tabel ei näita kunagi lõplikku otsust.

Seejärel peatage üks eksemplar ja jälgige, kuidas selle liides ja marsruudid kaovad, samal ajal kui teine jätkab. Katkestus ellujäänus tähendab, et kaks jagavad endiselt seadmenime, marsruuti või tulemüürireeglit, mida keegi ei eraldanud.

Tooge peatatud profiil tagasi ja korrake samu kontrolle. Kui tunnel jääb ellu ainult esimesel käivitamisel pärast taaskäivitust, vaatate elutsükli defekti, mitte marsruutimise disaini.