Мен сырттан бастадым, пайдаланушы жасайтындай: атауды мобильді деректегі телефон браузеріне жазып, байланыстың уақыты бітпейінше ілулі тұрғанын бақыладым. Атау шешілетін, яғни DNS ретімен болды. Үй маршрутизаторының портты бағыттау беті де тұйық жол болды, өйткені оның WAN мекенжайы 100.64.31.42 көрсетті, ал бұл провайдер мені интернеттен бағыттайтын мекенжай емес. Бұл сан бүкіл ақауды түсіндіреді: желі carrier-grade NAT артында, сондықтан туннельдің мен жағымдағы жария мекенжайы провайдерге тиесілі. Әрі қарай сол ілулі қалған қойындыдан жауап беретін қызметке дейінгі жүрген жолым келеді.

Клиенттен бастап, ішке қарай жылжы

Кез келген ережені өзгертуден бұрын тізбектің қай жерде тоқтайтынын дәлелде. Ноутбукте dig +short files.example.net командасын орындап, VPS мекенжайын қайта алдым, бұл машинамдағы ескірген DNS-ті жоққа шығарды. Содан кейін curl -v --connect-timeout 5 files.example.net:5022 қабылдамау орнына уақыт бітіміне ұшырады. Бұл айырмашылық маңызды: уақыт бітімі әдетте пакеттердің жолда тасталатынын білдіреді, ал қабылдамау бірдеңенің жауап беріп, жоқ дегенін білдіреді.

Ішке қарай келесі қадам VPS-тің өзі болды. ss -ltnp 5022-де тыңдап тұрған ештеңе көрсетпеді, бұл DNAT ережесі пайда болғанға дейін күтілген жағдай еді. Сол машинада wg show (немесе OpenVPN үшін ip -br a show tun0) үй peer-інің жұмыс істеп тұрғанын және жаңа handshake бар екенін растады. Peer жұмыс істемесе, ешбір NAT ережесі көмектеспейді, ал үй маршрутизаторының VPN бетіндегі жасыл шам ештеңені білдірмейді.

Үй желісінің шын мәнінде CGNAT артында екенін раста

Маршрутизатордың WAN интерфейсінде хабарлайтын мекенжайын сыртқы қызмет көретін мекенжаймен салыстыр. 100.64.0.0/10 ішіндегінің бәрі, яғни 100.64.x.x-тен 100.127.x.x-ке дейін, RFC 6598-дегі ортақ мекенжай ауқымы және интернеттен қолжетімсіз. Маршрутизатор қарапайым жеке мекенжай бар деп мәлімдеп, жария сұраныс байланысы жоқ нәрсе қайтарғанда да сол қорытындыға келесің. CGNAT желісі тек келесі lease-ке дейін жарамды жария мекенжаймен де келуі мүмкін, сондықтан портты бағыттау бір сағат жұмыс істеп тұрғандай көрініп, содан кейін үнсіз өледі.

Кейбір провайдерлер шынымен нақты жария мекенжай береді, бірақ тұрғын үй шоттарында кіріс 80 және 443 порттарын блоктайды. Қызметің тек веб болса және WAN мекенжайы шынымен жария болса, relay құрмас бұрын қолдау қызметінен сұра. Ондай болмаса, төмендегі жоба әр портқа бірдей қолданылады және тәжірибені маршрутизатор жағында тоқтатқан жөн: провайдер желісіндегі аударғыш байланысты сенің WAN интерфейсіңе жетпей тұрып аяқтайды.

Атауды VPS мекенжайына бағытта

DNS трафикті өткізбейді, сондықтан қызметтің A жазбасында VPS-тің жария мекенжайы болуы керек. 192.168.1.20-ға бағытталған A жазбасы тек VPN ішіндегі клиенттер үшін пайдалы шешіледі; интернеттен ешкім бағыттай алмайтын мекенжайға шешіледі. VPS-тің өз әкімшілік кіруі үшін бөлек атау ұстаймын, жазбаның қай хостқа қатысты екенін ешқашан шатастырмау үшін.

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

Бір порт DNAT арқылы, SSH 22-де қалсын

Тікелей нұсқа — VPS-тегі межелі NAT. Жұмыс істеп тұрған ядроға forwarding қос және ережеде үй серверінің туннель мекенжайын ұста, LAN мекенжайын емес:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

VPS-тің өзіне SSH-ты 22-де қалдыр және басқа портты, мысалы 5022-ні, үй машинасына бағытта. 22-ні өшірулі машинаға бағыттасаң, оны түзете алатын жалғыз жолды жоғалтасың. Сол логика проксиге де қатысты: VPS-тің басқару портын relay ережелерінен тыс ұста.

Ережелер жұмыс істей бастағанда оларды тұрақты ет. Debian немесе Ubuntu-да apt install iptables-persistent және одан кейін netfilter-persistent save оларды /etc/iptables/rules.v4 файлына жазады. firewalld бар хостта баламасы — аймақтағы тұрақты портты бағыттау, ол қолданылу алдында firewall-cmd --reload талап етеді. Тек жадта өмір сүретін ережелер провайдердің бірінші техникалық қызмет көрсету қайта жүктеуінде жоғалады, әдетте жаман сағатта.

Қайтару жолын түзе немесе оған мұқтаждықтан қаш

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

Екі түзету жұмыс істейді. Үй машинасына саясат маршрутын бер, туннельден келген трафик туннель арқылы қайтатын болсын:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

Немесе VPS көзді қайта жазсын, жауаптың жете алатын мекенжайы болсын, ал conntrack оны шығыста кері айналдырсын:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

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

Бүкіл жолды сырттан тексер

Не VPS, не үй болып табылмайтын желіден тексер: мобильді деректегі телефон немесе басқа жердегі арзан shell. nc -vz files.example.net 5022 сәтті байланыс туралы хабарлауы керек, ал openssl s_client -connect files.example.net:443 -servername files.example.net жария атау үшін сертификатты көрсетуі керек. Содан кейін провайдердің қауіпсіздік тобын немесе бұлттық firewall-ын тексер. Ешқашан пакет көрмейтін DNAT ережесі әдетте хосттан бір қабат жоғарыда блокталады.

Соңында туннель құлағанда не болатынын шеш. DNAT ережесі байланыстарды қабылдауды жалғастырады және оларды үнсіз өлі туннельге жібереді, бұл дәл бұзылған қызметке ұқсайды. VPS-те peer жұмыс істемегенше портты қабылдамайтын денсаулық тексерісі бірнеше жолға тұрар және бір сағат болжамды үнемдейді. Осыдан кейін ережелерді өңдеуді тоқтат және оған сенбес бұрын бір күн бақыла.

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