Kahe OpenVPN-kliendi aheldamine ühel Linuxi hostil fwmarki abil

Teise OpenVPN-kliendi lisamine ühele Linuxi hostile ebaõnnestub ühes kahest kohas. Kas sisemine klient ei saa oma serverini, sest väline tunnel on selle transpordi üle võtnud, või kirjutab teine klient marsruuditabeli ümber ja esimene tunnel lakkab töötamast. Mõlemad probleemid on marsruutimises, mitte krüpteerimises, ja mõlemad lahendatakse enne, kui uus tunnel hakkab kandma rakendusliiklust. Aadressid on siin illustratiivsed: tun0 on väline tunnel, 203.0.113.9 on sisemine server ja TCP 9999 on voog, mis peab kasutama sisemist teed.

Kaks tõrkerežiimi, üks marsruuditabel

Sisemine klient avab oma serverile UDP-pesa ja see pesa järgib praegust marsruuditabelit nagu iga teine. Kui väline tunnel omab juba vaikeimarsruuti, lähevad kätluspaketid välisesse tunnelisse. See töötab ainult siis, kui väline server saab sisemise serverini ja teine pool nõustub voogu kandma; muidu kätlus takerdub ja klient proovib uuesti.

Teine tõrge tuleb serveri pushist. Tavaline push on redirect-gateway def1, mis paigaldab 0.0.0.0/1 ja 128.0.0.0/1, selle asemel et vaikeimarsruuti asendada. Seetõttu põrkuvad kaks klienti, kellest kumbki paigaldab oma /1 paari, ja uusim paar võidab peaaegu iga sihtkoha puhul. Otsige neid kahte prefiksit tabelist, kui tunnel sureb pärast teise ühendumist, sest vaikeimarsruut ise ei pruugi kunagi muutunud olla.

Märkige voog ja andke sellele tabel

Suunake valitud liiklust, märkides selle mangle-tabelis ja sobitades märgi poliitikareeglis. Reegel osutab sihtotstarbelisele tabelile, mille vaikeimarsruut on sisemine seade, nii et sisemise tee võtavad ainult märgitud paketid.

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

Enamik selle reeglistiku tõrkeid tuleb kahest veast. Tulemüüri seatud märgiväärtus ja reegli sobitatav väärtus peavad olema identsed, sest erinevus ei anna ei viga ega mõju. Ja PREROUTING näeb ainult väljast saabuvaid pakette, seega vajab sellel hostil algatatud ühendus enne märkimist OUTPUT-reeglit sama sobitusega.

Võtke marsruutide omandiõigus teiselt kliendilt ära

Kaks valikut takistavad teist klienti tabelit muutmast ja need toimivad eri kohtades. route-nopull eirab pushitud marsruudivalikuid, nii et midagi ei paigaldada. route-noexec võtab pushitud valikud kliendi keskkonda vastu, kuid jätab tabelimuudatuse hookile, mis on täpselt see, mida vajate, kui peate nägema, mida server pakkus.

Hook töötab pushitud väärtustega oma keskkonnas ja peaks lisama ainult need kirjed, mille te kinnitasite. Tehke see idempotentseks: tühjendage tabel, mida see omab, enne ülesehitamist ja ärge eeldage, et eelmine käivitus jättis puhta oleku. Taasühendus kutsub hooki uuesti ja hook, mis lisab ilma puhastamata, kogub duplikaatseid marsruute.

Valige üks omanik ja kirjutage see üles. Profiil, mis seab mõlemad valikud, või hook, mis võistleb käsitsi skriptiga, loob tabeli, mida keegi hiljem seletada ei oska.

Kinnitage mõlemad serveriaadressid

Sisemine server vajab hostimarsruuti läbi välisseadme enne, kui sisemine klient ühendub. Just see kirje hoiab sisemise transpordi välise tunneli sees, selle asemel et lasta sellel vaikeimarsruuti järgida.

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

Lisage vastav hostimarsruut ka välise serveri jaoks peamisesse tabelisse, muidu võib taasühendus suunata välise kliendi enda transpordi tema enda tunnelisse. Järjekord ei ole valikuline: lisage need kirjed pärast seda, kui asjaomane liides on olemas, see tähendab hooki või skriptiga, mis töötab pärast ühendamist. Maas olevale seadmele osutav marsruut eemaldatakse või jäetakse tähelepanuta, nii et alglaadimisel kirjutatud kirje ei ela üle teie eeldatud järjestust.

Kontrollige otsingut, mitte lugege kogu tabelit. Marsruudiotsingu väljund nimetab seadme ja lähteaadressi, mida kernel kasutab, ja täpselt selle saab klient oma pesa avades.

Testige ahelat ja tehke tõrge nähtavaks

Püüdke välisliidesel, kui sisemine klient ühendub. Sisemine kätlus peaks välise tunneli sees paistma krüpteeritud kandevõimena; kui see paistab tavalise UDP-na aadressile 203.0.113.9, on hostimarsruut puudu ja ahelat ei ehitatud kunagi.

Ahel, mis vaikselt füüsilisele üleslingile tagasi langeb, on halvim tulemus, sest liidese olek ei teata midagi ja sisemine liiklus väljub valelt lähteaadressilt. Kui teine klient saab välise tunneli langedes otse uuesti ühenduda, keelake see tee või siduge see välisliidesega, et tõrge oleks nähtav.

Lõpetage kahe voo ja ühe reeglitõmmisega: märgitud ja märkimata ühendus peaksid minema eri teid ning ip rule show peaks loetlema kavatsetud eelistuse. Kui mõlemad vood lähevad sama teed, ei rakendata märki seal, kus te arvate.