Един публичен хост за VPN и уеб: как да разделим ролите

Една машина може да отговори и на трите нужди наведнъж: да прекратява тунели, да отговаря по HTTPS и да препраща между две частни LAN мрежи. Дали това е разумно зависи от три неща, които можете да решите на хартия: кой притежава публичния адрес, кой притежава всяка двойка порт и протокол и кой процес има право да препраща пакети. Направете ги правилно и споделеният хост е нищо особено. Направете ги грешно и ще прекарате уикенд върху услуга, която стартира чисто и никога не отговаря.

Следващото е процедура за решение, а не инструкция за изграждане. Всяка стъпка завършва с проверка, която доказва, че ролята, която току-що добавихте, е наистина изолирана.

Изберете собственика на адреса преди портовете

Крайна точка на тунел и уеб сървър могат да споделят едно ядро; споделянето на един адрес, порт и протокол едновременно е това, което се проваля. WireGuard обикновено заема UDP 51820, OpenVPN заема UDP 1194 или TCP 443, а уеб сървърът заема TCP 443. Болезнената двойка е OpenVPN през TCP 443 до HTTPS, защото и двете искат един и същ сокет и ядрото го дава на този, който се е свързал пръв. Само демултиплексор отпред, като sslh или прокси, което разбира TLS, им позволява да споделят този порт, и той добавя компонент, чиято повреда изглежда точно като проблем със защитна стена.

Погледнете собствениците, преди да промените нещо: ss -lntup показва локалния адрес, порта и процеса за всеки слушащ сокет. Два реда с 0.0.0.0:443 означават, че втората услуга така и не се е свързала, колкото и весел да беше init скриптът ѝ. Мостът също мести собственика. Когато eth0 се присъедини към br0, IP адресът се мести на br0 и всяко правило на защитната стена, което споменава eth0 спира да съвпада, затова закачете услугите на моста и потвърдете с ip -br addr.

Същото правило за собственост обяснява изненада, която се появява при виртуалните машини. Сървър на тунел, който работи в гост в същата LAN, запазва адреса на госта, така че връзките към собствения адрес на хоста остават на хоста и тунелът на госта никога не ги вижда, каквото и да предполага клиентският профил.

Маршрутизиране между двете LAN мрежи или NAT на едната страна

Две LAN мрежи, които не се виждат, могат всяка да се свърже с публичния хост, който след това препраща между тунелите. Този маршрутизиран дизайн изисква три неща: включено препращане, маршрут към всеки отдалечен префикс и политика за препращане, която пропуска транзита. sysctl -w net.ipv4.ip_forward=1 покрива първото, ip route add 10.20.0.0/24 dev wg1 второто, а ред на nftables като nft add rule inet filter forward iifname "wg0" oifname "wg1" accept третото.

Source NAT е по-лесен за добавяне и по-труден за отстраняване на грешки. Маскирането пренаписва адреса на клиента, така че далечната страна вижда хъба, а не истинския хост, и правилата и логовете ѝ за достъп спират да бъдат полезни за установяване на произход. Когато и двете мрежи са ваши, маршрутизирайте. Когато едната страна принадлежи на трета страна, която няма да добави обратен маршрут, NAT е вариантът, който може да се достави тази седмица. Във всеки случай запишете плана на адресите, защото два припокриващи се /24 не могат да бъдат маршрутизирани с никакво количество конфигурация.

Нищо в ролята на интернет изход за лаптоп не пречи на същата кутия да прекратява входящи тунели. Само припокриващите се адреси го правят, затова планът на адресите е документът, който има значение.

Тествайте разделянето, докато две роли са спрени

Полезният тест е изваждане: спрете две роли и потвърдете, че третата все още отговаря. Уеб заявка трябва да завърши със спряна услуга на тунела, а ръкостискането на тунела трябва да завърши със спрян уеб сървър. Ако и двете работят само когато всичко работи, имате случайна зависимост: споделена таблица на защитна стена, заблуден маршрут или име, сочещо към грешен адрес.

Три команди правят този тест конкретен. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ доказва, че локалният слушател отговаря без външен DNS, wg show на клиента доказва, че ръкостискането е завършило, а tcpdump -ni any port 51820 на хъба отделя проблем с маршрутизацията от проблем с ключа. Ръкостискане, което никога не се появява в записа, е умряло преди хоста: защитна стена на доставчика, грешен публичен адрес или правило за NAT по пътя.

Повторете изваждането за препращаните LAN мрежи. С един изключен партньор ping през хъба трябва да се провали; с включен отново ping трябва да се възстанови, без да се пипа правило. Ping, който се възстановява само след рестартиране на тунела, сочи към политика, а не към достижимост, и това е различно поправяне.

Пазете набора от правила четим, докато изваждате роли. nft list ruleset трябва да показва едно правило за приемане на посока, която наистина ви е нужна, а верига forward, която приема всичко, не е разделяне, а работещо демо.

Линии за достъп само с IPv6 и услуги по IPv4

Някои линии за достъп дават достъпност само по IPv6, а услугите все още трябва да се публикуват по IPv4. Самият тунел пътува по семейството, което все още пропуска трафик, докато публикуваната услуга стои на адрес вътре в тунела. Това обръща обичайното предположение и тихо чупи мониторинга: правило на защитната стена или проверка за uptime, написани за пътя по IPv4, сега наблюдават интерфейс, който не носи нищо.

Тествайте всяко семейство поотделно с curl -4 и curl -6, защото една успешна заявка не казва нищо за пътя, който не сте опитали. Собствеността на портовете не се променя между семействата, но слушателят се променя: ss -lntup показва сокетите на IPv4 и IPv6 като отделни редове, а 0.0.0.0:443 не покрива [::]:443, освен ако процесът не е поискал сокет с двоен стек.

Услуга, която отговаря на едно семейство и отказва на другото, обикновено е проблем на слушателя, а не на маршрутизацията. Преди да обявите дизайна за готов, потвърдете, че всяка роля притежава своя адрес или порт, че препращането е включено и разрешено и че всяка роля все още отговаря, докато другите две са спрени.