Potinklį už tunelio galinio taško galite pasiekti trimis būdais, o minutė faktų rinkimo paprastai atmeta du. Faktai: ar serveriai ten turi atskirti vartotojus, ar kas nors ten kada nors bandys jungtis į jūsų diapazoną, ir kas gali redaguoti tolimąjį maršrutizatorių. Atsakykite į šiuos tris, ir dizainas išsirinks pats. Likusi dalis laiko, kad jūs valdote galinį tašką ir galite redaguoti jo ugniasienę.

Trys variantai ir ką kiekvienas iš tikrųjų keičia

Prefikso susiejimas, DNAT kiekvienam hostui ir maršrutizuotas prefiksas visi perkelia paketus tarp tų pačių dviejų diapazonų, bet keičia skirtingus dalykus. Susiejimas išranda alias diapazoną ir skrydžio metu aritmetiškai perrašo adresus. Taisyklės kiekvienam hostui taip pat perrašo, tik kiekvienas tikslas nurodomas ranka. Maršrutizuotas prefiksas nieko neperrašo: paketai išlaiko tikruosius adresus, o abu galai sutaria, kur tie adresai gyvena.

What the far side needsPrefix mappingPer-host DNATRouted prefix
Users visible to its logsOnly without source NATSame conditionYes, unchanged
To start a connection toward youNo, alias is localNo, same reasonYes, both ends route
To absorb a new hostYes, arithmetic onlyNo, one rule per addressYes, it simply routes
To require no config changeYes, with source NATYes, same conditionNo, it needs a route back

Pradėkite atmetimą nuo tolimosios pusės, kur apribojimus sunkiausia pakeisti. Jei ten esantis serveris rašo klientų adresus į žurnalus, tikrina juos pagal leidžiamų sąrašą arba perduoda kitai sistemai, šaltinio vertimas sunaikina vienintelį jo identifikatorių. Jei tolimoji pusė taip pat turi jungtis vidun, vertimas visiškai netinka, nes ten niekas nežino, kad alias egzistuoja. Tik kai tolimoji pusė tik atsako į užklausas, pigesnės parinktys tampa saugios.

Prefiksų poros ir kodėl dydžiai turi sutapti

NETMAP yra nat lentelės taikinys, veikiantis su vienodo ilgio prefiksų pora. Viduje jis neturi lentelės kiekvienam adresui: nuima prefiksą, išlaiko hosto bitus ir vėl prijungia juos prie naujo prefikso, todėl /24 susiejamas su /24 ir niekada su /25. Padėtis lemia kryptį: tikslo atitikimas PREROUTING perrašo, kur paketas eina, o šaltinio atitikimas POSTROUTING perrašo, iš kur jis atėjo.

Hostas 192.168.2.17 jūsų klientams atrodo kaip 10.50.1.17, o paskutinis oktetas nėra puošmena — tai tas pats skaičius abiejose pusėse. Rytoj pridėkite hostą 192.168.2.40, ir jo alias bus 10.50.1.40, be jokios taisyklės, kurią reikėtų redaguoti.

Klientams vis tiek reikia maršruto alias diapazonui, nukreipto į jūsų įrenginį, nebent alias patenka į potinklį, kurį jie jau pasiekia. Šliuzui nereikia maršruto alias, nes tikslo vertimas vykdomas PREROUTING, prieš maršruto paiešką. Persiuntimas taip pat turi būti įjungtas, kitaip branduolys numes paketą po perrašymo. Trys komandos žemiau yra visa konfigūracija Debian stiliaus šliuze, kai klientai yra br0, alias yra 10.50.1.0/24, o tunelis yra tun0.

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 MASQUERADE

Atsakymas turi pats rasti kelią atgal

Tikslo perrašymas tik nusprendžia, kur paketas bus pristatytas. Tolimasis serveris vis tiek turi atsakyti adresu, kurį pasiekia, ir tai galima sutvarkyti dviem būdais. Versti šaltinį, kad atsakymai grįžtų į jūsų įrenginį, arba palikti šaltinį ir duoti tolimajai pusei maršrutą klientų diapazonui.

