Домашният тунел WireGuard се нуждае от обратен маршрут от LAN
Ръкостискането е лесната част. Решете разделението на работата между рутера и шлюза, запазете източника на лаптопа и дайте на LAN обратен маршрут.
Достъпът до дома е една частна услуга, а не втори изход към интернет. WireGuard завършва на Linux машина зад рутера, рутерът запазва досегашната си роля, а лаптопът изпраща през тунела само домашния префикс. Кое устройство препраща и кое завършва е решението, от което следва всяко следващо правило. Сгрешете ли това разделение, ще отстранявате проблеми в NAT, който не сте смятали да добавяте.
Решете кой препраща и кой завършва
Рутерът притежава публичния вход: той приема UDP пакета и го предава на Linux хоста. Този хост притежава слушателя на WireGuard и решението за препращане към LAN. На практика преобразуването изпраща UDP 51820 към 192.168.50.10, а собственият порт на приложението остава затворен. Разделението на ролите държи защитната стена кратка.
Напишете плана за адресите преди създаването на интерфейса. Рутер 192.168.50.1, шлюз 192.168.50.10, услуга 192.168.50.20, тунел 10.77.0.0/24 с шлюз .1 и лаптоп .2. Обхватът на тунела не бива да се припокрива с мрежа, до която лаптопът вече достига, иначе дестинациите стават двусмислени. Carrier-grade NAT или рутер по-нагоре може да блокира входящия достъп и никакво локално пренасочване на порт не поправя това.
Разменете ключове, после оразмерете AllowedIPs
Създайте отделена двойка ключове за всяка крайна точка и пренасяйте само публични ключове по проверен канал. Записът за партньор на шлюза допуска само източника на тунела на лаптопа, защото домашната LAN е зад шлюза, а не зад лаптопа. Да поставите LAN в този запис описва топология, която не сте изградили.
[Interface]
Address = 10.77.0.2/32
PrivateKey = LAPTOP_PRIVATE_KEY_BASE64
[Peer]
PublicKey = HOME_PUBLIC_KEY_BASE64
Endpoint = home-vpn.example.com:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32AllowedIPs е домашният префикс плюс адресът на тунела на шлюза, никога 0.0.0.0/0, така че обичайното сърфиране запазва локалния си път. Дръжте един собственик на конфигурацията и никога не свързвайте същия интерфейс към втори мрежов мениджър.
Обратният маршрут е частта, която хората пропускат
Този дизайн запазва източника 10.77.0.2 на лаптопа, вместо да го маскира като шлюза, затова домашните устройства трябва да знаят как да отговорят. Добавете статичен маршрут на домашния рутер за 10.77.0.0/24 с 192.168.50.10 като следващ хоп и прочетете какво извежда wg-quick от AllowedIPs в справката му. Без този маршрут завършено ръкостискане съществува заедно с отговори на приложението, които никога не пристигат.
Ако рутерът не може да носи този маршрут, изберете документиран обратен дизайн. Тихото добавяне на NAT вместо това променя модела на източника, който току-що записахте.
Разрешете една услуга, не подмрежата
Включете препращане на IPv4 на шлюза и дръжте три задължения на защитната стена отделно: допускане на слушателя на WireGuard, препращане на източника на лаптопа само към 192.168.50.20 и оставяне на останалата домашна мрежа затворена за този партньор. Вградете правилата във вече използвания мениджър на защитната стена, вместо да го изчиствате. Маршрут за целия домашен префикс не е разрешение да използвате всяко устройство вътре в него.
Собствената автентикация на приложението и защитната стена на хоста са отделна врата. Назовете услугата, която наборът правила разрешава, за да може следващият преглеждащ да я свери с предвидената задача.
Тествайте отвън, после изведете чисто
Вдигнете профилите през техния собственик, потвърдете ръкостискането, после упражнете предвиденото приложение от одобрена външна мрежа и проверете отговора. Опитайте домашна услуга, която трябва да остане забранена, защото разрешаващо правило е невидимо, докато нещо не го използва. За HTTPS използвайте името от сертификата и оставете валидацията да работи; въвеждането на суровия адрес и преминаването през предупреждението не доказва нищо за пътя. PersistentKeepalive е по избор: помага на партньор зад NAT след престой, но не е липсващ маршрут или поправка на разрешение.
Динамичният публичен адрес се нуждае от обновявания на DNS и лаптопът трябва да разреши отново крайната си точка след промяна; новите DNS записи не местят конфигурирана крайна точка. Изведете лаптопа, като премахнете партньора му от запазената и активната конфигурация; изтриването само на профила на лаптопа не отменя оторизацията на шлюза.