AWS Client VPN арқылы үзілісті қатынас: әр байланысқан қосымша желіні тексеріңіз

Пайдаланушы қосылып, ішкі қолданбаны ашады және жауап алады; сол шеткі нүктедегі әріптес сол Wi-Fi-дағы бірдей ноутбуктен уақыт бітуін алады. Бұл үлгі бірнеше байланысқан қосымша желісі бар client VPN шеткі нүктесінің белгісі, онда жолдар тең емес. Мен мұны консольден сыртқа қарай қараймын, өйткені екі қойынды қалған тексерудің қажеттігін шешеді. Клиент конфигурациясында мұны түсіндіретін ештеңе жоқ.

Шеткі нүктеден бастап байланыстарды тізімдеңіз

VPC консолінде Client VPN endpoints ашыңыз, шеткі нүктені таңдап, Associations қойындысын оқыңыз. Әр байланыс — қолжетімділік аймағындағы қосымша желі, ал клиент қосылым құрылған кезде қызмет таңдаған желіге түседі. Қосымша желілердің ID-лерін және әрқайсысы нақты пайдаланатын маршрут кестесін жазып алыңыз, өйткені осы екі тізім — жасайтын салыстыруыңыз.

Егер шеткі нүкте тек бір байланыс көрсетсе, бұл теория дұрыс емес және клиент жақсырақ күдікті.

Шеткі нүктенің маршрут кестесін әр байланыспен салыстырыңыз

Сол шеткі нүктеде Route table қойындысын ашыңыз. Ондағы әр мақсатты CIDR-дің мақсаты бар, ал client VPN-де мақсат — шлюз емес, байланыс. AWS әр байланысқан қосымша желі үшін мақсат жазбасын талап етеді, сондықтан олардың тек біреуіне бағытталған маршрут қатынасты сессия қайда түскеніне тәуелді етеді. Сізге шынымен қажет мақсатты тексеріңіз, содан кейін оның авторизация ережесін тексеріңіз, өйткені маршрут жолды береді, ал ереже кім пайдалана алатынын шешеді.

Екі қабатты кестеге түсіргеннен кейін ақауды байқамау қиын.

Көп билеттерде екінші жол — бүкіл қате. Шеткі нүктенің маршруты бар, сондықтан ешкім әрі қарай қарамайды, ал пакет бір секірістен кейін VPC ішінде өледі.

Әр қосымша желіні оның әрекетті маршрут кестесіне дейін бақылаңыз

Айқын маршрут кестесі байланысы жоқ қосымша желі VPC-нің негізгі кестесін мұра етеді. Нақты күшіндегі кестені оқыңыз, атауы дұрыс көрінетін кестені емес, және жолдағы белгіні емес, мақсат пен мақсат нүктесін салыстырыңыз.

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

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

Авторизация ережелерін, содан кейін қайту жолын тексеріңіз

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

Қайту жолы да сондай назарға лайық. Peering қосылымы қолданба VPC-інде клиент CIDR-іне қарай маршрутты, екі шетте де трафикті рұқсат ететін қауіпсіздік тобы ережелерін және оны тастамайтын желілік ACL-ді қажет етеді. Бір бағытты қолжетімділік, яғни ping жұмыс істейді, ал TCP қол алысуы істемейді, әдетте VPN-ге емес, ACL немесе қауіпсіздік тобына нұсқайды.

Шеткі нүктенің өз қауіпсіздік топтары байланыстың серпімді желілік интерфейстерінде орналасқан, сондықтан қолданба портын клиент CIDR-інен рұқсат ететін ережені тек данаға емес, байланысқа да тіркеу керек.

Бір сәтті сұраныспен емес, қайта қосылумен тексеріңіз

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

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