Kaksi OpenVPN-asiakasta yhdellä Linux-yhdyskäytävällä: jaa käytäntö

Kaksi OpenVPN-taustaprosessia voivat molemmat ilmoittaa onnistuneesta tunnelista, kun yhdyskäytävä lähettää jokaisen asiakkaan samaa kautta. Mikään kättelyssä ei päätä, mitä tunnelia asiakas käyttää; sen päättää ydin, paketti paketilta, kulkemalla käytännön säännöt läpi ja sitten taulun, jonka kukin sääntö nimeää. Kun asiaa katsoo näin, kokoonpano lakkaa koskemasta OpenVPN-asetuksia ja muuttuu reititysmatriisiksi, jolla on kaksi omistajaa.

Ydin päättää, ei taustaprosessi

Edelleenlähetetty paketti saapuu LAN-liittymään ja reitityskoodi arvioi sääntöluettelon prioriteettijärjestyksessä. Ensimmäinen sääntö, jonka valitsin täsmää, nimeää taulun, ja kyseisen taulun reitit valitsevat lähtölaitteen. Jos taulussa ei ole täsmäävää reittiä, haku jatkuu seuraavaan sääntöön, ja juuri tämä yksityiskohta saa puolivalmiin asennuksen epäonnistumaan hiljaa eikä äänekkäästi.

Tunneliprosessilla ei ole tässä kulussa sanansijaa. Se luo liittymän ja voi asentaa reittejä, mutta se, tuleeko tietyn asiakkaan paketti siihen liittymään, riippuu täysin taulusta, johon se lähetettiin. Niinpä kaksi tunnelia, joilla on samat tuodut reitit, kilpailevat, ja viimeinen kirjoittaja voittaa kaikkien osalta. Siksi asennus voi näyttää konfiguraatiotiedostoissa tasapainoiselta ja silti lähettää kaikki asiakkaat yhden taustaprosessin kautta.

Anna kullekin instanssille oma resurssijoukkonsa

Aloita nimistä, sillä uudelleenkäytetyt nimet ovat se tapa, jolla kaksi instanssia päätyy vahingossa jakamaan tilan. Anna erilliset tunnelilaitteet, erilliset konfiguraatiotiedostot, erilliset tunnistetiedot ja erilliset palveluyksiköt. Kirjaa kunkin instanssin ulkoinen päätepiste ja tunneliosoite samaan tauluun kuin käytännön matriisi, jotta myöhemmällä muutoksella on yksi paikka katsoa.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull pitää palvelimen työntämät reitit kohdallisen taulun ulkopuolella, mitä juuri haluat, kun käytäntötaulujen on tarkoitus olla nimenomaisia. Kannattaa tarkistaa käsikirjasta eikä olettaa, työntääkö tietty palvelin myös redirect-gateway-vaihtoehdon ja tukeeko asiakasversiosi suodatinmuotoa.

Kirjoita matriisi: lähde, taulu, laite

Lisää jokaiselle asiakasryhmälle sääntö, joka valitsee taulun lähdeosoitteen perusteella, ja aseta sitten aiottu polku siihen tauluun:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Taulu tarvitsee kohdereitit, jotka ryhmällä pitäisi olla, sekä kaikki paikalliset tai hallinnolliset poikkeukset, jotka pitävät yhdyskäytävän käyttökelpoisena. Taulu, joka sisältää vain oletusreitin, on kyseisen ryhmän täystunnelikäytäntö, mikä voi olla täsmälleen oikein, mutta sen pitäisi olla päätös eikä puuttuva kohta.

Tunnelin oma liikenne ei ole asiakasryhmässä

Kunkin taustaprosessin salatut paketit syntyvät yhdyskäytävällä itsellään ja on osoitettu ulkoiselle vastapuolelle. Sääntö, joka täsmää vain asiakkaan lähde-etuliitteeseen, jättää ne paketit rauhaan, minkä vuoksi lähteeseen rajatut säännöt ovat turvallisempia kuin säännöt, jotka täsmäävät kaikkeen. Sääntö ilman valitsinta voi kaapata tunnelin oman liikenteen ja lähettää sen takaisin tunnelin kautta, ja sitten yhteys epäonnistuu tavalla, joka näyttää palveluntarjoajan ongelmalta.

Pidä paikallinen hallintayhteys ja alikerroksen polku nimenomaisesti käytäntötaulujen ulkopuolella. Kirjoita ne poikkeukset matriisin viereen; ne ovat osa suunnittelua, eivät kiertotie, joka pitää löytää uudelleen tapauksen aikana.

Polun valinta ei salli sitä

Edelleenlähetyksen lupa on toinen päätös, joka tehdään myöhemmin polulla. Palomuurisääntö, joka hyväksyy toisen tunnelin kautta lähtevät paketit, ei saa reitityskoodia valitsemaan sitä, eikä oikea taulu anna lupaa edelleenlähetykseen. Molempien pitää olla olemassa, ja testi, joka todistaa vain toisen, johtaa sinut harhaan toisen osalta. Kun yksi ryhmä toimii ja toinen ei, tarkista nämä kaksi vaihetta erikseen sen sijaan että kirjoittaisit taulut uudelleen.

Lähteen käännös on kolmas päätös, ja se tulisi rajata lähderyhmään ja tunnelilaitteeseen, joka sen todella kuljettaa. Lisää kahdelle instanssille oma ketju sen sijaan että tyhjentäisit postrouting-ketjun, koska asiaan liittymättömillä palveluilla voi olla siellä merkintöjä ja tyhjennys poistaa ne äänettömästi.

Mitä tapahtuu, kun yksi tunneli putoaa

Päätä vikatilanteen käyttäytyminen etukäteen. Kun tunnelitaulu menettää reittinsä, haku putoaa seuraavaan sääntöön ja ryhmän liikenne jatkuu toisen tunnelin tai tavallisen ylälinkin kautta ilman mitään virhettä. Jos se ei ole hyväksyttävää, lisää päättävä sääntö, jonka prioriteettinumero on pienempi ja joka palauttaa kyseiselle lähteelle tavoittamattoman tuloksen, jotta menetys on näkyvissä eikä imeydy.

Lähetä tuore pyyntö jokaisesta lähderyhmästä ja kirjaa neljä tosiasiaa: valittu taulu, lähtölaite, käännetty lähde ja se, tuliko vastaus takaisin samaa polkua. Laske sitten yksi tunneli alas ja toista. Kaksi TUN-laitetta liittymäluettelossa todistaa, että molemmat taustaprosessit käynnistyivät; ne eivät kerro mitään siitä, kumpaa tietty asiakas käytti. Toinen ajo, jossa yksi tunneli on poissa, on se, joka näyttää, tekeekö varasääntösi sen, mitä tarkoitit.