Адзін порт OpenVPN, тры службы: навошта патрэбны ўнутраныя порты

Адна сесія SSH, адно вэб-праграма і адзін запыт імені могуць сумесна выкарыстоўваць адно VPN-злучэнне, не змагаючыся за порты. Кліент будуе адзін шыфраваны паток да шлюза, і кожная размова праграмы ідзе ўнутры яго. Звонку бачныя толькі ўласны транспарт і порт тунеля. Унутры кожная служба захоўвае свой порт і па-ранейшаму патрабуе ўласнага дазволу.

Што нясе знешні паток і што ён хавае

Кліент заварочвае кожны пакет у транспарт тунеля, перш чым той пакіне машыну. Гэты знешні паток мае адзін порт прызначэння, зафіксаваны пры налашванні VPN. Унутры абгорткі кожны зыходны пакет захоўвае адрас і порт службы, на якую ён накіраваны. Шлюз здымае абгортку і маршрутызуе па ўнутраным загалоўку, таму пункт прызначэння бачыць звычайнага кліента, які прыйшоў з сеткі.

Такім чынам, перахоп на інтэрфейсе WAN паказвае адну размову, а не тры. Унутраныя порты з'яўляюцца толькі пасля дэкапсуляцыі. Менавіта таму адно адкрыццё ў міжсеткавым экране можа несці SSH, HTTPS і DNS адначасова.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

Дакументацыя TUN/TAP апісвае перадачу, пры якой маршрутызаваная прылада TUN перадае IP-пакеты паміж ядром і працэсам у прасторы карыстальніка. Менавіта дзякуючы гэтай перадачы ўнутраны загаловак бачны коду маршрутызацыі і міжсеткавага экрана шлюза. Яна таксама тлумачыць, чаму знешні порт нічога не кажа пра тое, якія службы дазволены.

Перанакіраванне NAT належыць слухачу, а не праграмам

Самастойна размешчаны шлюз за IPv4 NAT патрабуе адной уваходнай трансляцыі: публічны адрас і порт адлюстроўваюцца на слухача VPN. Ніякае правіла не патрэбна для SSH, HTTPS або DNS толькі таму, што карыстальнікі тунеля да іх дасягаюць. Публікацыя гэтых портаў выкрыла б службы, якія тунель ужо абараняе. Правіла перанакіравання апісвае дасяжнасць слухача, а не дазвол для чаго-небудзь унутры.

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

Менавіта ўнутраная палітыка вызначае доступ

Шыфраванне абараняе шлях; яно не дазваляе прызначэнне. Маршруты кліента выбіраюць, якія прэфіксы трапляюць у тунель, палітыка перанакіравання шлюза вырашае, ці могуць пакеты пакінуць яго, а міжсеткавы экран пункта прызначэння разам з уваходам вырашаюць, ці адказвае служба. DNS — самы ясны выпадак: перадача запытаў не прымушае рэзалютар прымаць іх з вашага пула кліентаў. Кожны ўзровень можа незалежна сказаць не.

Праверце кожную службу асобна праз тунель. Паспяховы пошук нічога не кажа пра вэб-порт, а паспяховы вэб-запыт — пра SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

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

WireGuard праводзіць тую ж мяжу

WireGuard называе свайго знешняга слухача ListenPort і ўнутраная праграма ўсё яшчэ выкарыстоўвае любы патрэбны ёй порт службы. AllowedIPs — гэта набор маршрутызаваных прэфіксаў, а не спіс дазволеных портаў службаў. Чытанне яго як спісу дазволаў для портаў стварае правілы, якія не адпавядаюць таму, што робіць тунель. Назва іншая; раздзяленне па ўзроўнях — не.

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

Агульная форма — адзін знешні транспарт з мноствам унутраных размоў. Прадукты, якім патрэбны некалькі знешніх абменаў або іншы IP-пратакол, нагадваюць, што схема аднаго публічнага порта апісвае гэту канструкцыю, а не кожны VPN.