Erillinen lähtö: VPN-allas usb0:ssa, yhdyskäytävän liikenne eth0:ssa

Asiakkaat yhdistävät ja todentavat itsensä, ja sitten heidän liikenteensä poistuu väärää ylälinkkiä pitkin, koska koneen ainoa oletusreitti kuuluu yhdyskäytävälle itselleen. Sen oletusreitin korvaaminen rikkoisi koneen omat päivitykset ja hallintayhteyden, joten valinnan on oltava kapeampi kuin ”kaikki liikenne”. Toimiva muoto on käytäntösääntö, joka perustuu asiakasaltaan sisäiseen lähdeosoitteeseen ja osoittaa toiseen reititystaulukkoon, joka omistaa vaihtoehtoisen WANin. Siitä eteenpäin tarkistuslista koskee täydellisyyttä ja vikatilakäyttäytymistä, ei itse sääntöä.

Varmista, että lähdeosoite säilyy reitityspäätökseen asti

Käytäntösääntö, joka vastaa lähdealuetta, laukeaa vain, kun paketti kantaa kyseistä lähdettä vielä hakuvaiheessa. Edelleenohjattu asiakasliikenne tekee niin, kunhan mikään ylempänä ei ole kirjoittanut sitä uudelleen ennen reititystä. Yhdyskäytävän itse tuottama liikenne ei tee niin, ja juuri siksi sen oma oletusreitti voi pysyä paikallaan.

Tässä paikalliset testit johtavat harhaan. Yhdyskäytävällä ajettu curl on paikallisesti luotu virtaus yhdyskäytävän osoitteella, joten se ottaa päätaulukon eikä todista mitään asiakkaan polusta. Testaa yhdistetystä asiakkaasta tai luo liikennettä lähteestä, joka todella kuuluu altaaseen.

Aloita kirjaamalla todelliset arvot: altaan etuliite, sen kuljettava tunnelirajapinta, toisen WANin osoite ja seuraava hyppy sekä taulukkonumero, jota aiot käyttää. Tyhjennä aiemman yrityksen vanhat säännöt ennen uusien lisäämistä, sillä eri prioriteeteilla monistetut säännöt tuottavat vikoja, jotka näyttävät satunnaisilta.

Rakenna valittu taulukko, joka on täydellinen

Taulukko ei ole oletusreitti kaverin kanssa. Se tarvitsee tarpeeksi reittejä, jotta jokainen haku ratkeaa sen sisällä, mukaan lukien WANin aliverkon yhdistetty reitti, jotta seuraava hyppy on tavoitettavissa. Allas 10.77.0.0/24 tun1:ssä, WAN-osoite 203.0.113.20/24 seuraavalla hypyllä 203.0.113.1 ja taulukko 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

Sääntö on prioriteetiltaan minkä tahansa olemassa olevan kaiken sieppaavan säännön alapuolella, joten vastaavat asiakkaat osuvat ensin taulukkoon 600 ja kaikki muu putoaa päätaulukkoon. ip-rule-viite kuvaa järjestetyn hakumallin ja valitsimen syntaksin täysin.

Mieti sitten, mitä taulukko ei sisällä. Kohde, jolla on reitti vain päätaulukossa, kuten eth0:n kautta tavoitettava hallinta-aliverkko, ei löydy taulukosta 600 eikä palaa päätaulukkoon, kun siellä on oletusreitti. Jos nuo polut ovat tärkeitä, lisää ne valittuun taulukkoon nimenomaisesti, mikä on yleensä oikea vastaus VPN-lähtötaulukolle.

Pidä kuuntelijan oma liikenne käytännön ulkopuolella

OpenVPN-kuuntelijalla on oma ulkoinen yhteytensä, jota kuljetetaan sitä ylälinkkiä pitkin, jota asiakas saavutti sen. Sen liikenteen on säilytettävä saapumisreittinsä, ja laaja sääntö, joka kattaa palvelimen julkisen osoitteen tai koko tunnelirajapinnan, voi vetää sen vaihtoehtoiseen taulukkoon. Rajaa sääntö sisäiseen altaaseen eikä mihinkään muuhun.

