Эмне үчүн сиздин LAN VPN кардардагы кызматка жете албайт
VPN кардары LAN ача албаган кызматты жайгаштыра алат. Көбүнчө жетишпегени кайтаруу жолу: бир маршрут, DNAT түгэйи же эч ким кошпогон SNAT сабы.
Туннелиңиз көтөрүлгөн, кызмат угуп жатат, ал эми кеңсе LAN’ы дагы эле эч нерсе кайтарып албайт. Эч ким VPN’ди бузган жок. LAN тарабынан ноутбуктун туннель дареги, бирөө LAN’га ага кантип жетүүнү айтмайынча, жок, жана жооп суроо чыккан жол менен кайтышы керек. Мен адамдардын кайтаруу жолуна эч ким карабай туруп, толук соо туннелди үч жолу кайра куруп чыкканын көрдүм.
Булган туннель эмес
Эки учу тең жеке диапазондордо отурат, бул кадимки абал, туура эмес конфигурация эмес. 10.8.0.6 сыяктуу дарек туннелдин ичинде чыныгы жана башка жерде жок, ошондуктан LAN’дын ал жакка бир нерсе жөнөтүүгө себеби жок. Маршруттоого тийүүдөн мурун кызматтын туннелдин ичинде жалпы жеткиликтүү экенин ырастаңыз: кардарда ss -ltn угуучунун 127.0.0.1, LAN интерфейсине же туннель дарегине байланганын көрсөтөт. Бир гана loopback’ке байланган демон өзүнөн башка эч кимге жооп бербейт, жана аны эч бир маршрут, DNAT же портту кайра багыттоо өзгөртпөйт.
80 же 443 портундагы прокси — башка көрүнүүгө ээ башка курал. Ал пакеттерди эмес, суроолорду жылдырат, ошондуктан чийки маалымат базасынын туташуусу үчүн туура эмес катмар, жана ага кайрылуу — бул маселенин бирөө бир нерсени өлчөөдөн мурун үч курал тереңдигине жетүү жолу.
Маршруттун формасы: LAN’га бассейндин кайда экенин айтыңыз
LAN шлюзиндеги статикалык маршрут — LAN менен туннель бассейни кабатташпаганда эң таза жооп. Бассейнди туннелди бүтүргөн машинага багыттаңыз:
ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12 # Windows, persistent
Бул бир гана багытты оңдойт, ошондуктан бул өзгөртүүнүн жарым-жартылай версиялары прогресс сыяктуу көрүнөт. Туннелдин тарабына да тиешелүү жарымы керек, болбосо жооп кардарды өзүнүн демейки маршруту менен таштап, жолдо өлөт:
push "route 192.168.1.0 255.255.255.0"
Сервердин артында эмес, бир кардардын артында турган субнет үчүн серверге системалык маршрут да, ошол кардардын файлындагы iroute жазуусу (client-config-dir астында) да керек. iroute жок болсо, OpenVPN префикс бар экенин билет, бирок аны кайсы кардар ээлегенин билбейт: пакеттер келет, ал эми демондун аларды дал келтире турган эч нерсеси жок.
Мына ат коюуга татыктуу уламыш. Маршрут даректи жеткиликтүү кылат; ал каршы тарапты жооп берүүгө даяр кылбайт. Сайттан сайтка өнөктөштөр үстүнө дагы бир катмар кошот, анткени алыскы шлюз өз саясатында тизилген префикстердин ичиндеги булактарды гана кабыл алат, ал эми үй бассейнинен келген ноутбук алардын ичинде эмес.
NAT’тын формасы: ичке DNAT, жана баары өткөрүп жиберген SNAT сабы
LAN шлюзине тийе албаганда же так бир портту жарыялагыңыз келгенде, VPN хостундагы котормо LAN’да эч кандай маршрутсуз иштейт. Портту жарыялаңыз, аны кайра багыттаңыз, жана булакты туннелге кирген жолдо которуңуз:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1
Үчүнчү сап — жоголуучу сап. Аны өткөрүп жиберсеңиз, кардар баштапкы LAN дарегин булак катары көрөт, өзүнүн демейки маршруту менен жооп берет, жана бул жооп LAN’га кайтуунун ордуна туннелге кетет. Байланыш тирүү калабы, ал сиз эч качан пландабаган маршруттоого байланыштуу болот. SNAT менен кардар сервердин туннель дарегин көрөт, ошондуктан жооп туннел менен кайра котормону жокко чыгара алган жалгыз хостко чейин барат.
Керектөөчү firmware өзүнүн чынжыр аттарын колдонот жана бул котормону сиз үчүн жаратпайт. Tomato’до кирүү эрежеси WANPREROUTING ичине, андан кийин wanin сыяктуу чыпка чынжырына түшөт, жана толук көрүнгөн эрежелер жыйындысы дагы эле кол менен жазылган POSTROUTING сабын талап кылат. Бул firmware катасы эмес; бул кирүү трафиги үчүн гана жазылган эрежелер жыйындысы.
Эмне үчүн туура көрүнгөн эреже пакетти баары бир таштайт
Бул ийгиликсиздиктердин көбү сиз карап турган эрежеде эмес. Ушул тартипте төрт нерсени текшериңиз, жана аткарылбаган биринчисинде токтоңуз:
- Чынжырлардын тартиби.
iptables -Iжогору жагына киргизет, ал эми-Aаягына кошот, ошондуктан мурунку уруксат берүүчү же блоктоочу эреже биринчи чечет. - Туура эмес чынжыр. Роутердин өзүнө адрестелген трафик INPUT аркылуу өтөт, ал эми кайра багытталган трафик ага эч качан тийбейт. Бир кызматты жарыялоо экөөндө тең эрежелерди талап кылышы мүмкүн.
- Багыт желеги.
-i tun0кардарлардан келген трафикке дал келет, ал эми-o tun0аларга карай кеткен трафикке. Туура эмес желеги бар REJECT сиз ойлобогон нерсени бөгөттөйт. - Булак чектөөсү. Бир кардардын дарегин кабыл алган кайра багыттоо ошол кардардан иштейт жана калган бардык булактарды бир сөз айтпастан таштайт.
Пакет эсептегичи нөл болгон эреже жолдо такыр жок, жана эсептегичтерди окуу туура эмес чынжыр маселесин туура эмес эреже маселесинен ажыратуунун эң тез жолу.
Жергиликтүү кайра багыттоо, LAN’да эч нерсени өзгөртүүгө мүмкүн болбогондо
SSH жергиликтүү кайра багыттоосу бүткүл суроону айланып өтөт. Ага LAN’да маршрут да, кардардын firewall’унун кызматташтыгы да, бир жерде жарыяланган порт да керек эмес:
ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host
Андан кийин кызмат туннелди кармап турган машинанын localhost:3000 дарегинде пайда болот, жана бөтөн жерде эмес. Бул — чек: бир жумуш станциясы, бир порт, жана бир нерсе аны кайра иштетпесе, кайра багыттоо сессия менен өлөт. Сыноо маалымат базасын текшерген администратор үчүн бул туура курал. Башка адамдар жетиши керек болгон камера же сканер үчүн андай эмес, анткени ар бир колдонуучуга өзүнүн кайра багыттоосу керек болмок.
Дагы бир эреже кошуудан мурун эки багытты тең текшериңиз
Котормо из калтырат, жана аларды окуу божомолдоодон артык. VPN хостто conntrack -L котормонун жалпы болгонун, iptables -t nat -L -n -v эсептегичтердин жылганын, ал эми tcpdump -ni any port 3000 кайсы булак дареги чындап келгенин көрсөтөт. Кардарда ss -ltn угуучунун туннель жете алган даректе экенин ырастайт.
Андан кийин сактай турган формаңызды тандаңыз. Бир жарыяланган порт, бүткүл бассейн үчүн маршрут жана бир администратор үчүн кайра багыттоо — бул үч башка милдеттенме, жана аларды аралаштыруу иштеп жаткан конфигурацияны алты айдан кийин эч ким түшүндүрө албай турган конфигурацияга айландыруучу жол. Кайсы дарек кайдан жеткиликтүү экенин жазып коюңуз, жана муну оңдой турган кийинки адам туннелден эмес, жооптон баштайт.