Туннель аркылуу алыскы /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кa хост кошуңуз, анын алиасы 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 көз карандылыгын кайра ачуу арзан эмес.