Шлюз хостыць уласную адмін-старонку: унутраны адрас ці публічны
Паслуга на самім VPN-шлюзе патрабуе ўнутранага ўваходу, да якога можа дабрацца тунель. Апублікуйце яе прыватна, затым пераканайцеся, што публічны слухач больш не адкрыты.
Адмін-старонка адказвае з тэлефона на мабільных даных і сканчаецца па тайм-аўце з ноўтбука, далучанага да VPN. З тунелем усё ў парадку, бо запыт ніколі ў яго не трапляе. Імя хоста развязаецца ў публічны адрас шлюза, а гэты адрас даступны толькі ззовні тунеля, які ён завяршае. Выправіць гэта значыць даць паслузе прыватны ўваход, а не перасоўваць знешні канчатковы пункт.
Старонка загружаецца ззовні, а не праз тунель
Параўноўваюцца два розныя запыты. З мабільных даных браўзер дабіраецца да публічнага адраса напрамую. Знутры тунеля тое ж імя развязаецца ў той жа публічны адрас, і пакет цяпер мусіць выйсці праз тунель, каб дабрацца да адраса на ўласным далёкім баку тунеля. Тое ж імя, той жа адрас, два вельмі розныя становішчы.
Маршрут прызначэння выбірае адрас, а не порт. Нішто ў табліцы маршрутызацыі не ведае, што порт 443 прызначаны для адміністравання, а порт 1194 — транспарт, таму абодва разглядаюцца як адно і тое ж прызначэнне.
Вось чаму старонка часам працуе, а часам не, у залежнасці ад таго, якое імя і якую сетку выкарыстаў кліент. Гэта праблема шляху, а не праблема аўтэнтыфікацыі. Абодва кліенты цалкам паспяхова аўтэнтыфікуюцца.
Трымайце знешні канчатковы пункт даступным
Профілі поўнага тунеля патрабуюць выключнага маршруту для канчатковага пункта VPN, і опцыя redirect-gateway у OpenVPN дакументуе менавіта гэта: аддалены канчатковы пункт захоўвае маршрут праз існуючы шлюз, каб тунель не маршрутызаваўся ў сябе. Прыбярыце гэтае выключэнне, і зашыфраваны транспарт пойдзе за тунелем, што завяршае сеанс у пятлі. Менавіта праз гэтае выключэнне адрас канчатковага пункта застаецца даступным знутры тунеля.
Вынік у тым, што публічны адрас застаецца даступным з кліента, і таму запыт браўзера да гэтага адраса можа прайсці тое ж выключэнне і выйсці, не ўваходзячы ў тунель. Выключэнне робіць сваю справу, а шкоду наносіць імя.
Чытайце рашэнне маршруту, а не спіс інтэрфейсаў, перш чым нешта змяняць. Каманды ніжэй друкуюць рашэнне, а не інвентар. Запусціце іх з кліента, які не спрацаваў.
ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table allКалі пошук паказвае маршрут канчатковага пункта праз фізічны шлюз, паводзіны правільныя, і адмін-старонка проста накіроўваецца няправільным шляхам. Гэта і ёсць момант, калі развязанне імён становіцца выпраўленнем.
Дайце паслузе прыватнае імя
Паслузе патрэбна імя, якое развязаецца ў адрас шлюза ўнутры тунеля, захоўваючы пры гэтым семантыку сертыфіката і імя хоста, якую чакае праграма. Прыватны запіс зоны для адмін-імя — звычайны адказ, і ён пакідае транспартнае імя некранутым.
Не перанакіроўвайце транспартнае імя на ўнутраны адрас, бо наступнае ўсталяванне тунеля паспрабуе дабрацца да адраса, які існуе толькі ўнутры тунеля. Гэтая памылка дае VPN, які працуе роўна адзін раз.
Праверце абодва сямействы адрасоў, бо пакінуты запіс AAAA можа адправіць браўзер туды, куды прыватны план ніколі не пашыраўся.
dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/Узгадніце палітыку з месцам, дзе выконваецца працэс
Да роднага працэсу, які слухае на шлюзе, дабіраюцца праз шлях лакальнага ўваходу, таму ланцуг уваходу і прывязка сокета вырашаюць, ці будзе запыт прыняты. Правілы перасылкі і IP-перасылка не прымушаюць лакальны слухач адказваць. Дазвольце крыніцы тунеля ў палітыцы ўваходу і пераканайцеся, што працэс прывязаны да адраса, даступнага з тунеля.
Кантэйнер, апублікаваны на порце хоста, ідзе іншым шляхам, бо пакет падвяргаецца трансляцыі прызначэння і перасылцы. Гэты запыт сустракае палітыку перасылкі хоста і ўласныя правілы Docker, таму працоўны родны слухач можа суіснаваць з кантэйнерам, які адмаўляе той жа порт.
Парадак запуску мае значэнне ў абодвух выпадках, бо прывязка да адраса, які з'яўляецца толькі пасля ўздыму тунеля, моўчкі правальваецца пры загрузцы.
Праверце прыватны доступ і адхілены публічны шлях
Зрабіце новы іменны запыт ад аўтарызаванага кліента, захаваўшы ўласныя праверкі ідэнтычнасці праграмы. Затым паспрабуйце тую ж паслугу ззовні тунеля і пераканайцеся, што яна не адказвае. Прыватнае імя — гэта зручнасць, а не абмежаванне, а слухач, які ўсё яшчэ прывязаны да публічнага адраса, усё яшчэ адкрыты. Менавіта апошнюю праверку большасць аглядаў прапускае.
Чытайце прывязкі і стан фільтра, а не імя хоста, якое атрымалі карыстальнікі. Уздзеянне — уласцівасць сокета, а не імя. Гэтае адрозненне перажывае любую змену DNS.
ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/Калі ўнутраны запыт вяртае старонку, а знешні сканчаецца па тайм-аўце, у паслугі ёсць адзін наўмысны прыватны шлях і транспарт застаецца даступным. Калі знешні запыт усё яшчэ адказвае, слухач або апублікаваны запіс кантэйнера трэба звузіць, перш чым хтосьці назаве паслугу толькі ўнутранай.