OpenWrt VPN-vyöhyke, edelleenvälitys ja maskaus: mitä tarvitset?

Kolme muutosta sekoittuvat aina, kun VPN kohtaa OpenWrt:n: portin avaaminen, edelleenvälityksen salliminen ja maskauksen kytkeminen päälle. Ne vastaavat eri kysymyksiin, ja yleensä vain yksi niistä on todellinen vaatimus. Jokaisen säätimen lukeminen sen liikenteen roolin mukaan, jota se ohjaa, muuttaa arvauksen päätökseksi ja kertoo myös, mitä oiretta odottaa, kun muutos on väärä. Aloita nimeämällä rooli, joka epäonnistui, älä valintaruutua, jonka muistat.

Nimeä liikenteen rooli ennen kuin kosket säätimeen

Vyöhykkeen tulo päättää, mitä voi päästä reitittimeen itseensä. Vyöhykkeen lähtö kattaa liikenteen, jonka reititin itse luo, vyöhykkeen edelleenvälitys on oletus vyöhykkeen läpi kulkevalle liikenteelle, ja maskaus päättää, kirjoitetaanko lähdeosoite uudelleen ulospäin mentäessä. Ne ovat neljä eri kysymystä, ja vyöhykekäytäntö vastaa niihin kaikkiin kerralla samalla arvolla, minkä vuoksi koko vyöhykkeen muutos on karkea työkalu. Nimetty sääntö voi vastata yhteen niistä koskematta muihin.

Hyödyllinen kartta on liikenteen roolin mukaan, koska juuri sitä voit havainnoida, kun jokin epäonnistuu. Jokaisella alla olevalla roolilla on yksi säädin, joka sen päättää, ja yksi oire, joka viittaa siihen:

Reitittimessä kuunteleva palvelu tarvitsee yhden kapean tulossäännön

Reitittimessä oleva OpenVPN-palvelin vastaanottaa reitittimelle osoitettua liikennettä, joten sen ulkoinen yhteys riippuu sen vyöhykkeen tulokäytännöstä, joka sitä kuljettaa. Salli määritetty kuljetus ja portti ja jätä kaikki muu siinä vyöhykkeessä hylätyksi. Yksi porttisääntö on paljon pienempi muutos kuin koko vyöhykkeen sallinta, ja se on se, jonka voit vielä vuoden päästä selittää.

Kaksi asiaa tekee säännöstä turvallisen pitää: se nimeää portin, jota palvelu todella käyttää, ja se seisoo vyöhykkeen määritelmän vieressä, jotta seuraava ihminen näkee, miksi se on olemassa. Alla olevat rivit ovat muoto, ja portti edustaa sitä, mitä palvelimelle on määritetty. Vaihda tämä portti molemmissa paikoissa, kun palvelu siirtyy, sillä vanhaan jäänyt sääntö on näkymätön tarkastukseen asti.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Validoi ennen uudelleenlatausta, sillä palomuuritiedoston syntaksivirhe voi jättää reitittimen ilman toimivaa sääntökokonaisuutta. fw4:ää käyttävässä versiossa tarkistus on erillinen komento, ja se epäonnistuu äänekkäästi sen sijaan, että hyväksyisi rikkinäisen lohkon hiljaa. Lataa uudelleen vasta tarkistuksen mentyä läpi ja pidä edellinen tiedosto siellä, mistä voit palauttaa sen.

fw4 check
service firewall reload

Asiakkaan pyyntö kulkee edelleenvälityksen kautta, ei tulon

Todennuksen jälkeen tunneliasiakkaan pyyntö LAN-palveluun tuottaa välitetyn virtauksen, joten sen päättävä säädin on tunnelivyöhykkeen ja LAN-vyöhykkeen välinen edelleenvälityssuhde. Kohdista tunneliliitäntä haluttuun vyöhykkeeseen ja ilmoita sitten suunta, lähteet ja palvelu. Vyöhykekohdistus on se, mikä antaa edelleenvälityssäännölle merkityksen, ja molemmat ovat mielekkäitä vain yhdessä luettuina. Edelleenvälityssuhde, joka nimeää tunnelivyöhykkeen lähteeksi ja LAN-vyöhykkeen kohteeksi, luetaan yhtenä tarkoituksellisena päätöksenä, kun taas kaksi koko vyöhykkeen sallintaa luetaan onnettomuutena.

Itse reitittimeen pääseminen käyttää yhä tulopolkua, minkä vuoksi ping yhdyskäytävään ei kerro mitään sen takana olevasta tiedostojen jakamisesta. Nämä kaksi epäonnistumista elävät eri lohkoissa ja korjataan eri muutoksilla. Kirjoita molemmat polut erikseen ennen kuin muutat kumpaakaan.

Maskaus on reitityspäätös, ei lupa

Maskaus kirjoittaa uudelleen valitun lähtevän liikenteen lähdeosoitteen. Se voi pelastaa lähtöratkaisun, jossa kaukopuolella ei ole paluureittiä, ja se myös piilottaa yksittäisten asiakkaiden osoitteet kaikilta palveluilta, jotka lokittavat tai valtuuttavat osoitteen perusteella. Sen pois kytkeminen on reititysvalinta paluureitistä, ei turvakytkin, joka sulkee tulevan reiän. Tunneli, joka toimii käännöksen ollessa päällä ja epäonnistuu heti kun se kytketään pois, kaipaa yleensä paluureittiä, ei palomuurisääntöä.

Reititetty vaihtoehto tarvitsee käännöksen sijaan paluureitin kaukopuolella. Kumpikaan vaihtoehto ei tarjoa palomuurilupaa tai sovellustiliä, minkä vuoksi maskauksen pois kytkeminen lähes koskaan korjaa tunneliasiakasta, joka ei pääse mihinkään. Käsittele myös IPv4- ja IPv6-käytäntöjä erikseen, sillä yksi käännösasetus ei kuvaa molempia perheitä.

Todista päätös sallitulla ja hylätyllä pyynnöllä

Lähetä yksi pyyntö, joka pitäisi sallia, ja yksi, joka pitäisi hylätä, ja tunnista sitten säädin, joka teki kunkin päätöksen. Sivu, joka sattumalta latautuu, ei ole todiste; todiste on sääntö, joka täsmäsi, siinä ketjussa, jossa se täsmäsi. Hylkäys merkitsee yhtä paljon kuin onnistuminen, koska se osoittaa käytännön tekevän jotain sen sijaan, että kaikki olisi sallittua.

Kaksi komentoa antavat tämän todisteen nykyisessä versiossa. Vastaavan säännön laskuri liikahtaa, kun pyyntö hyväksytään, ja loki näyttää pudotuksen, jos olet ottanut lokituksen käyttöön säännölle:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Pidä hallintapolku, jota voit vielä käyttää, ennen kuin muutat mitään palomuurikäytäntöä, ja noudata kokoonpanon omistajan validointi- ja palautusprosessia. Muutos, joka lukitsee sinut ulos reitittimestä, ei ole testitulos vaan toinen tapaus. Kirjaa vyöhyke ja liikenteen rooli jokaisen havainnon viereen, jotta tulospari selittää käytännön sen sijaan, että kuvailisi onnekasta sivun latautumista.