Бир 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ди эмес экенин эскертет.