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 менен четки чекиттин маршруттары байланыш орнотулганда жөнөтүлөт, ошондуктан өзгөргөн маршруттар топтому туташып турган клиентке эч качан жетпейт. Колдоого алынган клиент аркылуу ажыратып, кайра туташыңыз, анан жаңы маршруттар машинада бар экенин ырастаңыз.

Акырында байланыш журналын клиент алган дарек менен байланыштырыңыз жана бирден ашык туташууга туш болуш үчүн сыноону жетиштүү жолу кайталаңыз. Оңдоодон кийинки бир ийгиликтүү сурам бир жолдун иштешин далилдейт, ал эми билет экинчиси жөнүндө болчу.