Paluupolun suodatus ansaitsee vilkaisun samasta syystä. Kun vastaukset asiakkaille lähtevät usb0:n kautta samalla kun pyyntö saapui toista linkkiä pitkin, tiukka rp_filter-asetus voi pudottaa paketteja, joita reitityskäytäntö pitää kelvollisina. Tarkista molempien rajapintojen voimassa olevat sysctl-arvot ennen kuin päättelet säännön epäonnistuneen.

Järjestyksellä on merkitystä myös suhteessa kaikkeen muuhun koneessa. Docker-sillat, toinen VPN ja kaikki palveluntarjoajan imagen aiemmat säännöt lisäävät prioriteetteja, joten lue koko sääntöluettelo sen sijaan, että olettaisit prioriteetin 100 olevan yksin.

Sovita edelleenohjaus ja käännös reittiin

Reititys valitsee ylälinkin; se ei myönnä lupaa edelleenohjaukseen. Ytimessä on oltava IPv4-edelleenohjaus käytössä, ja palomuurin on hyväksyttävä suunta asiakkaasta WANiin ja paluuliikenne. Oikea taulukko, jonka FORWARD-ketju pudottaa virtauksen, tuottaa saman oireen kuin puuttuva reitti, siksi molemmat tarkistetaan samassa läpikäynnissä.

Jos toinen WAN ei reititä yksityistä allasta takaisin sinulle, käännä lähde kyseisessä lähdössä. Dynaamisen osoitteen rajapinnalle tavallinen valinta on kapea masquerade-sääntö, joka on rajattu altaaseen ja rajapintaan:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

Laajuus on tässä tärkeämpää kuin kohde. Masquerade-sääntö, joka vastaa mitä tahansa lähtevää rajapintaa, kirjoittaa uudelleen myös liikenteen, joka poistuu oikein eth0:n kautta, ja se piilottaa reititysvirheet niiden korjaamisen sijaan. Käännös ajetaan reitityspäätöksen jälkeen, joten se ei voi koskaan korjata väärälle ylälinkille lähetettyä pakettia.

Tunnelin ylimääräinen rasite vaatii huomiota myös silloin, kun polut eroavat. Jos asiakkaat neuvottelevat suuren TCP MSS:n ja vaihtoehtoisella WANilla on pienempi MTU tai sen sisällä tunneli, suuret segmentit juuttuvat pienien toimiessa. MSS:n rajaaminen edelleenohjauspolulla tekee siitä ennustettavaa käytöstä satunnaisen jumittumisen sijaan.

Päätä, mitä tapahtuu, kun usb0 katoaa

Tyhjä taulukko ei ole vikatilassa sulkeutuva tila. Jos vastaava reitti katoaa, haku jatkuu seuraavaan sääntöön, saavuttaa päätaulukon ja ottaa eth0:n oletusreitin. Liikenne, jonka piti poistua toisen WANin kautta, poistuu hiljaa ensimmäisen kautta, mikä käytäntöreititetyssä käyttöönotossa on yleensä se tulos, jota vähiten haluat.

Missä tällainen taantuma ei ole hyväksyttävää, lisää taulukkoon 600 nimenomainen päätösreitti, esimerkiksi blackhole-oletusreitti, tai pudota allas palomuurissa, kun rajapinta on alhaalla. Kumpi tahansa on päätös, jonka voit kirjoittaa; vaikeneminen ei ole.

Pysyvyys on viimeinen kohta. Kuka tahansa omistaa molemmat linkit, oli se verkkohallinta, lähetysskripti tai yhteyden elinkaari, sen on luotava reitit ja sääntö uudelleen joka yhdistämisellä lisäämättä kopioita. Varmista pyynnöllä todelliselta asiakkaalta ja erillisellä pyynnöllä yhdyskäytävältä, vahvista havaittu lähtö molemmissa, vedä sitten toinen WAN irti ja katso, kumpi kahdesta suunnittelemastasi tuloksesta todella tapahtuu. IPv6 tarvitsee oman taulukkonsa, sääntönsä ja käännöksensä; yllä oleva IPv4-sääntö ei kerro siitä mitään.