Добавете VPN за сайта до рутера на доставчика, без да прекъсвате разговорите

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

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

Запишете ролите, които вече работят

Отбележете шлюза по подразбиране, DHCP сървъра, резолвера и устройството, което държи гласовата регистрация на доставчика. Тук рутерът на доставчика е 10.50.0.1, новият шлюз ще е 10.50.0.2, а отдалеченият сайт е 10.60.0.0/24. Нищо в този план не променя първите три роли и точно това е смисълът. После потвърдете, че второто устройство наистина може да терминира нужния тунел: проверете протокола, очакваната пропускателна способност и дали получава фърмуерни или пакетни обновления. Устройство с лого на VPN и без път за обновяване е тежест, не добавка.

Ако не можете да кажете кой притежава гласовата услуга, спрете. Смяна на рутера с регистрация без план за връщане назад превръща VPN проекта в телефонна авария.

Дайте на новия шлюз един адрес и една задача

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

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Ако търсенето връща рутера на доставчика и traceroute умира на интернет границата, хостът още няма отдалечен път, което е очаквано. Ако върне нещо неочаквано, решете го първо, защото всяка следваща стъпка предполага тази база.

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

Вариант A е рутерът на доставчика: той държи статичен маршрут за 10.60.0.0/24 към шлюза и всеки хост следва шлюза си по подразбиране както преди. Вариант B е по хост: само машините, които имат нужда от отдалечения сайт, получават явен маршрут през 10.50.0.2, а всичко останало остава недокоснато. A е по-чист при много хостове, но обикновено изисква рутерът на доставчика да приеме статичен маршрут, което някои не правят. B не иска съдействие от доставчика, но оставя поддръжката на хост конфигурацията у вас, затова пасва на малък одобрен набор машини.

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

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

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

Осигурете достъпна входяща точка

Шлюзът има нужда от адрес, до който отдалеченият сайт да стигне. Зад рутера на доставчика това означава пренасочване на порт или запис в DMZ и двете зависят от това доставчикът наистина да предава трафика. Локално пренасочване не побеждава NAT от операторски клас от страна на доставчика. Ако доставчикът не даде достъпна точка, обърнете посоката: нека двата сайта инициират към концентратор, който контролирате. Това е валиден дизайн, но добавя трета зависимост за пренасочване, доверие и наличност, а динамичният DNS не го замества.

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

Приемете частната услуга и гласовата линия заедно

Тествайте предвидената работа от LAN хост, с частен DNS и собствените идентификационни данни на приложението. Маршрутизиран тунел не прави отдалеченото сърфиране да изглежда като локален Ethernet сегмент, затова откриването и разрешаването на имена искат свои уредби.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

После потвърдете, че обикновеният интернет достъп от същия хост работи и телефоните са още регистрирани; тези две проверки хващат случайна промяна на маршрута по подразбиране, най-честият начин този проект да счупи нещо, което не е възнамерявал да пипа. Завършете с писмена бележка за възстановяване: кое устройство коя роля държи, резервираните адреси и как да премахнете маршрута към отдалечения префикс с една стъпка. Частен път, който може да се оттегли чисто, струва повече от такъв, който просто работи днес.

Подобни статии