Kolm lahendust lahendavad sama laboriprobleemi: väike LAN peab väljuma WireGuard-partneri kaudu, samal ajal kui lüüs ise säilitab oma hariliku ühenduse üles. Peibutav otsetee on viia ruuteri vaikemarsruut tunnelisse, kuid see lõhub seadme enda haldustee ja kõik muu, mida see edasi suunab. Huvitav valik on poliitikapõhine marsruutimine, mis on piiratud ühe liidese ja ühe prefiksiga. Valige nende vahel, vastates kolmele küsimusele masina kohta, mis teil tegelikult on.

Otsustage, kus väljapääs elab

Esimene küsimus: kas see host suunab edasi ka millegi muu jaoks? Sihtotstarbeline laborilüüs talub vaikimisi kõike kõrvale jätvat edasisaatmispoliitikat. Tootmiskohustustega ruuter ei talub, ja konkureeriva reeglistiku ladumine hallatava tulemüüri peale on täpselt see viis, kuidas katkestusi planeeritakse. Teine: kas saate omada kahte poliitikaobjekti ja nende järjekorda üle taaskäivituste? Kolmas: kas teie partner volitab teie tunneli lähteaadressi ja pakub internetiväljapääsu? Partner, mis avab ainult privaatvõrgu, on teine toode ja ükski kohalik marsruudimuudatus ei paranda seda. Kui mõni vastus on ei, pange väljapääs hoopis nimeruumi või ühekordselt kasutatavasse virtuaalmasinasse.

Nimeruum või VM maksab mälu ja annab teile puhta plahvatusraadiuse. Poliitikapõhine marsruutimine maksab kaks reeglit ja jätab teile ühe silutava seadme.

Valige väljapääs, mis volitab teie lähte

Enamik selle labori tõrkeid juhtub enne, kui eksisteerib üksainus tulemüürireegel. Väljapääsu operaator peab aktsepteerima lähteaadressi, mida teie paketid pärast tõlget kannavad, ja selles lahenduses on see tunneli aadress, mitte LAN-i prefiks. Seetõttu kuulub maskeerimine lahendusse algusest peale, mitte hilise lisandina.

Kinnitage operaatoriga kolm asja: partner volitab teie tunneli aadressi, see suunab IPv4 edasi, selle asemel et ise lõpetada, ja rakendab väljuvat NAT-i. Ilma esimeseta jõuavad teie paketid kohale ja kaovad. Ilma kolmandata lahkuvad need privaatse lähtega ja surevad järgmisel hüppel. Seejärel kontrollige, et wg-quick ei paigalda oma vaikemarsruuti, mida hoiab ära Table = off; see säte summutab marsruutide loomist, mitte partneri AllowedIPs-kontrolle ega selle DNS-käsitlust.

Kaks poliitikaobjekti teevad juhtimise

Juhtimiseks on vaja tabelit ja reeglit. Tabel hoiab kahte marsruuti: LAN-i prefiks LAN-i liidesest välja ja vaikemarsruut tunnelist välja. Reegel saadab liikluse, mis saabub LAN-i liidesele ja kannab seda prefiksit, tabelisse. Kasutage iif valijat koos lähtekattuvusega, sest lüüsi enda WireGuard-paketid tekivad kohapeal ega kattu kunagi sissetuleva liidesega.

Valvur tuleb enne otsingut, mitte pärast seda. Just see järjekord ongi kogu lahenduse turvaomadus.

Valvur on teine reegel samal valijal, mille otsus on unreachable. Andke sellele kõrgem numbriline prioriteet, et otsing ikka võidaks, kuni tunnel on üleval. Kui tunneli marsruut kaob, ei tagasta otsing midagi ja valvur peatab otsingu, selle asemel et lasta sellel langeda põhitabeli WAN-i vaikemarsruudile.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Sulgege taganemislünk enne, kui selle avate

Paigaldage valvur esimesena ja otsing teisena. Vastupidi tehes jääb sekunditepikkune aken, mille jooksul testkliendi liiklus võib ühenduse üles jõuda.

Filter lõpetab pildi. Konksus forward aktsepteerige testprefiksi puhul suunda LAN-ist tunnelisse ja väljakujunenud tagasisuunda, seejärel jätke kõik muu kõrvale; selle prefiksi NAT tunneliliidesele käib kohta postrouting. Just policy drop edasisaatmise ahelasse jätmine muudab puuduva marsruudi lekkimise asemel vaikuseks. Pöördtee filtreerimine nõuab tunneliliidesel lõtva režiimi, sest dekapsuleeritult saabuv avalik lähe on oma parima pöördmarsruudiga WAN-i poolel. Linux võtab kõrgema kahest väärtusest: all ja liidesepõhine, seega tunneliliidese seadistamine ei ole sama, mis valideerimise nõrgendamine kõikjal.

Tõestage seda rikketsenaariumiga

Küsige tuumalt täpset küsimust, nimetades kliendi lähteaadressi ja liidese, mille kaudu see saabub. Otsing ilma mõlemata vastab teisele küsimusele ja näib mõlemal juhul õige. Seejärel vaadake tulemüüri loendureid, partneri ülekandeseisundit ja kliendi enda teenust.

Testige eemaldamist korralikult. Peatage tunnel, jättes reegli ja filtri paigale: klient peaks takerduma ja lüüsi enda liiklus peaks edasi töötama. Seejärel peatage partner ilma kohalikku liidest puutumata, ja see on juhtum, mis püüab kinni lahendused, mis loodavad ainult marsruudi olemasolule. Lõpuks taaskäivitage ja kontrollige reeglite järjekorda uuesti, sest valvuri eemaldav lammutamiskonks annab kogu lahenduse põhitabelile tagasi. Kirjutage tabeli number, prioriteedid ja liideste nimed muudatuse piletile, sest järgmine inimene, kes reegli lisab, on see, kes selle katki teeb.

Seotud artiklid