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

Подобни статии