Eraldatud väljund: VPN-i bassein usb0-l, lüüsi liiklus eth0-l

Kliendid ühenduvad ja autendivad end, seejärel väljub nende liiklus vale üleslingi kaudu, sest ainus vaikeimarsruut masinas kuulub lüüsile endale. Selle vaikeimarsruudi asendamine lõhuks masina enda uuendused ja haldusjuurdepääsu, seega peab valik olema kitsam kui „kogu liiklus“. Toimiv vorm on poliitikareegel, mis põhineb kliendibasseini sisemisel lähteaadressil ja osutab teisele marsruutimistabelile, millele kuulub alternatiivne WAN. Sealt edasi käsitleb kontrollnimekiri täielikkust ja tõrke käitumist, mitte reeglit ennast.

Kinnitage, et lähteaadress püsib marsruutimisotsuseni

Poliitikareegel, mis vastab lähtepiirkonnale, rakendub ainult siis, kui pakett kannab seda lähtet otsingu hetkel veel edasi. Edastatud kliendiliiklus teeb seda seni, kuni miski ülalpool ei ole seda enne marsruutimist ümber kirjutanud. Lüüsi enda loodud liiklus ei tee seda, ja just seetõttu võib lüüsi enda vaikeimarsruut jääda sinna, kus see on.

Siin eksitavad kohalikud testid. Lüüsil käivitatud curl on kohapeal loodud voog lüüsi aadressiga, seega võtab see põhitabeli ega tõesta kliendi tee kohta midagi. Testige ühendatud kliendi pealt või looge liiklus lähtega, mis tõesti kuulub basseini.

Alustage tegelike väärtuste kirjapanekust: basseini prefiks, seda kandev tunneliliides, teise WAN-i aadress ja järgmine hüpe ning tabelinumber, mida kavatsete kasutada. Enne uute reeglite lisamist puhastage varasema katse vanad reeglid, sest erinevate prioriteetidega dubleeritud reeglid tekitavad tõrkeid, mis tunduvad juhuslikud.

Koostage valitud tabel, mis on täielik

Tabel ei ole vaikeimarsruut sõbraga. See vajab piisavalt marsruute, et iga otsing laheneks selle sees, sealhulgas WAN-i alamvõrgu ühendatud marsruut, et järgmine hüpe oleks kättesaadav. Basseini 10.77.0.0/24 jaoks tun1 peal, WAN-i aadress 203.0.113.20/24 järgmise hüppega 203.0.113.1 ja tabel 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

Reegel asub prioriteedil allpool iga olemasolevat kõikehaaravat reeglit, seega sobivad kliendid tabavad esmalt tabelit 600 ja kõik muu langeb põhitabelisse. ip-rule viide kirjeldab järjestatud otsingumudelit ja valija süntaksit täielikult.

Mõelge siis, mida tabel ei sisalda. Sihtkoht, millel on marsruut ainult põhitabelis, näiteks eth0 kaudu kättesaadav haldusalamvõrk, ei leita tabelist 600 ega lange tagasi põhitabelisse, kui seal on juba vaikeimarsruut. Kui need teed loevad, lisage need valitud tabelisse selgesõnaliselt, mis on VPN-i väljundtabeli jaoks tavaliselt õige vastus.

Hoidke kuulaja enda liiklus poliitikast väljas

OpenVPN kuulajal on oma välimine ühendus, mida kantakse selle üleslingi kaudu, millega klient selleni jõudis. See liiklus peab säilitama tagasitee, millega see saabus, ja lai reegel, mis katab serveri avaliku aadressi või kogu tunneliliidese, võib selle alternatiivsesse tabelisse tirida. Piiritlege reegel sisemise basseiniga ja mitte millegi muuga.

Tagasitee filtreerimine väärib pilku samal põhjusel. Kui vastused klientidele väljuvad usb0 kaudu, samal ajal kui päring saabus teise lingi kaudu, võib range rp_filter seade visata kõrvale paketid, mida marsruutimispoliitika peab kehtivateks. Kontrollige mõlema liidese kehtivaid sysctl väärtusi enne, kui järeldate, et reegel ebaõnnestus.

Järjekord loeb ka kõige muu suhtes masinas. Dockeri sillad, teine VPN ja kõik varasemad reeglid teenusepakkuja kujutisest lisavad prioriteete, seega lugege kogu reeglite nimekirja, selle asemel et eeldada, et prioriteet 100 on üksi.

Viige edastamine ja tõlkimine marsruudiga kooskõlla

Marsruutimine valib üleslingi; see ei anna edastamiseks luba. Kernelil peab olema IPv4 edastamine lubatud ja tulemüür peab vastu võtma suuna kliendilt WAN-i ja tagasiliikluse. Õige tabel, mille FORWARD-ahel voo maha viskab, annab sama sümptomi nagu puuduv marsruut, seepärast kontrollitakse mõlemat samas läbimises.

Kui teine WAN ei marsruudi privaatset basseini teie juurde tagasi, tõlkige lähteaadress sellel väljundil. Dünaamilise aadressiga liidese jaoks on tavaline valik kitsas masquerade-reegel, mis on piiratud basseini ja liidesega:

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

Ulatus loeb siin rohkem kui sihtmärk. Masquerade-reegel, mis vastab mis tahes väljuvale liidesele, kirjutab ümber ka liikluse, mis väljub õigesti eth0 kaudu, ja see peidab marsruutimisvead nende parandamise asemel. Tõlkimine toimub pärast marsruutimisotsust, seega ei saa see kunagi parandada valele üleslingile saadetud paketti.

Tunneli üldkulud vajavad samuti tähelepanu, kui teed erinevad. Kui kliendid lepivad kokku suure TCP MSS-i ja alternatiivsel WAN-il on madalam MTU või tunnel selle sees, takerduvad suured segmendid, samal ajal kui väikesed töötavad. MSS-i kärpimine edastusteel muudab selle prognoositavaks käitumiseks, mitte aeg-ajalt kinnikiilumiseks.

Otsustage, mis juhtub, kui usb0 kaob

Tühi tabel ei ole tõrke korral sulguv olek. Kui sobiv marsruut kaob, jätkub otsing järgmise reegliga, jõuab põhitabelisse ja võtab eth0 vaikeimarsruudi. Liiklus, mis pidi väljuma teise WAN-i kaudu, väljub vaikselt esimese kaudu, mis on poliitikapõhise marsruutimise juurutuse puhul tavaliselt tulemus, mida te kõige vähem soovite.

Kui selline tagasilangemine on vastuvõetamatu, lisage tabelisse 600 selgesõnaline lõppmarsruut, näiteks blackhole-vaikeimarsruut, või laske bassein tulemüüris maha, kuni liides on maas. Kumbki valik on otsus, mille saate kirja panna; vaikimine ei ole.

Püsivus on viimane punkt. Kes iganes omab mõlemat linki, olgu selleks võrguhaldur, saatjaskript või ühenduse elutsükkel, peab igal taasühendusel marsruudid ja reegli uuesti looma, ilma dublette lisamata. Kontrollige päringuga päris kliendilt ja eraldi päringuga lüüsilt, kinnitage täheldatud väljund mõlemal, seejärel tõmmake teine WAN välja ja vaadake, milline kahest kavandatud tulemusest tegelikult juhtub. IPv6 vajab oma tabelit, reeglit ja tõlget; ülaltoodud IPv4 reegel ei ütle selle kohta midagi.