SNAT, DNAT және Masquerade: VPN-тегі әрбір NAT ережесі не істейді

VPN шлюзінің екі жағына түсірілім қойыңыз, бір ағын төрт түрлі мекенжайды көрсетуі мүмкін. Бастау NAT пакет қайдан келеді деп мәлімдегенін қайта жазады; межелік NAT оның қайда баратынын қайта жазады. Masquerade — үшінші бағыт емес, мекенжайды тіркелген мәннің орнына шығыс интерфейстен алатын бастау NAT ережесі. Үшеуінің қайсысы шынымен қажет екенін атаңыз, сонда «VPN бұзылды» билеттерінің көбі қайтару жолы туралы сұраққа айналады.

Әр ереже нені қайта жазады

Бастау NAT, әдетте SNAT деп жазылады, ағынның бастау мекенжайын ол маршрутизатордан немесе шлюзден шыққанда өзгертеді. Қабылдаушы қызмет аударылған мекенжайға жауап береді, ал аударатын қорап сол қосылым үшін сақтаған күйі арқылы өзгерісті кері қайтарады. Linux-те бұл күй conntrack ішінде тұрады, сондықтан conntrack -L түпнұсқа және жауап жұптарын қатар басып шығарады.

Межелік NAT, DNAT, оның орнына межені өзгертеді. UDP 51820 портындағы жария мекенжайға жіберілген пакетті 10.8.0.2:51820 мекенжайындағы ішкі WireGuard серверіне қайта жазуға болады. Үй маршрутизаторы немесе бұлттық жүктеме теңгерушісі VPN тыңдаушысын осылай жариялайды және бұл туннель кейін нені тасымалдай алатыны туралы ештеңе айтпайды.

Masquerade SNAT тұқымдасына жатады. Ереже ешбір мекенжайды атамайды; пакет шыққан кезде шығыс интерфейсте бар мекенжайды пайдаланады. Linux оған өз мақсатын береді және бұл мекенжайын DHCP немесе PPPoE арқылы алатын WAN интерфейсінде әдеттегі таңдау.

Сәйкестендіру қайда тұрса, ақау сонда анықталады

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

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

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

Masquerade немесе айқын SNAT

Екеуін уәде еткені бойынша салыстырыңыз. Masquerade шығыс мекенжайды таңдайды, айқын SNAT оны бекітеді. Тұрақты жария мекенжайы бар шлюзде бекіту журналдар мен серіктестердің рұқсат тізімдеріне бір болжамды мән береді. Динамикалық WAN арнасында бекітілген SNAT мекенжайы жалдау өзгерген сәтте қате болады, ал Masquerade дәл осы жағдай үшін құрылған.

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

Саясатқа негізделген IPsec осы жерде ең қатты шайнайды. strongSwan-ның жіберу жөніндегі нұсқаулығы IP жіберуді қосу мен клиенттер үшін бастау NAT ережесін қосуды кезең-кезеңімен көрсетеді, ал сол құжат өз түпнұсқа мекенжайын сақтауы тиіс трафикті шығарып тастауды да қамтиды. Қауіпсіздік саясаты оған сәйкес келмес бұрын бастауды аударыңыз, сонда туннель көтерілуі мүмкін, бірақ трафик әлі де құлайды, өйткені пакет енді келісілген селекторға ұқсамайды.

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

Linux шлюзінде ережелерді оқу

Клиенттері 10.8.0.0/24 желісінде және WAN интерфейсі eth0 деп аталатын қашықтан қатынау шлюзіне жіберу қосулы және ағынға рұқсат беретін сүзгі саясаты керек, содан кейін ғана қандай да бір NAT ережесі көмектесе алады. iptables нұсқасы екі бағытты да nat кестесінде ұстайды:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables нысаны сол екі ілгекті аталған интерфейспен және айқын тізбекпен пайдаланады:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Екі үзінді де сүзгі тізбегі жіберілген ағынды әлдеқашан қабылдайды деп есептейді. NAT рұқсат ережесі емес, ал дұрыс аударылған пакет бір кестеден кейін де тасталуы мүмкін. Тірі сәйкестендіруді conntrack -L арқылы растаңыз, не жүктелгенін nft list ruleset немесе iptables-save -t nat арқылы растаңыз, содан кейін мекенжай шынымен өзгеретінін көру үшін екі интерфейсте де түсіріңіз.

Нашар ережеге ұқсайтын ақау режимдері

Шаш түйреуіш трафигі — классика. Сервердің жария мекенжайы арқылы ішкі серверге жететін ішкі клиентке кіреберісте DNAT, ал қайта шығу жолында бастау аудармасы керек, әйтпесе сервер клиентке тікелей жауап береді және жауап қабылданбайды. Түзету — сол ішкіден жарияға жағдайы үшін екінші, тар ереже, бәріне арналған кеңірек Masquerade ережесі емес.

Қос аударма — үнсіз. Оператор деңгейіндегі NAT артында тұрған клиент сіздің шлюзіңізге кері маршруттау мүмкін емес мекенжаймен келеді, сондықтан қайта аударасыз. Жұмыс істейді, бірақ журналдар енді жеке мекенжайлаудың екі секірісін көтереді және кез келген тергеуге екі сәйкестендіру де қажет. Саясатқа негізделген IPsec үшінші бұрылыс қосады: саясат сәйкестігінен бұрын аударыңыз, сонда трафик өтпей тұрып көтерілген SA аласыз, бұл NAT емес, файрвол қатесі сияқты оқылады.

Сосын өтетін сынақ пен сәтсіз болатын орналастыру бар. NAT пәрменін қолмен жүргізу механизмді дәлелдейді, конфигурацияны емес. Жұмыс уақытында қосылған ереже қайта жүктеуде немесе келесі интерфейс оқиғасында жоғалады, ал нөмірі өзгеретін интерфейске байланған Masquerade ережесі алыс жақ көретін мекенжайды үнсіз өзгертуі мүмкін. Ережені оны иеленетін файрвол конфигурациясына салыңыз және қайта қосылғаннан кейін қайта тексеріңіз.

Ережені сақтамас бұрынғы тексеру тізімі

Алдымен бағытты атаңыз: бастау, меже немесе екеуі де. Содан кейін күйді кім ұстауы керектігін анықтаңыз — шлюз, жоғарғы маршрутизатор немесе IPsec серіктесі — және жауап жолы сол арқылы қайтатынын растаңыз. Ережені шынымен көздеген клиент ауқымымен, межемен және интерфейспен шектеңіз, ал алыс жақ шлюзді немесе клиенттің түпнұсқа мекенжайын көруі керектігін алдын ала шешіңіз.

Шлюзден емес, клиенттен сынаңыз. Шлюздің өзіндегі браузер клиентті аудару ережесін толығымен айналып өтуі мүмкін, сондықтан онда жұмыс істейтін бет туннель туралы ештеңе дәлелдемейді. Клиенттен шыққан бір сұраныс жіберіңіз, есептегіштер мен conntrack кестесін бақылаңыз және жұмыс орныңызда екеуінің бірі мүмкін болса, туннель қайта қосылғаннан және WAN мекенжайы өзгергеннен кейін қайталаңыз.