Зоны Shorewall для двух шляхоў пакетаў OpenVPN

Два патокі пакетаў перасякаюць шлюз Shorewall, які завяршае OpenVPN, і толькі адзін з іх зашыфраваны. Першы — гэта транспарт кліента да слухача VPN на інтэрфейсе, які глядзіць у інтэрнэт. Другі — расшыфраваны запыт, які выходзіць з інтэрфейса тунеля да офіснага сервера або паслугі на шлюзе. Пазначце абодва да рэдагавання палітыкі, бо правіла, якое задавальняе першы, нічога не робіць для другога.

Намалюйце два патокі да рэдагавання палітыкі

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

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

Прызначце зону тунеля і межы інтэрфейса

Зона вандроўнага карыстальніка аб’яўляецца ў /etc/shorewall/zones, інтэрфейс тунеля далучаецца ў /etc/shorewall/interfaces, а знешняе злучэнне апісваецца ў /etc/shorewall/tunnels. Падладзьцеся пад сінтаксіс усталяванага выпуску, бо парадак слупкоў і назвы параметраў змяніліся паміж асноўнымі версіямі. Прыкладны порт з даведніка не з’яўляецца падставай дазваляць іншы порт, чым той, на якім дэман фактычна слухае. TCP і UDP не ўзаемазаменныя толькі таму, што лікі супадаюць.

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

Гістарычны даведнік утрымлівае значна старэйшыя прыклады канфігурацыі OpenVPN, і яго крыптаграфічныя парады не варта капіяваць у бягучае разгортванне. Пазычце замест гэтага мадэль зон і патокаў. Крыптаграфічную аснову бярыце з падтрымліванай палітыкі OpenVPN на шлюзе.

Дазвольце толькі той шлях, які вы класіфікавалі

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

Трафік паміж кліентамі патрабуе ўласнага рашэння. client-to-client у OpenVPN і routeback у Shorewall абодва ўплываюць на тое, ці могуць кліенты дасягаць адзін аднаго, і ні адзін з іх не варта ўключаць толькі дзеля працы адной праграмы LAN. Вызначце, дзе ўводзіцца ізаляцыя, перш чым правяраць.

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

Праверце, затым дакажыце абодва шляхі

Праверце канфігурацыю перад любым перазапускам і трымайце незалежную адміністрацыйную сесію адкрытай на выпадак, калі новая палітыка памылковая.

shorewall check

Пасля чыстай праверкі ўжывеце канфігурацыю і прачытайце, што загрузіў Shorewall. Гэтыя чытанні апісваюць працуючую палітыку, а не тое, што нібыта гаворыць файл.

shorewall show zones
ip route get 192.168.10.20

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