Споделете една VPN връзка с всяко устройство в LAN

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

Защо насочването на устройства към хоста се проваля

Хост, който получи пакет, адресиран до отдалечена мрежа, за този момент става рутер, независимо дали някой го е конфигурирал като такъв. Препращането е изключено по подразбиране на Linux и на Windows, освен ако функция не го включи. Транслацията е важна, защото отдалечената страна трябва да знае къде да изпраща отговорите, а частен адрес в LAN не значи нищо за нея. Обратният маршрут е третата част и именно него хората забравят, когато първият ping изглежда успешен.

Диагностицирайте в този ред, вместо да превключвате настройки наслуки. Всяка липсваща част дава малко по-различен симптом.

Включете препращане и транслация на хоста

Две промени на свързания хост покриват първите две части: включете препращане на IPv4 и транслирайте LAN трафика към интерфейса на тунела.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Запазете стойността на sysctl във файл под /etc/sysctl.d и проверете отново правилото MASQUERADE след рестарт, тъй като интерфейсите на защитната стена могат да изчистят персонализирани вериги. В Windows функцията за споделяне изпълнява и двете стъпки, но също така преназначава LAN адаптера на фиксирана подмрежа и изчиства шлюза му, което чупи статичното адресиране и препращането на портове. Възстановете пътя на рутера към хоста на новия му адрес, преди да заключите, че споделянето се е провалило. След това наблюдавайте как броячите на правилата растат, докато второ устройство изпраща трафик.

Дайте на LAN път, който оцелява след рестарти

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

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

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

Следете MTU, преди да обвинявате тунела

Тунелите намаляват използваемия размер на пакета и второто устройство не подозира. Големите трансфери и TLS ръкостисканията засичат, докато малките заявки успяват.

ping -M do -s 1400 10.8.0.5

Отговорът доказва, че този размер преминава пътя без фрагментация; таймаут означава, че натоварването от инкапсулация е избутало пакета отвъд MTU на тунела. Намалете MTU на интерфейса за споделяне или ограничете максималния размер на сегмента на препращащия, след което повторете същата проверка. Тествайте същия размер от страната на LAN първо, защото локалният провал сочи към LAN, а не към тунела. Запишете работещия размер, тъй като по-късна промяна на доставчика или тунела може да го измести.

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