Неге Access Server клиенттері LAN-нан қолжетімсіз
Маршрутталған клиенттер өз пулының мекенжайын сақтайды, сондықтан жауаптарға кері маршрут қажет. Қызметтегі көзді оқып, сосын пул маршрутын дұрыс шлюзге қосыңыз.
Ноутбук қосылады, туннель көтерілген, ал ішкі қызметке кеткен сұраныстар қосылу кезінде ілініп қалады. Қызметтің өзінде сұраныс 10.90.0.25 сияқты мекенжайдан келеді, жауап әдепкі шлюзге қарай шығады және ештеңе қайтпайды, өйткені бұл шлюз 10.90.0.25 қайда екенін білмейді. Екінші жақтан сол ақау қосылған клиентке ping жасай алмайтын ішкі хост сияқты көрінеді. Екеуі де бір жетіспейтін нысан: VPN клиенттер пулына кері маршрут, оны тек жеке желі қоса алады.
Қызмет көретін көз мекенжайын оқыңыз
Сол бір өріс қалғанының бәрін шешеді. Егер ішкі қызмет пул мекенжайын көрсе, Access Server клиент трафигін жасырудың орнына маршруттайды, және әр жауап пулға кері маршрутталуы керек. Егер ол орнына сервердің өзінің жеке мекенжайын көрсе, сервер маскировка жасайды және кері жол қазірдің өзінде жұмыс істейді, бірақ қызметтің журналдары мен қатынау ережелерінде әр клиенттің жеке сәйкестігі жоғалады.
Бірдеңе өзгертуден бұрын екі жақты салыстырыңыз. Серверде туннель интерфейстері мен олардың мекенжайларын тізімдеңіз; клиентте оның қай мекенжайды шын мәнінде ұстайтынын растаңыз; ішкі хостта белсенді қосылымды қараңыз.
ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25Соңғы пәрмен сынған жағдайда сәтсіз болатын пәрмен: ол не туннель префиксін қолжетімсіз деп хабарлайды, не, одан да жаман, әдепкі шлюзіңізді қайтарады, және жауаптар интернетке осылай шығады.
Тек бір пул бар деп ойламаңыз. Серверде динамикалық ауқым және әр пайдаланушыға статикалық сәйкестендіру болуы мүмкін, ал статикалық мекенжай динамикалық префикстен мүлдем тыс болуы мүмкін. Егер тек есте қалған ауқымды маршруттасаңыз, тұрақты мекенжайлы пайдаланушылар бұзылып қалады, ал қалғандары мәселе шешілді деп хабарлайды.
Маршрутты жауап шешілетін жерге қосыңыз
Маршрут ішкі қызмет әлдеқашан пайдаланып жатқан шлюзге тиесілі, қызметтің өзіне емес, егер ол өз трафигін өзі маршруттамаса. Оны Access Server-дің қолжетімді жеке мекенжайына бағыттаңыз, ол клиент ұстайтын туннель мекенжайынан өзгеше мән.
ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25Бұлтты желіде сол тұжырым маршруттар кестесінің жазбасына айналады, оның мақсаты сервер жұмыс істейтін инстанс немесе желілік интерфейс, және сол интерфейсте көз бен межелік тексерісі өшірілген. Бұл жазбаның нені істемейтініне назар аударыңыз: маршрут қатынау беру құралы емес, сондықтан қауіпсіздік топтары, желілік ACL және хосттың firewall-ы трафикке әлі де рұқсат беруі керек.
Оны тұрақты етіп жасаңыз және пул өлшемдерін адал ұстаңыз. Көршілес емес екі пулға екі маршрут қажет, ал конфигурацияланған префикстен асып өсетін пул жауаптары барар жері жоқ клиенттерді үнсіз жасайды. Егер пул ауқымдарын өзіңіз басқарсаңыз, бір рет маршруттап, содан кейін тыныш қалдыруға болатын жиынтықты таңдаңыз.
Қайта бағыттау мен сүзгілер маршрутқа сәйкес болуы керек
Маршруттау — жолдың тек жартысы. Серверге туннель мен жеке интерфейс арасында қайта бағыттауға рұқсат берілуі керек, бұл Linux-та net.ipv4.ip_forward және интерфейстер жұбына рұқсат беретін қайта бағыттау тізбегін білдіреді, ал қатайтылған хостта әдетте әр бағыт үшін жеке айқын ереже.
sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forwardКүйлі сүзгілеу адамдарды дұрыс емес жолға салатын белгіні түсіндіреді. Орныққан ағынның ішіндегі жауапқа жаңа кіріс ережесі қажет емес, сондықтан SYN-ACK-тан кейін ілінетін қосылымды жетіспейтін accept ережесі бөгемейді; ол тасталады немесе дұрыс емес маршрутталады. Осы айырмашылықты сақтаңыз, өйткені ол маршруттау өзгерісін firewall өзгерісінен ажыратады.
Асимметриялық кері жолдар — сол мәселенің тынышырақ нұсқасы. Егер пулға екі маршрут жетсе және жауап сұраныс келген интерфейстен өзгеше интерфейстен шығатын маршрутты таңдаса, қатаң кері жол сүзгісі оны тастайды да, ағын тек кейбір клиенттерде сәтсіз болады.
Маршрутталған немесе маскировкаланған: саналы түрде таңдаңыз
Маршрутталған режим клиенттің пул мекенжайын қызметте сақтайды, бұл әр клиент бойынша журналдау мен саясатты мүмкін етеді, ал орнына клиентке жауап беруі тиіс әр ішкі желіге пул маршруты қажет. Маскировка режимі бұл талапты жояды, өйткені жауаптар серверге қайтады, бірақ қызмет енді бір клиентті екіншісінен ажырата алмайды және нақты клиентке қарай ештеңе бастай алмайды.
Бұл мінез-құлықты жұмыс істеп тұрған серверде өзгерту бар сессияларды үзеді, сондықтан алдымен бір клиент пен бір ағынмен сынап көріңіз. Егер ауысу дұрыс жауап болса, бұл сервердегі конфигурация шешімі, кейін қажетсіз болатын маршруттарды қосу арқылы айналып өтетін нәрсе емес.
Клиенттің артындағы қосалқы желі — жеке міндет
Ноутбуктің өз LAN-ындағы құрылғыға жету ноутбуктің туннель мекенжайына жетумен бірдей емес. Ол клиенттің қосалқы желі шлюзі ретінде әрекет етуін талап етеді: клиент жағында жарияланған желі, клиенттің операциялық жүйесінде қосылған қайта бағыттау, және сол LAN-да клиентке кері маршрут. Ноутбуктің үй ауқымы үшін жеке желі маршрутын қосу мұны жасамайды және екі пайдаланушының үй ауқымы бірдей болғанда қақтығыс тудырады.
Бағыт та саясат мәселесі. Клиентке ішкі қызметке қосылым ашуға рұқсат беру ішкі хостқа сол клиентке қосылым ашуға автоматты түрде рұқсат бермейді. Жол бұзылған деп қорытынды жасамас бұрын сервердің қатынау саясатын және клиенттің хост firewall-ын тексеріңіз.
Бір ағын және бір түсіріліммен растаңыз
Жолды жалпы қолжетімділік тестінің орнына бір қосылыммен дәлелдеңіз. Екі жақта бірдей ағынды бақылаңыз: қызметке келетін сұраныс пен одан шығатын жауап.
tcpdump -ni any host 10.90.0.25 and port 443Түзетуден бұрын түсірілім жауаптың оны маршруттамайтын шлюзге қарай кетіп бара жатқанын көрсетеді. Түзетуден кейін жауап серверге қарай кетеді және ағын аяқталады. Сосын шлюздің екінші клиент мекенжайы үшін қолданатын маршрутын растаңыз, сонда жабылмаған пул аптадан кейін емес, қазір көрінеді.
Осыны жабатын төрт тексерумен аяқтаңыз: қызметтегі көз мекенжайы көздеген режимге сәйкес, шлюздің әр пайдаланылатын пулға маршруты бар, қайта бағыттау мен сүзгілер екі бағытқа да рұқсат береді, және бір нақты ағын басынан аяғына дейін аяқталады. Access Server маршруттауы туралы жиі қойылатын сұрақтар орнатылған шығарылым үшін сол қағиданы баяндайды, оның қолдау көрсетілетін конфигурация интерфейсі ескі нұсқаулықтардан өзгеше болуы мүмкін.