Kaugse /24-le tunnelist ligipääs: NETMAP, DNAT või marsruut?
Kaardistage terve prefiks NETMAP-iga, lisage DNAT-reeglid iga hosti kohta või marsruutige tegelik vahemik, ja otsustage selle järgi, mida kaugpool peab nägema ja kes tohib liiklust algatada.
Tunneli lõpp-punkti taga olevasse alamvõrku pääseb kolmel viisil ja minut faktide kogumist välistab tavaliselt kaks. Faktid on: kas seal olevad serverid peavad kasutajaid eristama, kas keegi seal kunagi helistab teie vahemikku, ja kes tohib kaugotsa ruuterit muuta. Vastake neile kolmele ja disain valib end ise. Ülejäänu eeldab, et haldate lõpp-punkti ja tohib selle tulemüüri muuta.
Kolm valikut ja mida igaüks tegelikult muudab
Prefiksi kaardistamine, hostipõhine DNAT ja marsruuditud prefiks liigutavad kõik pakette samade kahe vahemiku vahel, kuid muudavad erinevaid asju. Kaardistamine leiutab alias-vahemiku ja kirjutab aadressid lennu ajal aritmeetiliselt ümber. Hostipõhised reeglid kirjutavad samuti ümber, ainult iga sihtkoht nimetatakse käsitsi. Marsruuditud prefiks ei kirjuta midagi ümber: paketid säilitavad tegelikud aadressid ja mõlemad otsad nõustuvad, kus need aadressid elavad.
| 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 |
Alustage välistamist kaugpoolt, kus piiranguid on kõige raskem muuta. Kui sealne server kirjutab kliendi aadressid logidesse, kontrollib neid lubatud loendi vastu või annab need teisele süsteemile, hävitab allika tõlkimine selle ainsa identifikaatori. Kui kaugpool peab ka ise helistama, langeb tõlkimine täielikult välja, sest seal ei tea keegi, et alias eksisteerib. Alles siis, kui kaugpool ainult vastab päringutele, muutuvad odavamad valikud turvaliseks.
Prefiksipaarid ja miks suurused peavad klappima
NETMAP on nat-tabeli sihtmärk, mis töötab võrdse pikkusega prefiksite paari peal. Selle sees pole aadressipõhist tabelit: see eemaldab prefiksi, jätab hosti bitid alles ja kinnitab need uue prefiksi külge, mistõttu /24 kaardistub /24-le ja mitte kunagi /25-le. Asukoht määrab suuna: sihtkoha vaste PREROUTING-is kirjutab ümber, kuhu pakett läheb, ja allika vaste POSTROUTING-is kirjutab ümber, kust see tuli.
Host aadressil 192.168.2.17 paistab teie klientidele kui 10.50.1.17 ja viimane oktett pole dekoratiivne — see on mõlemal pool sama arv. Lisage homme host aadressil 192.168.2.40 ja selle alias on 10.50.1.40, ilma ühegi reegli muutmise vajaduseta.
Klientidel on endiselt vaja alias-vahemiku marsruuti, mis osutab teie masinale, kui alias ei jää alamvõrku, mida nad juba saavutavad. Lüüsil pole alias-vahemiku jaoks marsruuti vaja, sest sihtkoha tõlkimine toimub PREROUTING-is, enne marsruudi otsimist. Edastamine peab samuti sees olema, muidu viskab tuum paketi pärast ümberkirjutamist ära. Kolm allolevat käsku on kogu seadistus Debiani-stiilis lüüsil, kus kliendid on br0-l, alias 10.50.1.0/24-l ja tunnel tun0-l.
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 MASQUERADEVastus peab ise tagasitee leidma
Sihtkoha ümberkirjutamine otsustab ainult selle, kuhu pakett toimetatakse. Kaugpoolne server peab ikkagi vastama aadressile, mida ta saab kätte, ja selle korraldamiseks on kaks viisi. Tõlkige allikas, et vastused tuleksid teie masinasse tagasi, või jätke allikas puutumata ja andke kaugpoolele kliendivahemiku marsruut.
Maskeerimine väljamineval teel on lühem tee: üks reegel POSTROUTING-is ja kaugpool näeb teie tunneli aadressi, nii et tal pole oma marsruuti vaja. Hind on see, et kõik kasutajad sulavad ühte aadressi ja kasutajapõhised logid kaotavad tähenduse. Allika puutumata jätmine hoiab selle teabe alles, kuid siis peab kaugkoht saatma kliendivahemiku vastused tunneli kaudu tagasi. Ühel OpenVPN serveril on see saadetud push "route 10.50.9.0 255.255.255.0", pluss rida route 192.168.2.0 255.255.255.0.
Kallis viga on teha mõlemast pool. Kui maskeerite osa liiklusest, samal ajal kui kaugpool kannab ka teise liikluse jaoks tagasimarsruuti, saabuvad vastused liidesele, kus ühenduse jälgimise kirjet polnud kunagi nähtud. Klient teatab ajutõrkest päringu puhul, mille server logis teenindatuna. Voog mõlemad suunad peavad läbima sama netfilteri eksemplari: üks lüüs, mis tõlgib, mitte kaks tulemüüri järjestikku.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLugege kirjet mõlemas suunas: algne korteež hoiab alias teie sihtkohas, vastuse korteež kannab tegelikku aadressi. Kui vastuse korteež puudub, on probleem tagasiteel, mitte reeglis. Kui PREROUTING-i loendurid ei liikunud kunagi, ei jõudnud pakett kunagi selle konksuni.
Kokkupõrked ja otsing, mis käivitub esimesena
Kaks erinevat vahemikku võivad kokku põrgata ja mõlemad tõrked näevad välja nagu katkine tunnel, mitte nagu halb reegel. Alias, mille leiutate, peab olema kogu teel kasutamata ja kaugpoolne tegelik vahemik ei tohi teie võrgus juba olemas olla. Duplikaat tekitab aeg-ajalt liiklust vale hosti poole, mida on raskem diagnoosida kui keeldutud ühendust. Küsige marsruutimistabelilt enne, kui reegli lisate.
Lüüsil peaks ip route get 192.168.2.17 nimetama tunneli seadet; kohalik sild tähendab, et kaugvahemik on varjatud ja ükski nat-reegel seda ei paranda. Kui teie võrk kasutab juba 192.168.2.0/24, nummerdage kaugkoht ümber, selle asemel et laduda kokkupõrke peale kaardistust.
Testige päris kliendilt ja hoidke alles
Testige masinalt, mis alias tegelikult kasutab, mitte lüüsilt, sest kohapeal loodud liiklus ei läbi PREROUTING-i kunagi samamoodi. Avage ühendus ühe aliastega hosti poole ja jälgige, kuidas loendurid ja conntracki kirje koos ilmuvad, seejärel sulgege see ja kinnitage, et kirje kaob. Vananenud kirje osutab poollahtisele ühendusele, mis tavaliselt tähendab, et vastus ei tulnudki tagasi.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Kaks või kolm edukat ühendust tõestavad aritmeetikat, kuid ei ütle midagi püsivuse ega järgmise inseneri kohta. Salvestage reeglid sinna, kust alglaadimise protsess neid loeb, mis Debianis ja Ubuntus tähendab iptables-save > /etc/iptables/rules.v4 koos lubatud netfilter-persistentiga. Kaardistus, mis taaskäivitusel kaob, on hullem kui mitte ükski, sest katkestus tuleb ilma hiljutise muudatuseta, mida süüdistada.
Jätke reeglite kõrvale märkus: alias-vahemik, tegelik vahemik, paari põhjus ja kummalt poolt tohib algatada. See märkus eraldab disaini hunnikust reeglitest, mida keegi ei julge kustutada. See lahendab ka hilisema küsimuse, kui kaugkoht lisab hosti ja aadress, mida keegi ei seadistanud, vastab juba. Kui märkus ütleb, et kaugpool vajab tagasimarsruuti, teab järgmine inimene, et maskeerimisreegli eemaldamine katkestab ühenduvuse. Dokumentatsioon on siin odav; NAT-sõltuvuse uuesti avastamine kell kolm öösel ei ole.