Masquerade išėjimo kryptimi yra trumpesnis kelias: viena taisyklė POSTROUTING, ir tolimoji pusė mato jūsų tunelio adresą, todėl jai nereikia savo maršruto. Kaina ta, kad kiekvienas vartotojas sueina į vieną adresą, o žurnalai pagal vartotoją nustoja ką nors reikšti. Palikus šaltinį nepažeistą, ta informacija išlieka, bet tada tolimoji svetainė turi siųsti atsakymus klientų diapazonui atgal per tunelį.OpenVPN serveryje tai yra push siunčiama push "route 10.50.9.0 255.255.255.0", plius route 192.168.2.0 255.255.255.0 eilutė.

Brangus nepakankamumas yra daryti po pusę kiekvieno. Jei maskuojate dalį srauto, o tolimoji pusė taip pat turi grįžimo maršrutą kitam srautui, atsakymai atvyksta į sąsają, kurioje ryšio sekimo įrašas niekada nebuvo matytas. Klientas praneša apie laiko limitą užklausai, kurią serveris užregistravo kaip įvykdytą. Abi srauto kryptys turi kirsti tą pačią netfilter instanciją: vienas šliuzas verčia, o ne dvi ugniasienės nuosekliai.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Skaitykite įrašą abiem kryptimis: pirminė tuple išlaiko jūsų alias tiksle, o atsakymo tuple neša tikrąjį adresą. Jei atsakymo tuple nėra, problema yra grįžimo kelias, o ne taisyklė. Jei PREROUTING skaitikliai niekada nejudėjo, paketas niekada nepasiekė to hook.

Susidūrimai ir paieška, kuri vykdoma pirmoji

Du skirtingi diapazonai gali susidurti, ir abu gedimai atrodo kaip sugedęs tunelis, o ne bloga taisyklė. Jūsų išrastas alias turi būti nenaudojamas visame kelyje, o tikrasis tolimasis diapazonas neturi jau egzistuoti jūsų tinkle. Dublikatas sukelia protarpinį srautą ne tam hostui, kurį diagnozuoti sunkiau nei atmestą ryšį. Prieš pridėdami taisyklę, paklauskite maršrutų lentelės.

Šliuze, ip route get 192.168.2.17 turėtų nurodyti tunelio įrenginį; vietinis bridge reiškia, kad tolimasis diapazonas yra užtemdytas ir jokia nat taisyklė jo nepataisys. Jei jūsų tinklas jau naudoja 192.168.2.0/24, pernumeruokite tolimąją svetainę, o ne kraukite susiejimą ant susidūrimo.

Išbandyti iš tikro kliento, o paskui išsaugoti

Bandykite iš mašinos, kuri iš tikrųjų naudos alias, o ne iš šliuzo, nes vietoje sugeneruotas srautas niekada nekerta PREROUTING taip pat. Atidarykite ryšį į vieną hostą su alias ir stebėkite, kaip kartu atsiranda skaitikliai ir conntrack įrašas, tada uždarykite ir patvirtinkite, kad įrašas išnyksta. Pasenęs įrašas rodo pusiau atvirą ryšį, o tai paprastai reiškia, kad atsakymas niekada negrįžo.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Du ar trys sėkmingi ryšiai įrodo aritmetiką, bet nieko nesako apie patvarumą ar kitą inžinierių. Išsaugokite taisykles ten, kur jas skaito paleidimo procesas, o Debian ir Ubuntu tai reiškia iptables-save > /etc/iptables/rules.v4 su įjungtu netfilter-persistent. Susiejimas, kuris dingsta perkrovus, yra blogiau nei joks, nes sutrikimas ateina be jokio neseno pakeitimo, kurį būtų galima kaltinti.

Palikite pastabą prie taisyklių: alias diapazonas, tikrasis diapazonas, poros priežastis ir kuri pusė gali inicijuoti. Ta pastaba atskiria dizainą nuo taisyklių krūvos, kurios niekas nedrįsta ištrinti. Ji taip pat išsprendžia vėlesnį klausimą, kai tolimoji svetainė prideda hostą ir adresas, kurio niekas nesukonfigūravo, jau atsako. Jei pastaba sako, kad tolimajai pusei reikia grįžimo maršruto, kitas žmogus žino, kad masquerade taisyklės pašalinimas nutraukia ryšį. Dokumentacija čia pigi; iš naujo atrasti NAT priklausomybę trečią valandą nakties — ne.

Susiję straipsniai