Большасць невялікіх сайтаў ужо мае адзін прыбор, які робіць інтэрнэт, DHCP і галасавую лінію, і гэты прыбор не будзе трымаць тунель сайта. Другі шлюз для прыватнага шляху працуе, калі вы загадзя вырашыце, каму належыць кожны маршрут, перш чым кранаць кабель. Сапраўдная рызыка не ў тунелі; яна ў тым, каб ціха змяніць прыладу, якая трымае тэлефоны зарэгістраванымі. Прайдзіце пяць праверак па парадку і спыніцеся там, дзе адна з іх не прайшла.

Запішыце ролі, якія ўжо працуюць

Зафіксуйце шлюз па змаўчанні, сервер DHCP, рэзалвер і прыладу, якая трымае галасавую рэгістрацыю правайдэра. У гэтым прыкладзе маршрутызатар ISP — 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

Калі пошук вяртае маршрутызатар ISP, а traceroute памірае на мяжы інтэрнэту, у хаста пакуль няма аддаленага шляху, і гэта чакана. Калі вяртаецца нешта нечаканае, спачатку разбярыцеся з гэтым, бо кожны наступны крок разлічвае на гэтую базу.

Выберыце, каму належыць маршрут аддаленага прэфікса

Варыянт A — маршрутызатар ISP: ён трымае статычны маршрут для 10.60.0.0/24 на шлюз, і кожны хост, як і раней, ідзе праз свой шлюз па змаўчанні. Варыянт B — па хастах: толькі машыны, якім патрэбны аддалены сайт, атрымліваюць явны маршрут праз 10.50.0.2, а ўсё астатняе застаецца непарушаным. A чысцейшы для многіх хастаў, але звычайна патрабуе, каб маршрутызатар правайдэра прымаў статычны маршрут, чаго некаторыя не робяць. B не патрабуе супрацоўніцтва правайдэра, але пакідае вам падтрымку канфігурацыі хастаў, таму падыходзіць для невялікага зацверджанага набору машын.

У любым выпадку зваротны кірунак мусіць існаваць. Калі аддалены адказ прыходзіць на шлюз, а шлюз перасылае яго наўпрост на хост LAN, трафік абыходзіць стан міжсеткавага экрана, які маршрутызатар ISP трымаў на шляху наперад. Калі шлюз не з’яўляецца маршрутызатарам па змаўчанні для 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

Замацуйце запіс праз уладальніка канфігурацыі хаста, а не праз скрыпт уваходу. Маршрут, які існуе толькі пасля чыйгосьці ўваходу, адмовіць пры першай перазагрузцы машыны з іншай прычыны.

Забяспечце дасягальны ўваходны пункт

Шлюзу патрэбны адрас, да якога можа дабрацца аддалены сайт. За маршрутызатарам ISP гэта азначае перанакіраванне порта або запіс 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

Затым пацвердзіце, што звычайны доступ да інтэрнэту з таго ж хаста працуе і тэлефоны ўсё яшчэ зарэгістраваны; гэтыя дзве праверкі ловяць выпадковую змену маршруту па змаўчанні, самы часты спосаб, якім гэты праект ламае тое, чаго не збіраўся кранаць. Завяршыце пісьмовай нататкай пра аднаўленне: якая прылада якую ролю трымае, зарэзерваваныя адрасы і як выдаліць маршрут аддаленага прэфікса адным крокам. Прыватны шлях, які можна чыста адклікаць, каштоўнейшы за той, што проста працуе сёння.

Падобныя артыкулы