VPN портын ашу клиенттерге LAN-ға қосылуға мүмкіндік бермейді

Туннель көтеріледі, клиент аутентификациядан өтеді, бірақ шлюздің артындағы LAN көрінбей қалады. Мұны түзетуі тиіс ереже VPN портына рұқсат береді және жазылғандай дәл жұмыс істейді, өйткені ол ереже шлюздің өзіне бағытталған пакеттерді реттейді. Шлюздің артындағы хостқа баратын клиент трафигінің басқа межелі жері және басқа тізбегі бар. Сәтті кіру ядроның қай тізбекті қарайтынын өзгертпейді.

Екі тізбек, екі түрлі меже

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

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

Тыңдаушы ережесі шын мәнінде неге рұқсат береді

Тыңдаушы пакеттері VPN процесінде аяқталады, дәл сол туннельді құруға мүмкіндік береді. Шлюздің әкімшілендіру беті мен жергілікті диагностикалық жауап та хосттың өз кіру жолын пайдаланады, сондықтан шлюзге тексеру сәтті болады, ал оның артындағының бәрі сәтсіз аяқталады. Екі нәтиже де дұрыс және ешқайсысы LAN туралы емес.

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

Клиенттен тексеріңіз, ешқашан шлюзден емес

Шлюзде жасалған тест хосттың өз шығу жолымен жүреді және жіберу жолы жабық болса да өтуі мүмкін. Тесті клиенттен бастаңыз және ағынның екі ұшын бақылаңыз.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

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

Жіберуге бір емес, үш нәрсе қажет

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

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

Құжаттамада екі ереже жиынтығын бөлек ұстаңыз

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

Әр аутентификацияланған серіктесті сенімді LAN мүшесі деп санаудың орнына, қажет клиент ауқымдары мен қызметтер үшін тар ережелерді қолданыңыз. StrongSwan-ның жіберу туралы жазбалары сол шекараның қайтару маршруты мен аударма жағын сипаттайды, бұл тағы үшінші шешім.

Соңында, пайдаланушы қабылданбағанда қабаттарды түзу ұстаңыз. Егер сұраныс хостқа жетіп, қолданба тіркелгіні қабылдамаса, сол қабатта қолданба рұқсатын түзетіңіз; жіберуді кеңейту файл алмасу тіркелгі деректерін бере алмайды және сәтті қосылған барлық басқалар үшін қатынасты кеңейтеді.