Жеке LAN-дардын ортосунда дагы бир NAT коштон мурун маршруттаңыз

Эки ички файрвол, бир жеке транзит сегменти жана ар бир LANдагы бир нече хосттун экинчиси менен сүйлөшүүсүнө уруксат берүү өтүнүчү. Адаттагы реакция — VPN көтөрүү же экинчи NAT катмарын кошуу, ал эми эки реакция тең маселенин баасынан кымбат. Жөнөкөй маршруттоо үч шарт аткарылганда жетиштүү: дарек диапазондору кайчылашпайт, эки тарап тең трафикти экинчи LANга кайтара алат жана транзит сегменти маалымат үчүн жетиштүү ишенимдүү. Бир нерсени долбоорлоодон мурун ушул үчөөнү текшериңиз, анткени ар бири жоопту өзгөртөт.

Долбоорду аныктаган үч шарт

Биринчи шарт — дарек мейкиндиги. Эгер эки LAN тең бирдей RFC 1918 блогун колдонсо, маршруттоо аларды ажырата албайт жана которуу милдеттүү болуп калат, тандоолуу эмес. Экинчиси — кайтуу жолу: Aдан Bге маршрут B да Aнын LANына кантип жетүүнү билбесе, пайдасыз, ал эми асимметриялык билим маршрутталган долбоордун жоопторду үнсүз ташташынын эң көп тараган себеби.

Үчүнчүсү — ишеним. Маршруттоо пакеттерди жылдырат; ал аларды коргобойт. Бир имараттын ичиндеги жеке транзит сегменти провайдерге өткөрүп берүүдөн же жалпы кампус магистралын кесип өткөн байланыштан башка нерсе. Эгер сегмент ишенимдүү болбосо, жооп — эки файрволдун ортосундагы туннел, ал эми төмөнкү маршруттоо планы анын ичинде да колдонулат.

Жөнөкөй долбоор үчөө тең бир багытты көрсөткөндө гана жеңет. Алардын бири ишке ашпаса, ошол шартты которуу менен жашырбай, ачык түзөтүңүз, анткени NAT кемчиликти жашырат, чечпейт.

Маршрут планын транзит тармагында куруңуз

Ар бир файрволго жалпы сегментте дарек бериңиз жана ар бир алыскы LAN үчүн бир конкреттүү маршрут кошуңуз. Учурдагы конфигурацияда башка эч нерсени жылдыруунун кереги жок, айрыкча интернеттин демейки маршруту так өз ордунда калышы керек. Демейки маршрутту кошуна файрвол менен алмаштыруу ар бир байланышсыз даректи транзит аркылуу жөнөтмөк, бул суралган өзгөрүүдөн алда канча чоң өзгөрүү. pfSenseдин статикалык маршруттоо документи ошол платформа үчүн ушундай эле маршрут-плюс-шлюз моделинин сүрөттөйт, ал эми барабар жөндөө сиз чындап колдонгон каалаган файрволдо бар.

A файрволу 10.30.0.0/24 тармагына кызмат кылат, B файрволу 10.40.0.0/24кө, эки транзит дареги 192.0.2.0/24тө. Ар бир LAN хост өзүнүн жергиликтүү файрволун шлюз катары кармайт, ошондуктан жаңы абал ар бир тарапта бирден маршрут. Linux негизиндеги файрволдо ошол эле план мындай көрүнөт, ал эми кайра багыттоо күйгүзүлүшү керек, болбосо маршрут чечилет, пакет ташталат.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Фильтрлөөнү которуудан бөлүп кармаңыз

Маршруттоо жана саясат — башка башкаруулар, ал эми көпчүлүк маршрутталган долбоорлор так экинчисинде ишке ашпайт. Пакеттер чындап кесип өткөн кирүү чегинде конкреттүү булактарга, даректерге жана кызматтарга уруксат бериңиз жана WAN сыяктуу интерфейс белгиси ат экенин, ишеним тууралуу билдирүү эмес экенин унутпаңыз. Жеке трафикти ташыган транзит портунда жеке даректерди блоктоо демейки боюнча күйүк болушу мүмкүн.

Андан кийин NAT болбойт деп жыйынтык чыгарбастан мурун чыгуучу которууга караңыз. Автоматтык чыгуучу эрежелер которууга эч качан арналбаган трафикти кайра жаза алат, бул экинчи тарапка өз саясаты жана журналдары үчүн керек болгон булак даректерин жок кылат. Тандалган агымдардын баштапкы даректерин сакташын ырастаңыз жана дагы деле керек трафик үчүн интернетти которуу эрежелерине тийбеңиз.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

NAT чынчыл жооп болгондо

Которуу дарек диапазондору чындап кайчылашканда жана кайра номерлөө мүмкүн болбогондо, же саясат бир тараптын ички тармактын ордуна бир даректи көрүшүн талап кылганда өз ордун алат. Мындай учурларда атайын бири-бирине же порт менен чектелген картага түшүрүү — кесепеттери белгилүү долбоордук чечим, айланып өтүү жолу эмес.

Үн чыгарып айтууга тийиш кесепет — экинчи тарап эми өзүнчө булактарды көрө да, фильтрлей да албайт. Журналдар которуучу дарекке топтолот, хост боюнча саясат иштөөнү токтотот, ал эми мүчүлүштүктөрдү жоюу белгилүү учурда кайсы ички хост агымды ээлеп турганын издөөгө айланат. Эгер мунун эч бири каралып жаткан трафик үчүн маанилүү болбосо, NAT туура.

Транзиттин өзү туура эмес божомол болгондо

Эгер жалпы сегмент провайдерден, жалпы коммутациялык кездемеден же башка тарап трафикти окуй алган каалаган жолдон өтсө, жалгыз маршруттоо толук жооп эмес. Эки файрволдун ортосундагы туннел сизге купуялуулукту жана өнөктөштүн аутентификациясын берет, ал эми анын ичиндеги маршрут таблицасы транзитте жазган таблицаңыздын так өзү.

Муну биринчи бөлүмдөгү ишеним суроосунан чечиңиз, VPN коопсузураак деген адаттан эмес. Мурунтан жеке сегмент үстүндөгү туннел пайдасыз операциялык чыгымды жана дагы бир бузулуу режимин кошот, ал эми ишенимсиз сегмент үстүндөгү маршруттоо купуялуулукту өзүңүз көтөрө албаган жөнөкөйлүккө алмаштырат. Үч шарттын кайсынысы тандоону башкарганын жазып коюңуз, кийинки инженер аны кайра талкуулабайт.