NAT VPN сервериндеби же маршрутизатордобу? Экөө тең иштеши мүмкүн

Ноутбукта байланышты демейки маршрут катары белгилөө — баары эстеген кадам, жана ал шлюзде эч нерсени өзгөртпөйт. Клиент азыр интернет суроолорун туннелге жөнөтөт; алар имараттан чыгабы, бул өткөрүүгө, которуу пунктуна жана клиенттин жеке дарегине жеткен кайтаруу жолуна байланыштуу. Эки конфигурация үчөөнү тең бере алат, алар ишти ар башка жерлерге коёт, жана жооп багытына эч ким жооптуу болбосо, экөө тең ошол эле тынч жол менен ишке ашпайт. Алардын арасынан тандоо клиент пулун ким көрүшү керек деген суроо.

Уламыш: клиент маршруту чыгууну курат

Мажбурлап туннелдөө — клиент тараптагы саясат: ал трафиктин физикалык адаптерге эмес, VPN адаптерине барарын чечет. Microsoft'тун VPN маршруттоо документтери ошол бөлүнүүнү жана мажбурлоо жүрүм-турумун сүрөттөйт, жана бул клиенттин маршруттар таблицасы жөнүндө билдирүү, сервердин өткөрүү эрежелери жөнүндө эмес. Клиенттин көз карашынан туннель — интернет жашаган жер; шлюздун көз карашынан пакет жогоруда эч ким укпаган даректен келди. Эч бир тарап өзүнчө туура эмес конфигурацияланган эмес, ошондуктан ноутбуктун жанындагы адамга бузулуу сынган сервердей көрүнөт.

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

Алгач жооп жолун тартыңыз

Каалаган жөндөөгө тийүүдөн мурун жолду реалдуу даректер менен жазып чыгыңыз жана ага эки мүмкүн болгон которуу пунктун белгилеңиз. Бул лаборатория 10.70.0.0/24 VPN пулун колдонот, анда бир клиент 10.70.0.37 дарегинде, сервердин LAN дареги 172.16.40.10, маршрутизатор 172.16.40.1 дарегинде жана коомдук чыгуу 203.0.113.40 дарегинде.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Интернетти буга чейин карап жүргөн сервер өз жолун гана далилдейт. Клиенттин атынан өткөрүлгөн пакет — ошол эле машинадагы өткөрүү саясаты кабыл алган башка чечим, жана адатта дал ошол жетишпейт. Диаграммадагы үч чечим пунктун белгилөө сүйлөшүүнү бир убакта алардын биринин айланасында кармайт.

A варианты: VPN серверинде которуу

Бул жерде сервер пакетти маршрутизаторго берүүдөн мурун клиенттин булагын өзүнүн LAN дарегине которот, ал эми маршрутизатор чыгуу жолунда кадимки которуусун колдонот. Жоопто маршрутизатордун байланышы сервер дарегин, сервердин байланышы клиент дарегин калыбына келтирет. Катары менен эки абалдуу которуу кадимки жана аткарылуучу, экөө тең жазылса; маршрутизаторго пулга чейинки маршрут эч качан керек эмес, жана бул ушул конфигурациянын жагымдуулугу.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

NAT бар деп болжолдоонун ордуна серверде эмне бар экенин көрүү үчүн бул окууларды колдонуңуз. Блогдон көчүрүлгөн Linux masquerade эрежеси Windows конфигурациясы эмес, жана VPN угуучусу үчүн хосттун файрволундагы уруксат клиенттин суроосун андан ары өткөрүү уруксаты менен бирдей саясат эмес. Сервердин өткөрүү ролун өзүнүн башкаруу интерфейсинен ырастаңыз, анан которууну өзүнчө караңыз, анткени экөөнү көбүнчө жайгаштыруунун ар башка бөлүктөрү күйгүзөт.

B варианты: пулду маршрутизаторго өткөрүү

Экинчи конфигурацияда сервер клиенттин чыныгы булак дарегин өткөрөт, ал эми маршрутизатор аны которот. Бул клиент пулун четинде көрүнүп туруусун камсыздайт, эгер маршрутизатор трафик саясаты, журналдоо же текшерүү жүргөн жер болсо, бул жардам берет. Бул ошондой эле маршрутизаторго 10.70.0.0/24 үчүн 172.16.40.10 көрсөткөн кайтаруу маршруту, ошондой эле ошол префиксти чындап камтыган интернет саясаты керек экенин билдирет; LAN ички тармагы үчүн жазылган эреже пулга тынч жайылбайт.

Муну четинин түзмөгү саясаттын көздөлгөн ээси болсо жана маршруттоо жана которуу таблицаларына дагы бир префиксти кабыл ала алса тандаңыз. Пул жогоруда көрүнбөй калышы керек болсо жана маршрутизаторду ошол эле команда башкарбаса, сервер тараптагы которууну тандаңыз. Эч бир вариант клиенттеги белги кутучасынан келип чыкпайт, жана эч бири жалпысынан кооптуураак эмес; алар көрүнүү менен тейлөөнү ар башка жерлерге коёт.

DNS, IPv6 жана кабыл алууну ачык кылыңыз

Даректерди которуу аттарды чечүүнү оңдобойт. Клиент VPN профили менен берилген чечүүчүнү, белгилүү ат мейкиндиктери үчүн жеке чечүүчүнү же бекитилген коомдук чечүүчүнү колдоно алат, жана ошол саясат боюнча жеткиликсиз чечүүчү маршруттоо иштегенден кийин да ишке ашпай берет. Ат менен даректи өзүнчө текшериңиз, эки бузулуу эч качан бир отчётко кошулбасын.

IPv6 дизайнда өзүнүн абзацын талап кылат. Иштеген IPv4 которуусу IPv6 клиенттеринин маршруту, жарактуу коомдук булагы же туннель кулаганда аларды тоскон саясаты бар-жогу жөнүндө эч нерсе айтпайт. Муну айтылбай калтыруу клиенттердин жарымы шлюзду тынч айланып өтүп, калган жарымы иштейт дегенди билдирет.

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