Еден јавен домаќин за 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. Со еден партнер исклучен, ping преку концентраторот треба да падне; со повторно поврзување, ping-от треба да се врати без допирање на правило. Ping што се враќа само по рестартирање на тунелот покажува на политика, а не на достапност, и тоа е поинаква поправка.

Држете го множеството правила читливо додека одземате улоги. nft list ruleset треба да покаже едно правило за прифаќање по насока што навистина ви треба, а синџирот за препраќање што прифаќа сѐ не е одделување, тоа е работна демонстрација.

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

Некои пристапни линии даваат само IPv6 достапност, а услугите сѐ уште мораат да се објавуваат преку IPv4. Самиот тунел патува по семејството што сѐ уште пропушта сообраќај, додека објавената услуга седи на адреса внатре во тунелот. Тоа ја превртува вообичаената претпоставка и тивко го крши следењето: правило на огнен ѕид или проверка на времето на работа напишана за IPv4 патеката сега надгледува интерфејс што не носи ништо.

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

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