iptables ережеңіз көпір арқылы өтетін VPN трафигін неге ешқашан көрмейді

Бір хосттағы екі виртуалды машина LAN-ға көпір арқылы жетеді, ал ip forward тізбегіне қойылған ереже ешқашан қозғалмайтын санауышты көрсетеді. Кадрлар шынайы, трафик өтіп жатыр, бірақ ереже жай ғана оның жолында емес. Linux көпір трафигін көрсетудің екі әдісін салыстыру осы үнсіздікті түсіндіреді және бір ескі модульді жүктеу көрінгеннен де нашар жауап екенін де түсіндіреді.

Бір хост арқылы екі жол

Пакет бұл хосттан екі мүлдем басқа жолмен шыға алады, және айырмашылық оны қай ілмектер көретінін анықтайды. Егер меже физикалық порттың арғы жағында болса және кадр көпірдің екі порты арасында ауыстырылса, хост Ethernet кадрын жібереді; маршруттау коды сұралмайды және маршрутталған секіріс болмайды. Егер меже хосттың өзі болса немесе туннель интерфейсі арқылы қол жеткізілетін желі болса, пакет маршрутталады және IP қабатының ілмектері шынымен қолданылады. Осы тармақты есте сақтаңыз, өйткені тізбектер мен топтар туралы кейінгі әрбір сұрақ кадрдың осы екі жолдың қайсысын таңдауынан туындайды.

Бұл айырмашылық ештеңе санамайтын ереженің артындағы бүкіл әңгіме. veth9a1-ден enp3s0-ге дейінгі көпірленген кадр IP стекті емес, көпірді кесіп өтеді, сондықтан ip forward тізбегі салыстырар ештеңе көрмейді. Ескі мысалдағы интерфейс атаулары сізде қай жол бар екенін анықтамайды, сондықтан бірінші қадам ережелер жиынтығына емес, топологияға қарау.

Туннель атауға тұрарлық үшінші жағдайды қосады. TUN құрылғысы IP пакеттерін хостқа береді, сондықтан олар маршрутталады және IP тізбектерінен шынымен өтеді, ал көпірге қосылған TAP құрылғысы кадрларды береді және көпір жағдайы сияқты әрекет етеді. Құрылғы түрі шешеді, өнім атауы емес.

Көпірленген кадрды көре алатын екі топты салыстырыңыз

Linux nftables-тің bridge тобы арқылы жергілікті көпір сүзгісін қолдайды және ұшу кезінде кадрларды тексеріп тастау үшін оған ескі модуль қажет емес. Ядроның өз көпір құжаттамасы бұл ұсынысты тікелей береді, оны іздеу нәтижесі модуль жүктеуді айтпас бұрын білген жөн.

iptables орнына nft командасын қолдану ережені дұрыс топқа өздігінен қоймайды. bridge тобында жарияланған тізбек кадрларды көреді; ip, ip6 немесе inet-те жарияланған тізбек оларды көрмейді, оны қай бинарлық жасағанына қарамастан. Топ — тізбектің қасиеті, оны терген құралдың емес.

Ескі жол басқаша жұмыс істейді, сондықтан әдетпен жақ таңдаудың орнына салыстырған жөн. br_netfilter жүктеп, bridge-nf-call параметрлерін қосу көпірленген IPv4 және IPv6 трафигін IP қабатының ілмектері арқылы қайта ашады, сондықтан қарапайым iptables ережесі онымен ақыры сәйкесе алады. Кадрлар өзгермейді; олар өтетін ілмектер жиынтығы өзгереді, бұл хосттың әрбір қолданыстағы ережесінің енді жаңа аудиториясы бар екенін білдіреді.

Ереже қоспас бұрын нақты жолды оқыңыз

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

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

Шығыс жағдайларды таза ажыратады. Көпір астында тізілген порттар қай интерфейстер ауыстырылып жатқанын айтады; бос lsmod нәтижесі көпірленген кадрлардың IP қабатында ешқандай көрінуі жоқ екенін білдіреді; bridge тобының бар forward тізбегі саясат иесі бұрыннан бар екенін және ережеңіздің өзінің жаңа тізбегіне емес, сол жерге жататынын білдіреді.

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

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Ескі модуль мінез-құлықты қайда өзгертеді

Жұмыс істеп тұрған көпірде ескі жолды қосу — көріну қосу деген бейтарап әрекет емес. Көпір трафигі үшін бұрын қолжетімсіз болған ережелер қолжетімді болады, соның ішінде басқа интерфейс үшін жазылған хост ережелері, және ip forward тізбегіндегі әдепкі drop саясаты бұрын тиіспестен өтетін кадрларға кенеттен қолданылуы мүмкін. Сол көпір арқылы басқарылатын хостта нәтиже консолсыз құлыпталу болады. Бұл гипотетикалық ақау режимі емес; бұл жаңа ғана кеңейткен жолмен жететін машинада ілмектер жиынтығын кеңейтудің қарапайым салдары.

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

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

Соңында, хосттың кіріс жағдайын бөлек ұстаңыз. Көпірдің өз IP-іне бағытталған трафик input-қа келеді, forward-қа емес, және forward-тағы ереже оны қай топты таңдасаңыз да ешқашан көрмейді. Үш жағдай, екі топ, бір сабақ: жол ілмекті анықтайды, ал ілмек ережеңіздің мүлдем бар-жоғын анықтайды.