Една NIC или две? Одредување на распоредот на интерфејси на VPN сервер

Еден физички адаптер е доволен за многу VPN сервери, а тоа не е ни универзално решение. Шифрираната врска пристигнува на тој адаптер, VPN процесот ја дешифрира, потоа внатрешниот сообраќај излегува низ виртуелен интерфејс, пред да стигне до локална услуга или рутирана LAN. Дали тоа ќе работи зависи од три услови: каде се наоѓа дестинацијата, дали LAN има повратен пат до базенот на клиенти и дали една заедничка физичка врска ви дава изолацијата што ја тврдите. Одговорете на тие три и бројот на адаптери следи.

Трите услови што го одредуваат тоа

Првиот услов е дестинацијата. До услуга на самиот VPN хост се стигнува само преку тунелскиот интерфејс, додека хостот на LAN бара проследување и повратен пат. Вториот услов е тој повратен пат, бидејќи LAN уредот мора да знае како да го достигне базенот на клиенти, или преку рута или преку превод на серверот.

Третиот услов е одвојувањето. Еден адаптер значи дека секој пакет, шифриран или не, дели една врска и обично еден синџир на правила, па тврдењето за изолација што зависи од посебен хардвер не се задоволува со еден интерфејс. Тоа е факт за патеката, а не за тоа како е конфигуриран оперативниот систем. Се уште можете да го филтрирате сообраќајот на тунелот, но не можете да тврдите граница што ја немате.

Ниту еден од трите не е за бројот на порти на куќиштето. Тие се за рутирање, сопственост на адреси и колку проектот зависи од физичко одвојување.

Два адаптери остануваат легитимен избор кога физички зони, посебни uplink врски, пропусност или патека за опоравување надвор од опсегот го оправдуваат. Тоа се конкретни барања и вреди да се наведат пред некој да нарача хардвер.

Кога услугата работи на VPN хостот

Најпростиот случај не бара проследување воопшто. Демонот ги прима пакетите на клиентот на тунелскиот интерфејс и ги предава на локален сокет, а одговорот се враќа по истиот интерфејс. За хостот, адресата на базенот на клиенти е вистинска локална адреса.

Две работи сепак мора да бидат точни: услугата мора да слуша на адреса што тунелот може да ја достигне, а огнениот ѕид на хостот мора да го прифати сообраќајот што пристигнува на тунелскиот интерфејс. Двете се гледаат во командите подолу.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Врзувањето на услугата само на јавната адреса или погрешно филтрирање на тунелскиот интерфејс создава врска што стигнува до хостот и потоа умира. Тоа изгледа како дефект на VPN и обично е одлука за сокет или огнен ѕид.

Кога дестинацијата е на LAN

Тука дизајнот со еден адаптер го добива гласот дека е незгоден. Серверот мора да ги проследи пакетите на клиентот кон LAN, а LAN уредот мора да ги врати одговорите во базенот на клиенти. Или тој базен го носите како рута на LAN, или ја преведувате изворната адреса на серверот за одговорите да се вратат на самиот сервер.

Двата одговора се легитимни и пропаѓаат различно. Повратната рута ја остава оригиналната адреса на клиентот видлива за дестинацијата, што е добро за дневниците и лошо за правилата на огнениот ѕид што претпоставуваат LAN адреси. Преводот го остава LAN едноставен и ја крие идентитетот на клиентот од дестинацијата.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Асиметричната патека е класичен симптом: барањето на клиентот пристигнува, одговорот излегува низ друг рутер, а врската истекува без грешка на двата краја. Снимете сообраќај на двете страни пред да заклучите нешто за тунелот.

Зошто alias не создава втора зона

Додавањето втора адреса на истиот адаптер или создавањето dummy интерфејс што имитира втора порта менува многу малку. Пакетите сепак излегуваат низ истата физичка врска, истата порта на комутаторот и обично истиот синџир на огнен ѕид, па меѓу нив не настанува нова граница. Тоа е практичност на конфигурацијата, не сегментација. Третирањето како граница на зона е начинот на кој тврдењето за изолација опстојува само на хартија.

Посебна зона бара вистинско одвојување на патеката, а тоа е барањето што го задоволува вториот адаптер. Ако правило зависи од тоа сообраќајот кон VPN никогаш да не дели broadcast домен со сообраќајот кон LAN, еден кабел не може да го даде тоа својство, како и да е адресиран хостот.

Каде производ документира топологија со повеќе интерфејси за одреден режим, следете ја документацијата на тој производ наместо да измислувате заобиколно решение. Производителите исто така ги менуваат поддржаните топологии меѓу изданијата, што е уште една причина да го читате тековниот водич, а не слика од стар волшебник.

Проверете го распоредот спрема сообраќајот што го дозволувате

Наведете ги класите сообраќај што серверот треба да ги носи: клиент кон хост, клиент кон LAN, хост кон LAN и шифрираната надворешна врска. Секоја класа има извор, дестинација и интерфејс, а распоредот мора да ги задоволи сите четири одеднаш. Дизајн што обработува три од нив обично е тој што создава тикети.

Потоа потврдете ги вистинските интерфејси и вистинското снимање, а не дијаграмот во проектниот документ. Командите подолу ги печатат двата погледи.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Ако надворешното снимање го покажува шифрираниот сообраќај, а внатрешното го покажува дешифрираниот сообраќај на тунелскиот интерфејс, додека физичкиот адаптер ги носи двете, една NIC ја работи работата. Ако внатрешното снимање е празно, проблемот е во тунелот или во правилата за проследување, а не во бројот на адаптери. Одредете ја топологијата од тие две снимки и табелата за рутирање, и следната промена ќе има со што да се спореди.