Маршрутызатар LAN плюс кліент VPN: дзве прылады, дзве табліцы маршрутаў

Дзве прылады перасылаюць пакет, і кожная трымае сваю табліцу. Маршрутызатар LAN ведае, што аддалены прэфікс належыць кліенту VPN, а кліент VPN ведае, як дасягнуць гэтага прэфікса праз свой тунель. Наладзьце толькі першую табліцу, і пакет прыбудзе на машыну без адпаведнага маршруту, таму ён зноў выйдзе па маршруце па змаўчанні. Гэта і ёсць увесь збой, і з боку LAN ён выглядае як пятля маршрутызацыі, бо амаль ёю і з’яўляецца.

Намалюйце два крокі, перш чым кранаць маршрут

Вазьміце ілюстратыўную схему: вузлы LAN на 192.168.50.0/24, звычайны маршрутызатар на 192.168.50.1, выдзелены кліент на 192.168.50.15 і аддаленая сетка LAN на 10.60.0.0/24, дасяжная толькі праз тунель, які трымае гэты кліент. Ні адзін з прыватных дыяпазонаў не перакрывае другі, і ў тунеля свой план адрасоў.

Абодва прыватныя дыяпазоны важныя, бо яны вызначаюць, якая прылада можа адказаць. Аддалены бок убачыць, што пакет прыйшоў з адраса тунеля кліента, і яго адказ павінен знайсці шлях назад да 192.168.50.0/24. Калі наладжаны толькі зыходны кірунак, запыт можа спрацаваць, а адказ знікне.

Крок 1: накіруйце маршрутызатар на кліента, а не на тунель

На маршрутызатары LAN дадайце маршрут прызначэння, наступны крок якога — адрас LAN кліента:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

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

Праверце адказ другой каманды. Калі яна паведамляе кліента як gateway, а інтэрфейс LAN як device, першы крок правільны, і астатняя праца — на другой машыне.

Крок 2: дайце кліенту ўласны маршрут з боку тунеля

Цяпер кліент атрымлівае пакет для 10.60.0.0/24 і звяраецца са сваёй табліцай. Калі яго канфігурацыя тунеля ўсталявала маршрут для гэтага прэфікса, пакет працягвае ісці ў зашыфраваным выглядзе. Калі не, пакет адпавядае звычайнаму маршруту па змаўчанні і вяртаецца да 192.168.50.1, які зноў адпраўляе яго кліенту.

Паглядзіце, перш чым нешта дадаваць:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Адсутнасць маршруту прэфікса ва ўсіх табліцах — гэта тое, што вы шукаеце. Дадайце яго праз уласную канфігурацыю тунеля, каб наступнае перападлучэнне зноў яго ўсталявала; ручная каманда ip route add знікае разам з сеансам і вяртае збой у самы нязручны момант. Наступны крок — гэта інтэрфейс тунеля або адрас, які VPN прызначае як свайго партнёра, у залежнасці ад кліента, і адрас партнёра павінен брацца з бягучага профілю, а не са старой нататкі.

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

Крок 3: дазвольце перасылку і выберыце зваротны шлях

Атрыманне і перасылка — розныя дазволы. net.ipv4.ip_forward=1 на кліенце дазваляе транзіт на ўзроўні ядра, але правіла файрвола ўсё яшчэ павінна дазволіць яго паміж інтэрфейсам LAN і тунелем. Правіла, якое дазваляе доступ да ўласнай старонкі кіравання кліента, не дазволіць транзіт да аддаленай LAN, і гэтую розніцу лёгка прапусціць, калі той жа хост адказвае на ping лакальна.

У аддаленага боку люстраная праблема. Ён павінен ведаць, што 192.168.50.0/24 дасяжная праз гэтага аўтэнтыфікаванага кліента. З OpenVPN гэта звычайна азначае маршрут для кожнага кліента, які штурхае канфігурацыя сервера, або кліенцкі файл на серверы, які абвяшчае LAN за кліентам. Без яго аддаленая LAN або адкідвае адказ, або адпраўляе яго на свой шлюз па змаўчанні, гэта значыць у інтэрнэт.

Трансляцыя крыніцы — гэта альтэрнатыва, калі прэфікс LAN немагчыма абвясціць. Абмежаванае правіла masquerade на кліенце перапісвае крыніцу на адрас тунеля, і адказы тады вяртаюцца натуральна. Яно таксама хавае, які вузол LAN зрабіў запыт, і само па сабе не дазваляе аддаленаму боку ініцыяваць злучэнні ўнутр. Выбірайце гэты кампраміс свядома, а не дадавайце суцэльны masquerade і выяўляйце пабочны эфект пазней.

Крок 4: замацуйце абодва рашэнні, затым праверце рэальны шлях

Кожны маршрут мае ўладальніка, і ўладальнік — гэта канфігурацыя, якая аднаўляецца пры загрузцы або пры перападлучэнні. На маршрутызатары гэта можа быць запіс статычнага маршруту; на кліенце — профіль VPN, NetworkManager або systemd-networkd. Праверце, перападлучыўшы тунель і перазагрузіўшы кліента, затым прачытайце табліцу зноў, а не давярайце правадцы.

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

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