VPN мен вебке арналған бір жария хост: рөлдерді қалай бөлу керек

Бір машина үш қажеттілікті бірден қанағаттандыра алады: туннельдерді аяқтау, HTTPS-ке жауап беру және екі жеке LAN арасында жіберу. Бұл орынды ма, ол қағазда шешуге болатын үш нәрсеге байланысты: жария мекенжай кімдікі, әр порт пен протокол жұбы кімдікі және қай процеске пакеттерді жіберуге рұқсат етілген. Осылар дұрыс болса, ортақ хост ерекше емес. Қате болса, таза іске қосылып, ешқашан жауап бермейтін қызметке демалыс күнін жұмсайсыз.

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

Мекенжай иесін порттардан бұрын таңдаңыз

Туннельдің соңғы нүктесі мен веб-сервер бір ядроны бөлісе алады; бір мекенжайды, портты және протоколды бір уақытта бөлісу — сәтсіздікке ұшырайтын нәрсе. WireGuard әдетте UDP 51820 қолданады, OpenVPN UDP 1194 немесе TCP 443 қолданады, ал веб-сервер TCP 443 қолданады. Ауыртатын жұп — HTTPS жанындағы TCP 443 үстіндегі OpenVPN, өйткені екеуі де бір сокетті қалайды және ядро оны бірінші байланысқанға береді. Тек алдында тұрған демультиплексор, мысалы sslh немесе TLS-ті түсінетін прокси, оларға бұл портты бөлісуге мүмкіндік береді, және ол істен шығуы firewall мәселесіне дәл ұқсайтын құрамдас қосады.

Бірдеңе өзгертудің алдында иелерге қараңыз: ss -lntup әр тыңдап тұрған сокеттің жергілікті мекенжайын, портын және процесін шығарады. Екі жол 0.0.0.0:443 көрсетсе, онда екінші қызмет ешқашан байланыспаған, оның init скрипті қаншалықты көңілді болса да. Көпір де иесін жылжытады. Қашан eth0 көпірге қосылады: br0, IP br0 мекенжайына ауысады және eth0 атайтын әр firewall ережесі сәйкестігін тоқтатады, сондықтан қызметтерді көпірге байланыстырып, ip -br addr арқылы растаңыз.

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

Екі LAN арасында маршруттаңыз немесе бір жағын NAT етіңіз

Бір-бірін көрмейтін екі LAN әрқайсысы жария хостқа қоңырау шала алады, ол кейін туннельдер арасында жібереді. Бұл маршрутталған дизайнға үш нәрсе керек: қосылған жіберу, әр шалғай префикске маршрут және транзитті өткізетін жіберу саясаты. sysctl -w net.ipv4.ip_forward=1 біріншісін қамтиды, ip route add 10.20.0.0/24 dev wg1 екіншісін, ал nftables жолы nft add rule inet filter forward iifname "wg0" oifname "wg1" accept үшіншісін.

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

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

Екі рөл тоқтап тұрғанда бөлуді тексеріңіз

Пайдалы тест — алу: екі рөлді тоқтатып, үшіншісінің әлі жауап беретінін растаңыз. Туннель қызметі өшіп тұрғанда веб-сұраныс аяқталуы керек, ал веб-сервер тоқтағанда туннель қол алысуы аяқталуы керек. Екеуі де бәрі жұмыс істегенде ғана жұмыс істесе, сізде кездейсоқ тәуелділік бар, мысалы ортақ firewall кестесі, адасқан маршрут немесе дұрыс емес мекенжайға сілтейтін атау.

Үш команда бұл тестті нақты етеді. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ жергілікті тыңдаушының сыртқы DNS-сіз жауап беретінін дәлелдейді, wg show клиентте қол алысудың аяқталғанын дәлелдейді, және tcpdump -ni any port 51820 хабта маршруттау мәселесін кілт мәселесінен ажыратады. Түсірілімде ешқашан көрінбейтін қол алысу хостқа дейін қайтыс болды: провайдердің firewall-ы, дұрыс емес жария мекенжай немесе жолдағы NAT ережесі.

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

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

Тек IPv6 қатынау желілері және IPv4 қызметтері

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

Әр отбасын бөлек тексеріңіз curl -4 және curl -6 арқылы, өйткені бір сәтті сұраныс сіз сынамаған жол туралы ештеңе айтпайды. Порт иелігі отбасылар арасында өзгермейді, бірақ тыңдаушы өзгереді: ss -lntup IPv4 және IPv6 сокеттерін бөлек жолдарда тізеді, және 0.0.0.0:443 мынаны қамтымайды: [::]:443 -ді, егер процесс dual-stack сокет сұрамаса.

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