tun0 жоқ па? nftables ішіндегі шифры ашылған IPsec-ті meta ipsec арқылы сәйкестендіріңіз

Саясатқа негізделген шлюз әлі де eth0 арқылы келетін ашық ішкі пакеттерді жібереді. Жоқ интерфейсті емес, қауіпсіздік жолы мен қызметті сәйкестендіріңіз.

Сіз туннель интерфейсін күтесіз, оны іздейсіз, бірақ брандмауэрде сәйкестендіретін ештеңе жоқ. Бұл саясатқа негізделген шлюз үшін қалыпты жағдай: шифрланған алмасу физикалық интерфейске келеді, ал одан кейін жіберілетін шифры ашылған ішкі пакет те сол интерфейске келетін ретінде байқалады. tun0 жоқ, өйткені оны ештеңе жасамаған.

Ішкі сұраныс әлі де өз көзі, межелі жері және қызметі бар жеке пакет, ал ядро оның қай қауіпсіздік қауымдастығынан шыққанын біледі. Дәл осы білімді брандмауэр ережесі сәйкестендіре алады.

Екі пакет, бір интерфейс

Кіретін бағытты елестетіңіз. ESP немесе UDP-ге қапталған пакет келеді, ядро сәйкес саясатты табады, оны шифрдан шығарады және ашық пакетті жіберу жолына береді. Тек интерфейс атауына қарайтын ереже бұл пакетті сол сыммен келетін кез келген басқа трафиктен ажырата алмайды.

Оны ерекшелендіретін нәрсе — пакетке тіркелген кіретін қауіпсіздік жолының контексті. nftables оны meta ipsec exists ретінде көрсетеді, бұл пакет IPsec қауіпсіздік жолымен келгенде ақиқат. Оны клиенттер пулымен, межелі жермен және қызметпен біріктіріңіз, ереже қауіпсіз болуға жеткілікті нақты болады.

Контексті қалдырып кету жиі кездесетін қате, және бұл сән емес, қауіпсіздік қатесі. Клиенттер пулынан келгеннің бәрін қабылдайтын ереже жергілікті желіден келген жалған пакетті де дәл сондай қуанышпен қабылдайды, өйткені бастапқы мекенжай өздігінен ештеңенің дәлелі емес. Бастапқы мекенжайды мағыналы етудің ең арзан жолы — қауіпсіздік жолының контексті. Ережені аудиттен кейін қосудың орнына басынан бастап сол контекстпен жазыңыз.

Жіберу ережесін жазыңыз

10.90.0.0/24 ішінде клиенттері бар аутентификацияланған IPv4 қашықтан қатынау қызметі және 203.0.113.40 мекенжайындағы бір мақұлданған межелі жер бар делік. Сол ағын үшін ереже үзіндісі осылай көрінеді.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Мекенжайлар мен интерфейс ауыстырылатын мысалдар. Тексерілген баламаны жіберу саясатына ағынды әйтпесе қабылдамайтын ережеден бұрын қойыңыз, және оны орнату үшін қолданыстағы ережелер жиынтығын тазаламаңыз; шлюз таза бөлме эксперименті емес.

oifname терминін сақтаған жөн. Ол шығу шешімін құжаттайды және ереженің сіз ойламаған бағытта сәйкесуіне жол бермейді, бұл интернетке бірнеше жолы бар шлюзде маңызды. Бір жоғары арнасы бар сынақ жәшігінде термин артық көрінеді, сондықтан жәшік екінші арнаны алғанға дейін ол алынып тасталады.

Сыртқы алмасуға рұқсаттар бөлек. Шлюздің кіру жолына ол іс жүзінде пайдаланатын IKE және ESP немесе UDP-қаптама порттары қажет, және бұл рұқсаттар іштегі шифры ашылған пакет туралы ештеңеге рұқсат бермейді. Екеуін араластыру — жұмыс істеп тұрған туннельдің бәрін жіберетін брандмауэрге тап болу жолы.

Кіретін контекст шығатын контекст емес

Сол өрнектер тұқымдасы қарама-қарсы бағытты rt ipsec арқылы қамтиды, ол пакет пайдаланатын шығатын қауіпсіздік қауымдастығын сипаттайды. Ол басқа сұраққа жауап береді: бұл пакет қайдан келгені емес, келесі бөлігінде ол қорғала ма.

Бұл айырмашылық бір туннельді аяқтап, екіншісіне жіберетін шлюзде маңызды. Пакет шифры ашылып келіп, бәрібір шифрланып кетуі мүмкін, ал тек кіретін контекст үшін жазылған рұқсат шығатын талап туралы ештеңе айтпайды. Егер саясат сол қорғауды талап етсе, ережелер жиынтығы оны білдіруі керек, маршруттау шешеді деп болжаудың орнына.

Екі сұрақты жеке ережелерде ұстаңыз, оқырман қайсысы орындалып жатқанын көрсін. Екеуін де тексеретін бір ақылды ережені қарап шығу қиынырақ, ал оның жартысы сәйкесуді тоқтатқанда жөндеу әлдеқайда қиын. Есептегіштері бар екі ереже қай талап орындалмай жатқанын да айтады, ал біріктірілген бір ереже мұны ешқашан істемейді.

NAT брандмауэр шешімі емес

Жеке клиенттер пулынан интернетке баратын трафик әдетте жауап қайту жолын табуы үшін бастапқы мекенжайды түрлендіруді қажет етеді. Бірақ басқа шығатын IPsec саясаты үшін таңдалған трафик өзінің қажетті жеңілдігін сақтауы керек, ал келесі қорғау шешімі туралы ойланбастан әрбір жеке бастапқы мекенжайды жасыру мұны бұзады.

NAT тізбегінің ішіндегі рұқсат та жалпы рұқсат емес. NAT пен сүзгілеудің жұмыстары бөлек, және NAT тізбегі орныққан ағынның әрбір кейінгі пакетін тексере бермейді, сондықтан қауіпсіздік үшін оған сүйену сынақта жұмыс істейтін, ал жүктеме астында құлайтын ережелер тудырады.

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

Нақты ішкі қызметті тексеріңіз

Сіз рұқсат берген нақты межелі жер мен портты нақты клиенттен сынап, жауаптың қайтатынын растаңыз. Содан кейін рұқсат бермеген нәрсені сынап, оның өтпейтінін тексеріңіз, өйткені тым кең ереже бірінші сынақтан дұрыс ережедей-ақ өтеді. Клиенттен ешқашан шықпайтын сұраныс та брандмауэр нәтижесі емес, сондықтан пакеттің мүлдем бағаланғанын білу үшін есептегіштерді оқыңыз. Екі сынақ пен бір есептегіш көрсеткіші сізге ережелер жиынтығын оқуға кеткен тұтас түстен кейінгі уақыттан көбірек айтады.

nftables анықтамасы meta ipsec, rt ipsec және бағытқа тән өрнектерді құжаттайды, және синтаксисті орнатылған нұсқаңызбен салыстырып тексеретін жер — дәл сол жер. Ауқымды ашық ұстаңыз: бұл IPv4 мысалы, ол IPv6 туралы ештеңе айтпайды және кездейсоқ ашық порттарды жіберуді VPN қызметінің бөлігіне айналдырмайды.

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