Të arrish një /24 të largët përmes një tuneli: NETMAP, DNAT apo rrugë?
Mapo një prefiks të tërë me NETMAP, shto rregulla DNAT për çdo host ose ruto intervalin real, dhe vendos sipas asaj që ana e largët duhet të shohë dhe kush mund të nisë trafikun.
Mund të arrini një nënrrjet pas një pike fundore tuneli në tre mënyra, dhe një minutë mbledhje faktesh zakonisht përjashton dy. Faktet janë nëse serverët atje duhet t'i dallojnë përdoruesit, nëse dikush atje do të lidhet ndonjëherë drejt intervalit tuaj, dhe kush mund të modifikojë ruterin në anën e largët. Përgjigjuni këtyre tre dhe dizajni zgjedh vetveten. Pjesa tjetër supozon se ju drejtoni pikën fundore dhe mund të modifikoni firewall-in e saj.
Tre opsione dhe çfarë ndryshon në të vërtetë secili
Mapimi i prefiksit, DNAT për çdo host dhe një prefiks i rutuar të gjitha lëvizin paketat midis të njëjtave dy intervale, por ndryshojnë gjëra të ndryshme. Mapimi shpik një interval alias dhe rishkruan adresat në mënyrë aritmetike gjatë fluturimit. Rregullat për host gjithashtu rishkruajnë, vetëm se çdo destinacion emërtohet me dorë. Një prefiks i rutuar nuk rishkruan asgjë: paketat mbajnë adresat reale dhe të dy skajet bien dakord se ku jetojnë ato adresa.
| 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 |
Filloni eliminimin nga ana e largët, ku kufizimet janë më të vështira për t'u ndryshuar. Nëse një server atje shkruan adresat e klientëve në logje, i kontrollon kundrejt një liste të lejuar ose i dorëzon një sistemi tjetër, përkthimi i burimit shkatërron identifikuesin e tij të vetëm. Nëse ana e largët duhet gjithashtu të lidhet nga brenda, përkthimi përjashtohet plotësisht, sepse atje askush nuk e di se alias-i ekziston. Vetëm kur ana e largët thjesht u përgjigjet kërkesave, opsionet më të lira bëhen të sigurta.
Çiftet e prefikseve dhe pse madhësitë duhet të përputhen
NETMAP është një objektiv i tabelës nat që punon mbi një çift prefiksesh me gjatësi identike. Nuk ka tabelë për çdo adresë brenda: heq prefiksin, mban bitet e hostit dhe i ribashkon me prefiksin e ri, prandaj një /24 mapohet në një /24 dhe kurrë në një /25. Pozicioni vendos drejtimin: një përputhje destinacioni në PREROUTING rishkruan ku shkon paketa, dhe një përputhje burimi në POSTROUTING rishkruan nga ka ardhur.
Një host në 192.168.2.17 u shfaqet klientëve tuaj si 10.50.1.17, dhe okteti i fundit nuk është dekor — është i njëjti numër në të dyja anët. Shtoni nesër një host në 192.168.2.40 dhe alias-i i tij është 10.50.1.40, pa rregull për t'u modifikuar.
Klientët ende kanë nevojë për një rrugë për intervalin alias që tregon drejt kutisë tuaj, përveç nëse alias-i bie brenda një nënrrjeti që ata tashmë e arrijnë. Gateway nuk ka nevojë për rrugë për alias-in, sepse përkthimi i destinacionit ekzekutohet në PREROUTING, përpara kërkimit të rrugës. Edhe forwarding duhet të jetë i aktivizuar, përndryshe kerneli e hedh paketën pas rishkrimit. Tre komandat më poshtë janë e gjithë konfigurimi në një gateway në stil Debian me klientët në br0, alias-in në 10.50.1.0/24 dhe tunelin në 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 MASQUERADEPërgjigja duhet ta gjejë vetë rrugën e kthimit
Rishkrimi i destinacionit vendos vetëm ku paketa dorëzohet. Serveri i largët ende duhet t'i përgjigjet një adrese që e arrin, dhe kjo mund të rregullohet në dy mënyra. Përktheni burimin që përgjigjet të kthehen në kutinë tuaj, ose lini burimin dhe jepini anës së largët një rrugë për intervalin e klientëve.
Masquerade në dalje është rruga më e shkurtër: një rregull në POSTROUTING dhe ana e largët sheh adresën e tunelit tuaj, kështu që nuk i duhet një rrugë e vet. Kostoja është se çdo përdorues rrudhet në një adresë të vetme, dhe logjet për përdorues nuk nënkuptojnë më asgjë. Lënia e burimit të paprekur e ruan atë informacion, por atëherë faqja e largët duhet t'i kthejë përgjigjet për intervalin e klientëve përmes tunelit.OpenVPN serveri është një push "route 10.50.9.0 255.255.255.0", plus një route 192.168.2.0 255.255.255.0 rresht.
Dështimi i shtrenjtë është të bësh gjysmën e secilit. Nëse maskoni një pjesë të trafikut ndërsa ana e largët mban gjithashtu një rrugë kthimi për trafik tjetër, përgjigjet vijnë në një ndërfaqe ku zëri i gjurmimit të lidhjes nuk është parë kurrë. Klienti raporton një timeout për një kërkesë që serveri e regjistroi si të shërbyer. Të dy drejtimet e një rrjedhe duhet të kalojnë nëpër të njëjtin instancë netfilter: një gateway që përkthen, jo dy firewalls në seri.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLexoni zërin në të dy drejtimet: tuple origjinal mban alias-in tuaj në destinacion, ndërsa tuple i përgjigjes mban adresën reale. Nëse tuple i përgjigjes mungon, problemi është rruga e kthimit, jo rregulli. Nëse numëruesit e PREROUTING nuk lëvizën kurrë, paketa nuk arriti kurrë në atë hook.
Përplasjet dhe kërkimi që ekzekutohet i pari
Dy intervale të ndryshme mund të përplasen, dhe të dyja dështimet duken si një tunel i prishur dhe jo si një rregull i keq. Alias-i që shpikni duhet të jetë i papërdorur përgjatë gjithë rrugës, dhe intervali real i largët nuk duhet të ekzistojë tashmë në rrjetin tuaj. Një dublikatë prodhon trafik me ndërprerje drejt hostit të gabuar, më i vështirë për t'u diagnostikuar sesa një lidhje e refuzuar. Pyesni tabelën e rrugëzimit përpara se të shtoni një rregull.
Në gateway, ip route get 192.168.2.17 duhet të emërtojë pajisjen e tunelit; një bridge lokal do të thotë që intervali i largët është i hijezuar dhe asnjë rregull nat nuk e rregullon. Nëse rrjeti juaj tashmë përdor 192.168.2.0/24, rinumëroni faqen e largët në vend që të grumbulloni një mapim mbi përplasje.
Testimi nga një klient real, pastaj mbajtja
Testoni nga një makinë që do ta përdorë vërtet alias-in, jo nga gateway, sepse trafiku i gjeneruar lokalisht nuk e kalon kurrë PREROUTING në të njëjtën mënyrë. Hapni një lidhje drejt një hosti me alias dhe vëzhgoni numëruesit dhe zërin conntrack duke u shfaqur së bashku, pastaj mbylleni dhe konfirmoni që zëri largohet. Një zë i vjetëruar tregon një lidhje gjysmë të hapur, që zakonisht do të thotë se përgjigja nuk u kthye kurrë.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Dy ose tre lidhje të suksesshme vërtetojnë aritmetikën, por nuk thonë asgjë për qëndrueshmërinë ose për inxhinierin e radhës. Ruani rregullat atje ku procesi i boot-it i lexon, që në Debian dhe Ubuntu do të thotë iptables-save > /etc/iptables/rules.v4 me netfilter-persistent të aktivizuar. Një mapim që zhduket në rindezje është më keq se asnjë, sepse ndërprerja vjen pa një ndryshim të fundit për t'u fajësuar.
Lini një shënim pranë rregullave: intervali alias, intervali real, arsyeja e çiftit dhe cila anë mund të fillojë. Ai shënim ndan një dizajn nga një grumbull rregullash që askush nuk guxon t'i fshijë. Ai zgjidh edhe pyetjen e mëvonshme, kur faqja e largët shton një host dhe një adresë që askush nuk e konfiguroi tashmë përgjigjet. Nëse shënimi thotë se ana e largët ka nevojë për një rrugë kthimi, personi tjetër e di se heqja e rregullit masquerade prish lidhshmërinë. Dokumentacioni është i lirë këtu; rizbulimi i një varësie nga NAT në orën tre të mëngjesit nuk është.