OpenBSD VPN шлюзінде tun0 арқылы LAN-ды NAT-тау

OpenBSD tun0 шығысынан шығатын LAN трафигі үшін бастапқы NAT немесе қайтару маршрутын таңдап, сосын nat-to ережесін pf әлі өткізетін жерге қойыңыз.

Бір 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 кілт сөзі пайда болмай тұрып жазылған нұсқаулықтардан көшірілген ереже жинақтары ағымдағы ядрода жүктелмейді, сондықтан синтаксисті көшіріп, болжаудың орнына қатені оқыңыз.

Нақты желілермен жанасудан аман қалатын шешім ережесі қысқа: мүмкін болса, қайтару маршрутын орнатыңыз, мүмкін болмаса, трансляция жасаңыз және үш шарттың қайсысы сізді сол таңдауға итермелегенін жазып қойыңыз. Сол жазба келесі адамның жарты күнін үнемдейді.

Қатысты мақалалар