Један јавни домаћин за 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 трећу.

Изворни 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 мреже. Са једним партнером искљученим, пинг преко чворишта треба да падне; када се поново повеже, пинг треба да се врати без дирања правила. Пинг који се враћа само после поновног покретања тунела показује на политику, а не на достижност, и то је друга поправка.

Држите скуп правила читљивим док одузимате улоге. nft list ruleset треба да покаже једно правило прихватања по смеру који вам је заиста потребан, а ланац прослеђивања који прихвата све није раздвајање, то је радна демонстрација.

Приступне линије само са IPv6 и услуге на IPv4

Неке приступне линије дају само IPv6 достижност, а услуге ипак морају да се објављују преко IPv4. Сам тунел путује кроз породицу која још пропушта саобраћај, док објављена услуга седи на адреси унутар тунела. То преокреће уобичајену претпоставку и тихо квари надзор: правило ватрозида или провера радног времена написана за IPv4 пут сада надгледа интерфејс који ништа не носи.

Тестирајте сваку породицу засебно са curl -4 и curl -6, јер један успешан захтев не говори ништа о путу који нисте пробали. Власништво над портом се не мења међу породицама, али слушалац се мења: ss -lntup наводи IPv4 и IPv6 сокете у одвојеним редовима, а 0.0.0.0:443 не покрива [::]:443, осим ако процес није затражио dual-stack сокет.

Услуга која одговара на једној породици и одбија на другој обично је проблем слушаоца, а не рутирања. Пре него што дизајн прогласите готовим, потврдите да свака улога има своју адресу или порт, да је прослеђивање укључено и дозвољено и да свака улога још одговара док су друге две заустављене.