Kjede to OpenVPN-klientar på éin Linux-vert med fwmark

Å stabla ein andre OpenVPN-klient på éin Linux-vert feilar på ein av to stader. Anten når ikkje den indre klienten sin eigen server fordi den ytre tunnelen har teke over den transporten, eller den andre klienten skriv om rutetabellen og den første tunnelen sluttar å verke. Begge problema ligg i rutinga, ikkje i krypteringa, og begge vert løyste før den nye tunnelen ber nokon applikasjonstrafikk. Adressene her er illustrative: tun0 er den ytre tunnelen, 203.0.113.9 er den indre serveren, og TCP 9999 er flyta som må bruke den indre vegen.

To feilmodus, éin rutetabell

Ein indre klient opnar ein UDP-socket mot serveren sin, og den socketen følgjer gjeldande rutetabell som kvar annan. Viss den ytre tunnelen alt eig standardruta, går handsamingpakningane inn i den ytre tunnelen. Det verkar berre når den ytre serveren kan nå den indre serveren og den andre sida godtek å bera flyta; elles stoggar handsaminga og klienten prøver på nytt.

Den andre feilen kjem frå push frå serveren. Den vanlege pushen er redirect-gateway def1, som installerer 0.0.0.0/1 og 128.0.0.0/1 i staden for å erstatta standardruta. To klientar som kvar installer sitt eige /1-par kolliderer difor, og det nyaste paret vinn for nesten alle mål. Sjå etter dei to prefiksa i tabellen når ein tunnel døyr etter at den andre koplar til, fordi standardruta sjølv kanskje aldri har endra seg.

Merk flyta og gje ho ein tabell

Styr den valde trafikken ved å merka han i mangle-tabellen og matche merket i ein policyregel. Regelen peikar på ein eigen tabell der standardruta er den indre eininga, slik at berre merkte pakkar tek den indre vegen.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Dei fleste feila i dette regelsettet kjem frå to mistak. Merkeverdien som brannmuren set, og verdien regelen matchar, må vera identiske, fordi avvik ikkje gjev nokon feil og ingen effekt. Og PREROUTING ser berre pakkar som kjem utanfrå, så ei tilkopling som startar på denne verten treng ein OUTPUT-regel med same match før ho i det heile vert merkt.

Tak ruteeigarskapet frå den andre klienten

To alternativ hindrar den andre klienten i å redigera tabellen, og dei verkar på ulike stader. route-nopull ignorerer dei pusja rutealternativa, så ingenting vert installert. route-noexec godtek dei pusja alternativa inn i miljøet til klienten, men lèt tabellendringa vera opp til ein hook, og det er det du vil når du treng å sjå kva serveren baud på.

Hooken køyrer med dei pusja verdiane i miljøet sitt, og han bør berre leggja til oppføringane du godkjende. Gjer han idempotent: tøm tabellen han eig før du byggjer han opp att, og ikkje gå ut frå at førre køyring etterlét ein rein tilstand. Ei attkopling kallar hooken på nytt, og ein hook som legg til utan å tøma, samlar dupliserte ruter.

Vel éin eigar og skriv han ned. Ein profil som set båe alternativa, eller ein hook som konkurrerer med eit manuelt skript, gjev ein tabell ingen kan forklare seinare.

Fest båe serveradressene

Den indre serveren treng ei vertsrute gjennom den ytre eininga før den indre klienten koplar til. Den oppføringa er det som held den indre transporten inne i den ytre tunnelen i staden for å la han følgja standardruta.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Legg òg til ei tilsvarande vertsrute for den ytre serveren i hovudtabellen, elles kan ei attkopling rute transporten til den ytre klienten sjølv inn i sin eigen tunnel. Rekkjefølgja er ikkje valfri: legg til desse oppføringane etter at det relevante grensesnittet finst, altså ein hook eller eit skript som køyrer etter tilkoplinga. Ei rute som peikar på ei eining som er nede, vert fjerna eller ignorert, så ei oppføring skriven ved oppstart overlever ikkje sekvensen du antok.

Sjekk oppslaget i staden for å lesa heile tabellen. Utdata frå ruteoppslaget nemner eininga og kjeldeadressa kjernen vil bruke, og det er nøyaktig det klienten får når han opnar socketen sin.

Test kjeda og gjer feilen synleg

Fang på det ytre grensesnittet medan den indre klienten koplar til. Den indre handsaminga skal visast som kryptert nyttelast inne i den ytre tunnelen; viss ho viser seg som vanleg UDP til 203.0.113.9, manglar vertsruta og kjeda vart aldri bygd.

Ei kjede som stille fell tilbake til den fysiske uplinken er det verste utfallet, fordi grensesnittilstanden ikkje kunngjer noko og den indre trafikken går ut frå feil kjeldeadresse. Viss den andre klienten kan kopla direkte til på nytt når den ytre tunnelen fell, deaktiver den vegen eller bind han til det ytre grensesnittet slik at feilen vert synleg.

Avslutt med to flytar og éin regelutskrift: ei merkt og ei umerkt tilkopling skal ta ulike vegar, og ip rule show skal lista prioriteten du hadde tenkt. Viss båe flytane tek same veg, vert merket ikkje brukt der du trur.