Etäiseen /24-verkkoon tunnelin kautta: NETMAP, DNAT vai reitti?
Kartoita koko etuliite NETMAPilla, lisää DNAT-säännöt isäntäkohtaisesti tai reititä todellinen alue, ja päätä sen mukaan, mitä kaukopään on nähtävä ja kuka saa aloittaa liikenteen.
Tunnelin päätepisteen takana olevaan aliverkkoon pääsee kolmella tavalla, ja minuutti faktojen keräämistä sulkee yleensä kaksi pois. Faktat ovat: täytyykö siellä olevien palvelimien erottaa käyttäjät toisistaan, soittaako joku siellä koskaan alueellesi, ja kuka saa muokata kaukopään reititintä. Vastaa näihin kolmeen, niin suunnittelu valitsee itse itsensä. Loput olettaa, että sinä hallitset päätepistettä ja saat muokata sen palomuuria.
Kolme vaihtoehtoa ja mitä kukin oikeastaan muuttaa
Etuliitekartoitus, isäntäkohtainen DNAT ja reititetty etuliite siirtävät kaikki paketteja samojen kahden alueen välillä, mutta muuttavat eri asioita. Kartoitus keksii aliaksen alueen ja kirjoittaa osoitteet uudelleen aritmeettisesti lennossa. Isäntäkohtaiset säännöt kirjoittavat myös uudelleen, paitsi että jokainen kohde nimetään käsin. Reititetty etuliite ei kirjoita mitään uudelleen: paketit säilyttävät todelliset osoitteet ja molemmat päät sopivat, missä ne osoitteet asuvat.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Aloita karsinta kaukopäästä, jossa rajoituksia on vaikein muuttaa. Jos palvelin siellä kirjoittaa asiakkaiden osoitteet lokeihin, tarkistaa ne sallittujen luettelosta tai luovuttaa ne toiselle järjestelmälle, lähteen kääntäminen tuhoaa sen ainoan tunnisteen. Jos kaukopään on myös soitettava, käännös jää kokonaan pois, koska siellä kukaan ei tiedä aliaksen olevan olemassa. Vasta kun kaukopää vain vastaa pyyntöihin, halvemmat vaihtoehdot ovat turvallisia.
Etuliiteparit ja miksi kokojen on oltava samat
NETMAP on nat-taulun kohde, joka toimii samanpituisten etuliitteiden parilla. Sen sisällä ei ole osoitekohtaista taulua: se poistaa etuliitteen, säilyttää isäntäbitit ja liittää ne uuteen etuliitteeseen, siksi /24 kuvautuu /24:lle eikä koskaan /25:lle. Sijainti ratkaisee suunnan: kohteen osuma PREROUTINGissa kirjoittaa uudelleen, minne paketti on menossa, ja lähteen osuma POSTROUTINGissa, mistä se tuli.
Isäntä osoitteessa 192.168.2.17 näkyy asiakkaille osoitteena 10.50.1.17, eikä viimeinen oktetti ole koriste — se on sama luku molemmilla puolilla. Lisää huomenna isäntä osoitteeseen 192.168.2.40, niin sen alias on 10.50.1.40, ilman muokattavaa sääntöä.
Asiakkaat tarvitsevat yhä reitin aliaksen alueelle, joka osoittaa koneeseesi, ellei alias ole aliverkossa, johon he jo pääsevät. Yhdyskäytävä ei tarvitse reittiä aliakselle, koska kohdekäännös ajetaan PREROUTINGissa ennen reittihakua. Myös edelleenlähetys on oltava päällä, muuten ydin pudottaa paketin uudelleenkirjoituksen jälkeen. Alla olevat kolme komentoa ovat koko asennus Debian-tyylisellä yhdyskäytävällä, kun asiakkaat ovat br0:ssa, alias 10.50.1.0/24:ssä ja tunneli tun0:ssa.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEVastauksen on löydettävä itse tiensä takaisin
Kohteen uudelleenkirjoitus ratkaisee vain, minne paketti toimitetaan. Kaukopään palvelimen on silti vastattava osoitteeseen, jonka se tavoittaa, ja sen voi järjestää kahdella tavalla. Käännä lähde, jotta vastaukset palaavat koneeseesi, tai jätä lähde rauhaan ja anna kaukopäälle reitti asiakasalueelle.
Maskeeraus lähtevällä reitillä on lyhyempi polku: yksi sääntö POSTROUTINGissa ja kaukopää näkee tunnelisi osoitteen, joten se ei tarvitse omaa reittiä. Hinta on, että kaikki käyttäjät sulautuvat yhteen osoitteeseen ja käyttäjäkohtaiset lokit menettävät merkityksensä. Lähteen jättäminen ennalleen säilyttää tiedon, mutta silloin kaukosivun on lähetettävä asiakasalueen vastaukset takaisin tunnelin kautta. OpenVPN palvelimella se on työnnetty push "route 10.50.9.0 255.255.255.0", sekä rivi route 192.168.2.0 255.255.255.0.
Kallis virhe on tehdä puolet kummastakin. Jos maskeeraat osan liikenteestä, kun kaukopää kantaa myös paluureittiä muulle liikenteelle, vastaukset saapuvat rajapinnalle, jolla yhteyden seurannan merkintää ei koskaan nähty. Asiakas ilmoittaa aikakatkaisusta pyynnölle, jonka palvelin kirjasi palvelluksi. Virran molempien suuntien on kuljettava saman netfilter-instanssin läpi: yksi yhdyskäytävä kääntää, ei kaksi palomuuria sarjassa.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLue merkintä molempiin suuntiin: alkuperäinen monikko säilyttää aliaksesi kohteessa, kun taas vastausmonikko kantaa todellisen osoitteen. Jos vastausmonikko puuttuu, ongelma on paluureitillä eikä säännössä. Jos PREROUTING-laskurit eivät koskaan liikkuneet, paketti ei koskaan saapunut sille koukulle.
Törmäykset ja haku, joka ajetaan ensin
Kaksi eri aluetta voi törmätä ja molemmat viat näyttävät rikkinäiseltä tunnelilta eivätkä huonolta säännöltä. Keksimäsi aliaksen on oltava käyttämätön koko polulla, eikä kaukopään todellinen alue saa olla jo verkossasi. Kaksoiskappale tuottaa ajoittaista liikennettä väärälle isännälle, mitä on vaikeampi diagnosoida kuin hylättyä yhteyttä. Kysy reititystaulua ennen kuin lisäät säännön.
Yhdyskäytävässä ip route get 192.168.2.17 pitäisi nimetä tunnelilaite; paikallinen silta tarkoittaa, että kaukopään alue on varjostettu eikä mikään nat-sääntö korjaa sitä. Jos oma verkkosi käyttää jo 192.168.2.0/24:ää, numeroi kaukosivu uudelleen sen sijaan että pinoaisit kartoituksen törmäyksen päälle.
Testaus oikealta asiakkaalta ja sitten säilytys
Testaa koneelta, joka todella käyttää aliasmia, älä yhdyskäytävältä, koska paikallisesti luotu liikenne ei koskaan kulje PREROUTINGin läpi samalla tavalla. Avaa yhteys aliakselliseen isäntään ja seuraa, miten laskurit ja conntrack-merkintä ilmestyvät yhdessä, sulje se sitten ja varmista, että merkintä poistuu. Vanhentunut merkintä viittaa puoliavoimeen yhteyteen, mikä yleensä tarkoittaa, ettei vastaus koskaan tullut takaisin.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Kaksi tai kolme onnistunutta yhteyttä todistavat aritmetiikan, mutta eivät kerro mitään pysyvyydestä tai seuraavasta insinööristä. Tallenna säännöt sinne, mistä käynnistysprosessi ne lukee, mikä Debianissa ja Ubuntussa tarkoittaa iptables-save > /etc/iptables/rules.v4 ja päällä olevaa netfilter-persistenttiä. Uudelleenkäynnistyksessä katoava kartoitus on pahempi kuin ei mitään, koska katkos tulee ilman äskettäistä muutosta, jota syyttää.
Jätä sääntöjen viereen muistiinpano: aliaksen alue, todellinen alue, parin syy ja kumpi puoli saa aloittaa. Se muistiinpano erottaa suunnittelun kasasta sääntöjä, joita kukaan ei uskalla poistaa. Se ratkaisee myös myöhemmän kysymyksen, kun kaukosivu lisää isännän ja osoite, jota kukaan ei konfiguroinut, vastaa jo. Jos muistiinpano sanoo, että kaukopää tarvitsee paluureitin, seuraava tietää, että maskeeraussäännön poistaminen katkaisee yhteyden. Dokumentointi on täällä halpaa; NAT-riippuvuuden uudelleen löytäminen kolmelta aamuyöllä ei ole.