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га ээ интерфейстин конфигурациясына таандык, сиз жаба турган shellге эмес.

Экинчи буйруктун жообун текшериңиз. Эгерде ал кардарды 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 кайра жөнөтүүнү далилдейт, шифрлөөнү эмес: сырткы жол өзүнчө байкоо, жана туннелдин өз интерфейс эсептегичтери гана андан эмне чыкканын көрсөтөт.