Један OpenVPN порт, три услуге: зашто су унутрашњи портови важни

Један тунел, три услуге, један јавни порт. Одвојте спољни VPN слушалац од унутрашњих портова апликација, затим тестирајте сваку унутрашњу дозволу појединачно.

Једна 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.

Повезани чланци