Чаму кліенты OpenVPN не бачаць селектары IPsec на шлюзе

Прапінгуйце хост за аддаленым тунелем IPsec са шлюза — ён адказвае чыста, і тунель выглядае здаровым, а заяўка ідзе далей. Потым падключаны кліент спрабуе той жа хост і не атрымлівае нічога ў адказ. Той ping ніколі не быў доказам для патоку кліента, бо ён выйшаў з уласнага адрасу крыніцы шлюза і супаў з іншым селектарам IPsec. Разуменне таго, чаму два выпадкі разыходзяцца, — гэта большая частка выпраўлення.

Ping са шлюза правярае паток, які ваш кліент не выкарыстоўвае

Менавіта адрас крыніцы вызначае, якая палітыка ўжываецца. Пакет, створаны на шлюзе, выходзіць з адрасам з яго лакальнай LAN або з яго канцавой кропкі тунеля, і палітыка, якая яму адпавядае, была напісана менавіта для гэтага выпадку. Пакет кліента прыходзіць на інтэрфейс OpenVPN з адрасам з пула кліентаў, а гэта зусім іншы селектар.

Таму збой выглядае як праблема маршрутызацыі, хоць насамрэч гэта праблема ахопу палітыкі. Дакладнасць са шлюза даказвае, што партнёр працуе і прапановы ўзгоднены, і нічога не даказвае пра тое, ці абаронены пул.

Праштурхніце аддалены прэфікс, які рэальна патрэбны праграме

Вазьміце ілюстратыўную пару 10.8.0.0/24 для падключаных кліентаў і 172.30.239.0/25 для абароненай аддаленай сеткі. Кліенту патрэбны маршрут да другога прэфікса, а не да LAN шлюза і не да нейкага іншага адрасу тунеля. Менавіта маршрут, прасунуты ў пул, прымушае кліента наогул перадаць гэты трафік шлюзу. Без яго пакет ніколі не дасягне таго рашэння палітыкі, якое вы адладжваеце.

У серверы Community, які прымае прасунутыя маршруты, дырэктыва бярэ сапраўдную маску: push "route 172.30.239.0 255.255.255.128". Access Server наладжвае тую ж мэту праз параметры прыватнай сеткі або правілы доступу ўсталяванай версіі, а рэжым маршрутызацыі ці трансляцыі выбіраецца свядома. Рэдагаванне згенераваных ланцугоў firewall замест галоўнай канфігурацыі — гэта шлях да таго, што працаздольная ўстаноўка становіцца неўзнаўляльнай.

Пасля падключэння чытайце табліцу маршрутызацыі кліента, а не намеры сервера. Маршрут, які пакрывае толькі пул, азначае, што прасоўванне не дайшло, а маршрут па змаўчанні праз тунель шырэйшы за гэтае патрабаванне і здзівіць вас пазней. Праверце маску разам з прэфіксам, бо /25, прасунуты як /24, накіроўвае трафік суседніх адрасоў у шлях, які не можа яго несці. Затым пераканайцеся, што кліент выбраў інтэрфейс тунеля для гэтай мэты.

Уключыце пул кліентаў у селектары

Для маршрутызаванага доступу, які захоўвае адрасы кліентаў, палітыка IPsec павінна абараняць трафік паміж пулам і аддаленым прэфіксам. Селектары, напісаныя для ўласнай LAN шлюза, прапускаюць ping і адкідаюць запыт кліента, і гэта менавіта тая асіметрыя, з якой пачалося гэтае расследаванне.

Праверце ўзгодненую палітыку разам з наладжанымі прапановамі, напрыклад з дапамогай ipsec statusall на strongSwan або эквівалентнай каманды стану для вашай рэалізацыі. У IPsec на аснове палітык звычайны маршрут можа паказваць на фізічны інтэрфейс, пакуль адпаведны трафік усё яшчэ шыфруецца, таму адсутнасць прылады тунеля нічога не даказвае. Параўнайце пары селектараў з пулам і прэфіксам, якія вы запісалі.

Агульны source NAT на шлюзе таксама можа парушыць супадзенне. Калі правіла masquerade перапісвае крыніцу кліента да праверкі палітыкі, пакет ужо не выглядае як напісаны вамі селектар. Гэта адна з прычын, чаму шырокае правіла masquerade — дрэннае рашэнне для другога VPN: яно змяняе палітыку, якая ўжываецца, і адрас, які бачыць аддалены бок. Выключыце трафік, які вы збіраецеся маршрутызаваць, або транслюйце яго свядома і абнавіце селектары.

Свядома выбірайце маршрутызацыю або трансляцыю

Маршрутызацыя пакідае адрас кліента бачным для аддаленага боку, таму аддаленыя журналы і правілы па кожнай крыніцы застаюцца змястоўнымі, і патрабуе, каб аддалены шлюз ведаў зваротны шлях да пула. Трансляцыя хавае пул за адным адрасам, што здымае праблему зваротнага маршруту і знішчае ідэнтычнасць кожнага кліента.

Выберыце адзін дызайн і запішыце яго, бо два патрабуюць розных селектараў і рознага парадку firewall. Напалову ўжыты masquerade апынаецца паміж імі і не задавальняе ніводнага. Запісаны выбар — гэта таксама тое, што дазваляе наступнаму інжынеру адрозніць памылку ад свядомага рашэння.

Замкніце цыкл на перанакіраванні і адказе

Шлюз павінен перанакіроўваць той пратакол і мэту, якія вы маеце на ўвазе, а гэта значыць уключаны IP forwarding і ланцуг перанакіравання, што дазваляе пару. Затым аддалены бок павінен адпраўляць адказы назад праз шлях IPsec, і гэта рашэнне маршрутызацыі на іх шлюзе, а не на вашым. Абедзве паловы — звычайная канфігурацыя, і абедзве лёгка пакінуць недаробленымі. Тэстуйце іх асобна, каб адсутнае правіла перанакіравання не прынялі за зламаны тунель.

Праверце адным рэальным запытам ад кліента да праграмы, назіраючы, як ён перасякае інтэрфейс OpenVPN, рашэнне IPsec і аддалены хост. Разглядайце адказ як асобнае назіранне, бо запыт, які дайшоў, і адказ, які ніколі не вярнуўся, выглядаюць аднолькава з месца кліента. Адзін прасочаны запыт каштуе больш за любы лік ping са шлюза.

Трымайце аўтарызацыю мэты вузкай, пакуль тэстуеце, і пераканайцеся, што кліент без правіла не можа дасягнуць сэрвісу. Усталяваны маршрут разам з усталяванай асацыяцыяй — не тое ж самае, што дадзены доступ.