LANin NAT tun0:n läpi OpenBSD VPN-yhdyskäytävässä

Kaksi insinööriä saman OpenBSD-yhdyskäytävän kanssa antavat sinulle usein kaksi erilaista sääntöjoukkoa etäverkon saavuttamiseksi, ja molemmat ovat puolustettavissa. Valinta lähdeosoitteen käännöksen ja paluureitin välillä ei ole lainkaan syntaksikysymys. Kaikki riippuu siitä, mitä etäpuoli jo tietää osoitteesta 192.168.88.0/24 ja mitä sinun on pidettävä lokeissasi. Jos teet sen väärin, nat-to-rivi näyttää täysin oikealta, kun taas vastaukset katoavat etäpuolen oletusyhdyskäytävään.

Reititys ja uudelleenkirjoitus vastaavat eri kysymyksiin

Reititystaulu päättää, että 172.20.0.0/16 on tavoitettavissa tun0:n kautta, ja tämä päätös tehdään ennen kuin mitään pf-käännöstä kuullaan. Lähdeosoitteen käännös muuttaa sitten paketin otsaketta niin, että etäpää näkee yhdyskäytävän tunneliosoitteen LAN-isännän sijaan. Kumpikaan mekanismi ei korvaa toista: nat-sääntö ei voi loihtia reittiä tyhjästä, eikä reitti voi vakuuttaa etäreititintä, joka ei ole koskaan kuullut yksityisestä aliverkostasi. Kun etäpuolelta puuttuu paluupolku, vastaukset pudotetaan tai välitetään sen oletusyhdyskäytävälle, eikä mikään sääntöjen viritys korjaa sitä.

Selvästi sanottuna välitys vastaa siihen, minne liikenne menee, ja käännös siihen, keneltä sen näyttää tulevan. Pidä ne erillisissä ajatuslaatikoissa, kun suunnittelet sääntöjoukkoa.

Kolme ehtoa, jotka ratkaisevat

Esitä kolme kysymystä järjestyksessä, ja suunnittelu valitsee yleensä itse itsensä. Onko etäverkolla staattinen reitti, joka osoittaa tunneliosoitteeseen osoitteelle 192.168.88.0/24, vai hallitseeko sen ylläpitäjä kyseisen polun reitittimiä? Jos kyllä, anna LAN-osoitteiden kulkea muuttumattomina ja ohita käännös kokonaan. Tarvitsetko etäpuolella asiakaskohtaista näkyvyyttä, joko käyttöoikeuspolitiikkaa tai auditointijälkeä varten? Jos kyllä, lähteen säilyttäminen on reititystyön arvoista. Onko tunneliosoite tarpeeksi vakaa kirjoitettavaksi etäreitille, vai muuttuuko se uudelleenyhdistämisten välillä?

Jos mikä tahansa vastaus on ei tai tuntematon, nat-to on käytännöllinen vaihtoehto, ja se on myös peruttavissa. Käännössääntö poistuu yhdellä rivillä, kun etäpuoli lisää kunnollisen reitin. Paluureitti, jota ei koskaan asennettu, maksaa sinulle tukiketjun joka kerta, kun joku kysyy, miksi tunneli toimii vain yhteen suuntaan.

Sijoita fragmentti sinne, missä pf todella arvioi sen

Alla oleva fragmentti olettaa, että LAN on 192.168.88.0/24, etäverkko on 172.20.0.0/16 ja tunneliliittymä on tun0. Mikään siinä ei valitse seuraavaa hyppyä. Se vain kirjoittaa lähteen uudelleen paketteihin, jotka jo poistuvat tunnelin kautta.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Kaksi yksityiskohtaa tuolla ensimmäisellä rivillä kantaa suurimman osan painosta. Sulut tun0:n ympärillä kertovat pf:lle, että liittymän osoite luetaan joka kerta, kun se rakentaa tilamerkinnän, millä on merkitystä, kun tunneli numeroidaan uudelleen yhteyden palauttamisen jälkeen. Sana match tarkoittaa, että sääntö kirjoittaa uudelleen ja putoaa sitten läpi, joten erillisen pass-säännön on vielä hyväksyttävä virtaus. Match-rivillä nimetyn liittymän on myös oltava se, jonka reititystaulu valitsee, muuten pf arvioi säännön eri lähtöpolulla kuin minkä paketti todella ottaa.

