Туннель арқылы қашықтағы /24 желісіне жету: NETMAP, DNAT әлде маршрут?
Бүкіл префиксті NETMAP-пен картаға түсіріңіз, әр хостқа DNAT ережелерін қосыңыз немесе нақты диапазонды маршруттаңыз — және алыс жақ нені көруі керектігіне және трафикті кім бастай алатынына қарай шешіңіз.
Туннель соңғы нүктесінің артындағы қосалқы желіге үш жолмен жетуге болады, ал фактілерді жинаудың бір минуты әдетте екеуін жоққа шығарады. Фактілер: ондағы серверлер пайдаланушыларды ажыратуы керек пе, ондағы біреу сіздің диапазоныңызға қосылуға әрекет ете ме, және алыс жақтағы маршрутизаторды кім өңдей алады. Осы үшеуіне жауап берсеңіз, дизайн өзі таңдалады. Қалғаны сіз соңғы нүктені басқарасыз және оның брандмауэрын өңдей аласыз деп болжайды.
Үш нұсқа және олардың әрқайсысы шын мәнінде нені өзгертеді
Префиксті картаға түсіру, әр хостқа DNAT және маршрутталған префикс пакеттерді бірдей екі диапазон арасында жылжытады, бірақ әртүрлі нәрселерді өзгертеді. Картаға түсіру алиас диапазонын ойлап тауып, жолда мекенжайларды арифметикалық түрде қайта жазады. Хост ережелері де қайта жазады, тек әр тағайындалу қолмен аталады. Маршрутталған префикс ештеңені қайта жазбайды: пакеттер нақты мекенжайларды сақтайды және екі жақ бұл мекенжайлардың қайда тұратыны туралы келіседі.
| 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 |
Жоққа шығаруды алыс жақтан бастаңыз, өйткені шектеулерді өзгерту ең қиын сонда. Егер ондағы сервер клиент мекенжайларын журналдарға жазатын болса, оларды рұқсат етілген тізіммен салыстырса немесе басқа жүйеге берсе, көзді аудару оның жалғыз идентификаторын жояды. Егер алыс жақ өзі де қосылуы керек болса, аудару мүлдем жарамсыз, өйткені онда алиастың бар екенін ешкім білмейді. Алыс жақ тек сұрауларға жауап беретін болса ғана арзан нұсқалар қауіпсіз болады.
Префикс жұптары және өлшемдер неге сәйкес болуы керек
NETMAP — бірдей ұзындықтағы префикстер жұбында жұмыс істейтін nat кестесінің мақсаты. Оның ішінде әр мекенжайға арналған кесте жоқ: ол префиксті алып тастайды, хост биттерін сақтайды және оларды жаңа префикске қайта бекітеді, сондықтан /24 /24-ке салынады және ешқашан /25-ке салынбайды. Орны бағытты анықтайды: PREROUTING-тегі тағайындалу сәйкестігі пакеттің қайда баратынын қайта жазады, ал POSTROUTING-тегі көз сәйкестігі оның қайдан келгенін қайта жазады.
192.168.2.17-дегі хост сіздің клиенттеріңізге 10.50.1.17 болып көрінеді, ал соңғы октет әшекей емес — ол екі жақта бірдей сан. Ертең 192.168.2.40-қа хост қосыңыз, оның алиасы 10.50.1.40 болады, өңдейтін ереже жоқ.
Клиенттерге алиас диапазоны үшін сіздің құрылғыңызға бағытталған маршрут әлі де қажет, тек алиас олар жететін қосалқы желінің ішінде болса ғана қажет емес. Шлюзге алиас үшін маршрут қажет емес, өйткені тағайындалуды аудару PREROUTING-те, маршрутты іздеуден бұрын орындалады. Forwarding де қосулы болуы керек, әйтпесе ядро қайта жазғаннан кейін пакетті тастайды. Төмендегі үш команда — клиенттері br0-да, алиасы 10.50.1.0/24-те және туннелі tun0-да орналасқан Debian стиліндегі шлюздегі бүкіл конфигурация.
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Жауап өзіне қайтар жолды табуы керек
Тағайындалуды қайта жазу пакеттің қайда жеткізілетінін ғана шешеді. Алыс жақтағы сервер өзі жете алатын мекенжайға жауап беруі керек, және мұны ұйымдастырудың екі жолы бар. Жауаптар сіздің құрылғыңызға қайтуы үшін көзді аударыңыз, немесе көзді қалдырып, алыс жаққа клиент диапазоны үшін маршрут беріңіз.
Сыртқа шығатын masquerade — қысқарақ жол: POSTROUTING-те бір ереже және алыс жақ сіздің туннель мекенжайыңызды көреді, сондықтан өзіне маршрут қажет етпейді. Бағасы — әр пайдаланушы бір мекенжайға сығылады, ал пайдаланушы бойынша журналдар мағынасын жоғалтады. Көзді бүтін қалдыру бұл ақпаратты сақтайды, бірақ ол кезде алыс сайт клиент диапазонының жауаптарын туннель арқылы қайтаруы керек.OpenVPN серверінде бұл push арқылы жіберілетін push "route 10.50.9.0 255.255.255.0", сонымен қатар route 192.168.2.0 255.255.255.0 жолы.
Қымбат сәтсіздік — әрқайсысының жартысын жасау. Егер трафиктің бір бөлігін masquerade-лесеңіз, ал алыс жақ басқа трафик үшін қайтару маршрутын да алып жүрсе, жауаптар қосылымды бақылау жазбасы ешқашан көрінбеген интерфейске келеді. Клиент сервер орындалды деп жазған сұрауға timeout деп хабарлайды. Ағынның екі бағыты да бір netfilter инстанциясынан өтуі керек: бір шлюз аударады, тізбектегі екі брандмауэр емес.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nЖазбаны екі бағытта оқыңыз: бастапқы tuple тағайындалуда алиасыңызды сақтайды, ал жауап tuple нақты мекенжайды алып жүреді. Егер жауап tuple жоқ болса, мәселе ережеде емес, қайтару жолында. Егер PREROUTING есептегіштері ешқашан қозғалмаса, пакет бұл hook-қа ешқашан жетпеген.
Қақтығыстар және бірінші орындалатын іздеу
Екі түрлі диапазон қақтығысуы мүмкін, және екі сәтсіздік те жаман ереже емес, сынған туннель болып көрінеді. Сіз ойлап тапқан алиас бүкіл жолда пайдаланылмауы керек, ал нақты алыс диапазон сіздің желіңізде бұрыннан болмауы керек. Қайталану ара-мұнда қате хостқа трафик тудырады, оны қабылданбаған қосылымнан диагностикалау қиынырақ. Ереже қоспас бұрын маршрут кестесінен сұраңыз.
Шлюзде, ip route get 192.168.2.17 туннель құрылғысын атауы керек; жергілікті bridge алыс диапазонның көлеңкеленгенін білдіреді және оны ешбір nat ережесі түзетпейді. Егер сіздің желіңіз 192.168.2.0/24-ді бұрыннан пайдаланса, қақтығысқа картаны қабаттастырудың орнына алыс сайтты қайта нөмірлеңіз.
Нақты клиенттен тексеру, содан кейін сақтау
Алиасты шынымен пайдаланатын машинадан тексеріңіз, шлюзден емес, өйткені жергілікті жасалған трафик PREROUTING-тен ешқашан дәл солай өтпейді. Алиасы бар бір хостқа қосылым ашып, есептегіштер мен conntrack жазбасының бірге пайда болуын бақылаңыз, содан кейін жауып, жазбаның кетуін растаңыз. Ескірген жазба жартылай ашық қосылымды көрсетеді, бұл әдетте жауаптың қайта оралмағанын білдіреді.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Екі-үш сәтті қосылым арифметиканы дәлелдейді, бірақ тұрақтылық немесе келесі инженер туралы ештеңе айтпайды. Ережелерді жүктеу процесі оқитын жерге сақтаңыз, бұл Debian мен Ubuntu-да iptables-save > /etc/iptables/rules.v4 netfilter-persistent қосулы күйде дегенді білдіреді. Қайта жүктеу кезінде жоғалатын карта жоқтан жаман, өйткені үзіліс кінәлайтын жақында өзгеріссіз келеді.
Ережелердің қасында жазба қалдырыңыз: алиас диапазоны, нақты диапазон, жұптың себебі және қай жақ бастай алады. Бұл жазба дизайнды ешкім жоюға батылы бармайтын ережелер үйіндісінен ажыратады. Ол кейінгі сұрақты да шешеді: қашықтағы сайт хост қосқанда, ешкім конфигурацияламаған мекенжай жауап бере бастайды. Егер жазбада алыс жаққа қайтару маршруты қажет деп жазылса, келесі адам masquerade ережесін алып тастау қосылымды үзетінін біледі. Мұнда құжаттама арзан; түнгі үште NAT тәуелділігін қайта ашу арзан емес.