Näin yhdelle testilähiverkolle annetaan oma WireGuard-uloskäynti

Kolme suunnittelua ratkaisee saman laboratorio-ongelman: pienen lähiverkon on poistuttava WireGuard-vertaiskumppanin kautta, kun yhdyskäytävä itse pitää tavallisen ylävirtayhteytensä. Houkutteleva oikotie on siirtää reitittimen oletusreitti tunnelin sisään, mutta se rikkoo laatikon oman hallintapolun ja kaiken muun, mitä se välittää. Kiinnostava vaihtoehto on käytäntöperusteinen reititys, joka rajataan yhteen liitäntään ja yhteen etuliitteeseen. Valitse niiden välillä vastaamalla kolmeen kysymykseen koneesta, joka sinulla todella on.

Päätä, missä uloskäynti asuu

Ensimmäinen kysymys: välittääkö tämä isäntä myös jotain muuta? Omistettu laboratorioyhdyskäytävä voi elää välityskäytännöllä, joka hylkää oletuksena. Tuotantotehtävien reititin ei voi, ja kilpailevan sääntöjoukon kerrostaminen hallitun palomuurin päälle on juuri se tapa, jolla katkokset ajoitetaan. Toinen: voitko omistaa kaksi käytäntöobjektia ja niiden järjestyksen uudelleenkäynnistysten yli? Kolmas: valtuuttaako vertaiskumppanisi tunnelin lähdeosoitteesi ja tarjoaako se internetyhteyden? Vertaiskumppani, joka paljastaa vain yksityisen verkon, on eri tuote, eikä mikään paikallinen reititysmuutos korjaa sitä. Jos jokin vastaus on ei, laita uloskäynti sen sijaan nimiavaruuteen tai kertakäyttöiseen virtuaalikoneeseen.

Nimiavaruus tai VM maksaa muistia ja antaa sinulle puhtaan räjähdysalueen. Käytäntöperusteinen reititys maksaa kaksi sääntöä ja jättää sinulle yhden laatikon viritettäväksi.

Valitse uloskäynti, joka valtuuttaa lähteesi

Useimmat tämän laboratorion viat tapahtuvat ennen kuin ainuttakaan palomuurisääntöä on olemassa. Uloskäynnin operaattorin on hyväksyttävä lähdeosoite, jota pakettisi kantavat käännöksen jälkeen, ja tässä suunnitelmassa se on tunnelin osoite eikä lähiverkon etuliite. Siksi peittäminen kuuluu suunnitelmaan alusta asti eikä myöhäisenä lisäyksenä.

Vahvista operaattorin kanssa kolme asiaa: vertaiskumppani valtuuttaa tunnelin osoitteesi, se välittää IPv4:n sen sijaan että päättäisi itseensä, ja se soveltaa lähtevää NAT:ia. Ilman ensimmäistä pakettisi saapuvat ja katoavat. Ilman kolmatta ne lähtevät yksityisellä lähteellä ja kuolevat seuraavalla hypyllä. Tarkista sitten, ettei wg-quick asenna omaa oletusreittiään, minkä Table = off estää; se asetus vaimentaa reittien luomisen, ei vertaiskumppanin AllowedIPs-tarkistuksia tai sen DNS-käsittelyä.

Kaksi käytäntöobjektia hoitavat ohjauksen

Ohjaus tarvitsee taulukon ja säännön. Taulukossa on kaksi reittiä: lähiverkon etuliite ulos lähiverkon liitännästä ja oletusreitti ulos tunnelista. Sääntö lähettää liikenteen, joka saapuu lähiverkon liitäntään ja kantaa tätä etuliitettä, taulukkoon. Käytä iif-valitsinta lähdeosumisen rinnalla, koska yhdyskäytävän omat WireGuard-paketit syntyvät paikallisesti eivätkä koskaan osu saapuvaan liitäntään.

Vartija tulee ennen hakua, ei sen jälkeen. Juuri tämä järjestys on koko suunnitelman turvaominaisuus.

Vartija on toinen sääntö samalla valitsimella, ja sen tuomio on unreachable. Anna sille korkeampi numeerinen prioriteetti, jotta haku voittaa yhä tunnelin ollessa pystyssä. Kun tunnelin reitti katoaa, haku ei palauta mitään ja vartija pysäyttää haun sen sijaan, että päästäisi sen putoamaan päätaulukon WAN-oletukseen.

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

Sulje varautumisaukko ennen kuin avaat sen

Asenna vartija ensin ja haku vasta sitten. Toisin päin tehtynä jäljelle jää sekuntien ikkuna, jossa testiasiakkaan liikenne voi päästä ylävirtayhteydelle.

Suodatin viimeistelee kuvan. forward-koukussa hyväksy lähiverkosta tunneliin -suunta testietuliitteelle ja vakiintunut paluusuunta ja hylkää sitten kaikki muu; kyseisen etuliitteen NAT tunnelin liitäntään menee kohtaan postrouting. Juuri policy drop:n jättäminen välitysketjuun muuttaa puuttuvan reitin vuodoksi tulemisen sijaan hiljaisuudeksi. Käänteisen polun suodatus tarvitsee löysän tilan tunnelin liitännässä, koska julkisella lähteellä, joka saapuu purettuna, on paras käänteisreittinsä WAN-puolella. Linux ottaa korkeamman arvoista all ja liitäntäkohtainen, joten tunnelin liitännän asettaminen ei ole sama kuin validoinnin heikentäminen kaikkialla.

Todista se vikatapauksella

Kysy ytimeltä täsmällinen kysymys nimeämällä asiakkaan lähdeosoite ja liitäntä, josta se saapuu. Haku ilman molempia vastaa toiseen kysymykseen ja näyttää oikealta kummassakin tapauksessa. Katso sitten palomuurin laskureita, vertaiskumppanin siirtotilaa ja asiakkaan omaa palvelua.

Testaa poisto kunnolla. Pysäytä tunneli jättäen sääntö ja suodatin paikoilleen: asiakkaan pitäisi pysähtyä ja yhdyskäytävän oman liikenteen jatkaa toimintaansa. Pysäytä sitten vertaiskumppani koskematta paikalliseen liitäntään, ja juuri se tapaus nappaa suunnitelmat, jotka luottavat pelkkään reitin olemassaoloon. Käynnistä lopuksi uudelleen ja tarkista sääntöjärjestys uudestaan, koska vartijan poistava purkukoukku antaa koko suunnitelman takaisin päätaulukolle. Kirjaa taulukon numero, prioriteetit ja liitäntöjen nimet muutospyyntöön, koska seuraava sääntöä lisäävä henkilö on se, joka tämän rikkoo.