Älä unohda ytimen puolta. IPv4-välitys on otettava käyttöön, ja tunnelin ja LANin tilalliset pass-säännöt on oltava olemassa ennen kuin millään tästä on merkitystä. OpenBSD FAQ:n PF NAT -osio on oikea viite avainsanojen järjestykselle tässä.

Vahvista sääntöjoukko ennen kuin luotat liikenteeseen

Tarkista ensin syntaksi komennolla pfctl -nf /etc/pf.conf, joka jäsentää tiedoston lataamatta sitä. Lataa sitten käytäntö ja lue takaisin, mitä ydin todella pitää, sillä puhtaasti jäsentynyt sääntö voi silti jäädä varjoon tai kiinnittyä väärään liittymään. pfctl -sn tulostaa käännössäännöt ladatussa muodossaan ja pfctl -sr tulostaa suodatinsäännöt arviointijärjestyksessä.

Tarkkaile seuraavaksi johtoa. Yhdyskäytävällä tcpdump -ni tun0 'host 172.20.0.10' näyttää, onko tunnelista poistuva lähdeosoite tunneliosoite vai LAN-isäntä. Nopea netstat -rn -f inet vahvistaa, mihin liittymään kohde ratkeaa. Kun liikenne virtaa, pfctl -ss luettelee tilamerkinnät; jos virtaus ei tuottanut tilaa, paketti ei koskaan osunut sääntöön, joka sellaisen luo.

Jos tunnelin puoli näyttää oikealta eivätkä vastaukset silti koskaan saavu, lopeta pf:n muokkaaminen. Jäljellä oleva vika on etäreitittimessä, jossa vastaus lähetetään yksityiseen osoitteeseen, johon tuo puoli ei pääse.

Kun käännös maksaa enemmän kuin säästää

Käännös piilottaa asiakkaat, ja joskus se on täsmälleen väärä vaihtokauppa. Päällekkäiset aliverkot ovat yksi tapaus: jos etäpuoli käyttää myös 192.168.88.0/24:ää sisäisesti, LAN-isäntien esittäminen yhdyskäytävänä pahentaa törmäystä sen sijaan, että parantaisi sitä. IPsec-käytännöt, jotka valitsevat liikennettä osoiteparin perusteella, ovat toinen, koska tietoturvakäytännön tietokanta sovitetaan ennen käännöstä eikä se koskaan näe uudelleenkirjoitettua pakettiasi. Jokainen käyttöönotto, joka laskuttaa, rajoittaa tai auditoi käyttäjäkohtaisesti, menettää myös tarvitsemansa identiteetin sinä hetkenä, kun lähde romahtaa yhdeksi osoitteeksi.

Siirrettävät pf-johdannaiset ovat erillinen ansa. Tuotteet, jotka tuottavat omat sääntötiedostonsa, odottavat NATin konfiguroitavan niiden liittymän kautta, ja käsin muokatut fragmentit ylikirjoitetaan seuraavalla uudelleenlatauksella. Ennen match-avainsanan olemassaoloa kirjoitetuista oppaista kopioidut sääntöjoukot eivät lataudu nykyiseen ytimeen, joten siirrä syntaksi ja lue virhe sen sijaan, että arvaisit.

Päätössääntö, joka kestää kosketuksen oikeisiin verkkoihin, on lyhyt: asenna paluureitti, kun voit, käännä, kun et voi, ja kirjoita muistiin, mikä kolmesta ehdosta sai sinut valitsemaan. Se muistiinpano säästää seuraavalta henkilöltä yhden iltapäivän.