NAT артындағы WireGuard peer-іне портты қайта бағыттау: DNAT және SNAT

DNAT сұранысты жеткізеді, бірақ жауап дұрыс емес мекенжайдан шығады. Сәйкес SNAT ережесін қосып, екеуін де туннель конфигурацияланғаннан кейін орналастырыңыз.

Браузер https://203.0.113.10:8443 мекенжайын сұрайды, прокси қосылымды қабылдайды, ал WireGuard peer-індегі қызмет ешқашан жауап бермейді. DNAT ережесі өз жұмысын істеп тұр; сәтсіздікке ұшырайтын бөлік – жауап. Пакетті екі трансляция арқылы бақылаңыз, сонда жетіспейтін ереже айқын болады. Түзету – дұрыс hook-тегі тағы бір NAT мәлімдемесі, жаңа туннель емес.

Бір сұранысты басынан аяғына дейін бақылаңыз

Сұраныс проксидің жария интерфейсіне келеді, көзі – клиенттің жария мекенжайы, межелісі – прокси мекенжайы. nat PREROUTING ішінде DNAT ережесі межеліні peer-дің туннель мекенжайына, 10.90.0.2-ге қайта жазады. Содан кейін маршруттау шешімі пакетті wg0 арқылы сыртқа жібереді және қайта жіберу жолы аяқталады.

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

Асимметрия – бүкіл мәселе: сұраныс прокси арқылы өтеді, ал жауап тікелей жүргісі келеді. Проксидің қосылымды бақылауы жауап прокси арқылы қайтқанда ғана көмектеседі, ал көз мекенжайы әлі бастапқы клиентке нұсқап тұрғанда ол онда қайта алмайды.

Қайта трансляцияны қосыңыз

Қайта жіберілетін ағынның көзін peer-ге кетер алдында проксидің туннель мекенжайына қайта жазыңыз. Содан кейін қызмет 10.90.0.1-ге жауап береді, прокси оны қабылдайды және пакет клиентке қайтпас бұрын қосылымды бақылау екі трансляцияны да кері айналдырады.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

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

Ережелерді туннель бар жерге орналастырыңыз

Туннель мекенжайына немесе интерфейсіне сілтейтін ережелер wg-quick оны конфигурациялағаннан кейін орындалуы керек. Интерфейс PreUp-тан бұрын құрылады, бірақ мекенжайлар, MTU, DNS және маршруттар одан кейін қолданылады, ал PostUp осының бәрі орнында болғанда іске қосылады. Қосымшаларды PostUp-қа, жоюларды PreDown-ға қойыңыз.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

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

Нәтижені iptables -t nat -S арқылы қайта қосылғаннан кейін тексеріңіз. Егер сол ереже екі рет көрінсе, PreDown жолы сәйкес келмейді және тазалау үнсіз сәтсіз аяқталады.

Қайта жіберу, сүзу және басқа NAT

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

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

NAT VPS-те провайдер жария портты жеке мекенжайға салыстырады. Салыстыру сіз жариялаған портқа сәйкес болуы керек, ал сәйкессіздік бұзылған туннельге дәл ұқсайды. WireGuard конфигурациясын өзгерту алдында провайдердің салыстыруын растаңыз.

Қайту жолын тексеріп, құнын қабылдаңыз

Проксидің LAN-ы болып табылмайтын желіден қосылыңыз, содан кейін қосылым ашық кезде трансляция жұбын тексеріңіз:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

conntrack жазбасы бастапқы tuple-ды, аударылған tuple-ды және жауап бағытын көрсетуі керек. Егер жауап жоқ болса, peer туннель арқылы жібермейді, бұл әдетте SNAT ережесі қолданылмағанын немесе peer-дің өз файрволы ағынды тастағанын білдіреді.

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

Соңында, SNAT қанша тұратынын қабылдаңыз. Қызмет әр сұранысты проксиден келген деп көреді, сондықтан кіру журналдары, клиентке шаққандағы жылдамдық шектеулері және рұқсат етілген мекенжай тізімдері енді пайдаланушыларды ажыратпайды. Hairpin жағдайы проксидің LAN-ындағы клиенттер үшін өзінің көз трансляциясын қажет етеді. Егер peer-ге нақты клиент мекенжайлары қажет болса, балама – клиент желісіне қайту маршруты, бұл көбірек жұмыс, бірақ ақпаратты сақтайды.

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