OpenBSD VPN шлюзинде tun0 аркылуу LANды NAT кылуу

Бир эле OpenBSD шлюзи бар эки инженер алыскы тармакка жетүү үчүн көбүнчө эки башка эрежелер топтомун сунушташат, экөөнү тең коргоого болот. Баштапкы трансляция менен кайтаруу маршрутунун ортосундагы тандоо такыр синтаксистик маселе эмес. Баары каршы тарап 192.168.88.0/24 тууралуу эмнени билерине жана журналдарыңызда эмнени сакташыңыз керектигине байланыштуу. Бул жерде ката кетирсеңиз, nat-to сабы таптакыр туура көрүнөт, ал эми жооптор алыскы демейки шлюзге жоголот.

Маршруттоо жана кайра жазуу ар башка суроолорго жооп берет

Маршруттоо таблицасы 172.20.0.0/16га tun0 аркылуу жетүүгө болорун чечет, жана бул чечим кандайдыр бир pf трансляциясына кайрылганга чейин кабыл алынат. Андан кийин баштапкы трансляция пакеттин аталышын өзгөртөт, ошондуктан алыскы тарап LAN хостунун ордуна шлюздун туннель дарегин көрөт. Эки механизмдин бири экинчисин алмаштырбайт: nat эрежеси маршрут жарата албайт, ал эми маршрут сиздин жеке ички тармагыңыз тууралуу эч качан укпаган алыскы маршрутизаторду ишендире албайт. Каршы тарапта кайтаруу жолу болбосо, жооптор ыргытылат же анын демейки шлюзине жөнөтүлөт, жана эрежелерди канча жөндөсөңүз да бул оңдолбойт.

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

Чечүүчү үч шарт

Үч суроону ирети менен бериңиз, долбоор көбүнчө өзү тандалат. Алыскы тармакта 192.168.88.0/24 үчүн туннель дарегин көрсөткөн статикалык маршрут барбы, же анын администратору ошол жолдогу маршрутизаторлорду көзөмөлдөйбү? Эгер ооба болсо, LAN даректерин өзгөртпөй өткөрүңүз жана трансляцияны толугу менен өткөрүп жибериңиз. Каршы тарапта ар бир кардарды көрүү керекпи, кирүү саясаты үчүн да, аудит изи үчүн да? Эгер керек болсо, баштапкыны сактоо маршруттоо ишине татыктуу. Туннель дареги алыскы маршрутка жазууга жетиштүү туруктуубу, же кайра туташуулардын ортосунда өзгөрөбү?

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

Үзүндүнү pf чындап баалай тургандай жайгаштыруу

Төмөнкү үзүндү LAN 192.168.88.0/24, алыскы тармак 172.20.0.0/16, ал эми туннель интерфейси tun0 деп эсептейт. Анда кийинки секирүүнү тандаган эч нерсе жок. Ал туннелден чыгып бара жаткан пакеттердеги баштапкы даректи гана кайра жазат.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Ошол биринчи саптагы эки детал эң көп салмакты көтөрөт. tun0 айланасындагы кашаалар pf ге ар бир абал жазуусун курууда интерфейс дарегин окууну айтат, бул кайра туташкандан кийин туннель кайра номурланганда маанилүү. match сөзү эреженин кайра жазып, анан ылдый түшөрүн билдирет, ошондуктан өзүнчө pass эрежеси агымды дагы деле уруксат бериши керек. match сабында аталган интерфейс да маршруттоо таблицасы тандаган интерфейс менен бирдей болушу керек, болбосо pf эрежени пакет чындап өткөн жолдон башка чыгуучу жолдо баалайт.

Ядро тарабын унутпаңыз. IPv4 өткөрүп берүү күйгүзүлүшү керек, ал эми туннель жана LAN үчүн абалдуу pass эрежелери мунун баарынын мааниси болушунан мурун болушу керек. Бул жердеги ачкыч сөздөрдүн ирети үчүн OpenBSD FAQдеги PF NAT бөлүмү туура шилтеме.

Трафикке ишенүүдөн мурун эрежелер топтомун текшериңиз

Алгач синтаксисти pfctl -nf /etc/pf.conf менен текшериңиз, ал файлды жүктөбөстөн талдайт. Андан кийин саясатты жүктөп, ядро чындап эмнени кармап турганын кайра окуңуз, анткени таза талданган эреже көлөкөдө калышы же туура эмес интерфейске тиркелиши мүмкүн. pfctl -sn трансляция эрежелерин жүктөлгөн түрүндө басып чыгарат, ал эми pfctl -sr чыпкалоо эрежелерин баалоо ирети менен басып чыгарат.

Андан кийин зымды байкаңыз. Шлюзде tcpdump -ni tun0 'host 172.20.0.10' туннелден чыккан баштапкы дарек туннелдин дарегиби же LAN хостдубу экенин көрсөтөт. Тез netstat -rn -f inet барар жери кайсы интерфейске чечилерин тастыктайт. Трафик ага баштаганда pfctl -ss абал жазууларын тизмелейт; эгер агым абал жаратпаса, пакет аны жараткан эрежеге эч качан туш болгон эмес.

Эгер туннель тарабы туура көрүнүп, жооптор келе бербесе, pf ти өңдөөнү токтотуңуз. Калган бузулуу алыскы маршрутизатордо, ал жерде жооп ошол тарап жете албаган жеке дарекке карай жөнөтүлүп жатат.

Трансляция үнөмдөгөндөн кымбат турганда

Трансляция кардарларды жашырат, кээде бул так эле туура эмес бүтүм. Кабатташкан ички тармактар бир учур: эгер каршы тарап ички түрдө 192.168.88.0/24 ты да колдонсо, LAN хостторду шлюз катары көрсөтүү кагылышты жакшыртуунун ордуна начарлатат. Трафикти дарек жуптары боюнча тандаган IPsec саясаттары экинчи учур, анткени коопсуздук саясатынын маалымат базасы трансляцияга чейин салыштырылат жана сиздин кайра жазылган пакетиңизди эч качан көрбөйт. Колдонуучу боюнча эсептеген, чектеген же аудит жасаган ар кандай жайылтуу да баштапкы бир дарекке чогулган учурда керектүү инсандыгын жоготот.

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

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