nginx бұзылмай тұрып OpenVPN SNAT ережесінің ауқымын шектеңіз
Клиенттер аутентификациядан өтеді, бірақ ештеңе маршрутталмайды, немесе VPN көтерілгеннен кейін сайт құлайды. tun қатынасын тексеріп, содан кейін аударманы pool және бір интерфейспен шектеңіз.
Бір типті хосттан екі ақау үнемі келеді. Біріншісінде клиенттер аутентификациядан өтіп, содан кейін туннельден тыс ештеңеге жетпейді. Екіншісінде VPN көтеріледі және сервердің өз сайты жауап беруді тоқтатады, бұл неғұрлым алаңдатарлық, өйткені жанама залалға ұқсайды. Контейнерге негізделген VPS-те екеуі де әдетте бірдей қысқа тексеру тізіміне қайтады, және рет маңызды: алдымен құрылғы, екінші аударма, үшінші ауқым.
Контейнердің tun құрылғысын жасай алатынына көз жеткізіңіз
Туннель интерфейсі өмір сүре алмаса, басқа ештеңе маңызды емес. /dev/net/tun бар екенін және сынақ құрылғысын жасау сәтті болатынын тексеріңіз, өйткені көптеген провайдерлер контейнерлер ішінде tun-ды әдепкі бойынша өшіреді. Ешқашан жасалмаған құрылғыны ешбір firewall жұмысы өтей алмайды.
Егер құрылғы жоқ болса, оны тек хост немесе провайдер қоса алады. Басқа жоспар бір аптаға созылатын ашық қолдау тармағынан арзан болуы жиі кездеседі. OpenVPN журналының бір жолын оқымас бұрын мұны растаңыз. Әйтпесе түнді ешқашан пакет көрмейтін ережелерді реттеуге жұмсайсыз.
Осы интерфейсте MASQUERADE не істейтінін шешіңіз
Кәдімгі виртуалды машинада әдеттегі шығу ережесі негізгі интерфейстен POSTROUTING MASQUERADE болады. OpenVZ контейнерінде көрінетін құрылғы жиі venet0, яғни хост басқаратын виртуалды интерфейс, маршрутталған желілік карта емес, және MASQUERADE онда оқулықтар болжайтындай әрдайым әрекет ете бермейді.
Жарамды нысан — клиенттер әлдеқашан жететін мекенжайға айқын аударма, екі бағытта да жіберуге рұқсат берілген. Сервер конфигурациясынан pool-ды ауыстыру мекенжайды ауыстыру сияқты маңызды. Әр жолды қою алдында оқыңыз.
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTЖіберу ережелері болмаса, аударма бәрібір орындалады және ядро бәрібір жіберуден бас тартады. Бұл үйлесім NAT ережесінің санауыштары өсіп жатқанда клиент ештеңе алмайтын шатастыратын күйді тудырады. Екі FORWARD жолы да сол шынжырдағы кез келген кең drop ережесінің алдында тұруы керек. Рет конфигурацияның бөлігі, іске асыру егжей-тегжейі емес.
Ережені бір pool және бір интерфейспен шектеңіз
Екінші симптомның себебі басқа: дереккөз де, шығу да шектелмеген POSTROUTING ережесі. Мұндай ереже хосттан шыққан әр пакетті қайта жазады.
Бастапқы дереккөзге тәуелді қызметтер содан кейін дұрыс емес әрекет етеді. Жергілікті прокси артындағы веб-сервер жауап беруді тоқтатуы мүмкін, және оны қайта іске қосу ештеңені өзгертпейді, өйткені ереже әлі жолда. Хосттың өз жария мекенжайына жіберетін трафигі де зардап шегеді, сондықтан ақау firewall емес, DNS немесе сертификат мәселесі болып көрінуі мүмкін. Ереже бірінші симптомды түзету үшін қосылған болуы әбден ықтимал.
Шешім — сәйкестікті туннель pool-ына және шығу интерфейсіне тарылту, содан кейін бірнешеуін қамту үшін бір ережені кеңейтудің орнына әр pool үшін бір ереже қосу.
Ережелерді тұрақты етіп, оларды тағы кім иеленетінін анықтаңыз
Қолмен қосылған ережелер қайта жүктеу кезінде жоғалады, сондықтан оларды iptables-save арқылы сақтаңыз немесе орнатылған жерде netfilter-persistent арқылы басқарыңыз. Қалпына келтіру OpenVPN басталғанға дейін жүретінін растаңыз. Содан кейін олқылықты оқиға кезінде табудың орнына бір рет әдейі қайта жүктеңіз.
Контейнер хостында тұрақтылық файлының жазылатын контейнер қоймасында екенін және провайдердің жүктеу кезінде сүзуді алмастырмайтынын да растаңыз. Кейбір платформалар саясатты контейнерден тыс басқарады, онда жергілікті ережелер не еленбейді, не хосттың өз ережелерімен қақтығысады.
Санауыштармен және бір түсірілген ағынмен тексеріңіз
Қосылған клиенттен сыртқы қызмет хабарлайтын жария мекенжайды тексеріңіз. Егер ол сервердің мекенжайымен сәйкес келсе, аударма жұмыс істейді; сәйкес келмесе, пакет басқа жолмен шығады немесе мүлдем шықпайды. Содан кейін серверде орналасқан қызметті де, жария интернеттегі қызметті де сынап көріңіз, өйткені олар бір ережелер жиынтығы арқылы әртүрлі жолдармен өтеді.
Серверде NAT және FORWARD ережелеріндегі пакет санауыштарын iptables -t nat -L -v -n арқылы оқып, түсірілімде бір ағынды бақылаңыз. Егер түсірілімде клиенттің мекенжайы көрінсе және жауап келмесе, олқылық қайтару жолында немесе провайдердің сүзуінде, клиент профилінде емес. Түсірілген дереккөзді ереженің аударатын мекенжайымен салыстырыңыз, өйткені сәйкессіздік бұрын басқа ереже сәйкес келгенін білдіреді. Бір бақыланған ағын конфигурацияны оқудың бір бетінен көбін шешеді.
Pool-ды, аударылған мекенжайды және интерфейс атауын өзгерістер жазбасында бірге ұстаңыз. Бір pool үшін дұрыс ереже келесісін қате аударады.