Ноутбугуңуз VPN аркылуу pfSense LAN'ына жетет, бирок дагы эки секирик тереңирээк жайгашкан кызматка жете албайт, ал эми айырмачылык — ар бир ээ үчүн бир маршруттоо чечими. Пакет өзүнүн барып-кайтуу сапарын бүтүрүү үчүн үч түзмөк макулдашуусу керек: клиент, брандмауэр жана максаттуу тармакка чындап ээлик кылган маршрутизатор. Алардын кайсынысын болбосун өткөрүп жиберсеңиз, белги бирдей көрүнөт.

Эрежени өзгөртүүдөн мурун бир пакетти ушул үч чечим аркылуу байкап чыгыңыз, анткени ар бир ээнин башкаруусу жана бузулуу режими башка.

Бир пакет, үч маршруттоо чечими

Клиент максат туннелге таандыкпы же жокпу чечет, жана ал өзү билген нерселердин негизинде гана чече алат: түртүлгөн маршрут, жергиликтүү маршрут же баарын камтыган демейки маршрут. pfSense пакетти кийин кайда жөнөтүүнү чечет, ал эми башка маршрутизатордун артындагы тармак үчүн бул туура интерфейстеги жеткиликтүү шлюз аркылуу статикалык маршрутту билдирет. Төмөнкү маршрутизатор VPN бассейнине кайра кайтуучу жолду билеби же жокпу чечет, эгер билбесе, жооп ташталат же пайдасыз жерге жөнөтүлөт. Ар бир чечим калган экөөнөн көз каранды эмес.

Алардын кайсынысынын бузулушу болбосун бирдей колдонуучу отчётун берет. Ошондуктан мүчүлүштүктү оңдоо тартиби куралдардан маанилүүрөөк.

Клиентке божомол эмес, префикс бериңиз

IPv4 туннелдик тармагы /30'дон чоң pfSense SSL/TLS серверинде IPv4 Local network(s) талаасы туташканда клиенттерге маршруттарды таратат. Клиент өзү ойлоп табат деп ишенүүнүн ордуна төмөнкү префиксти ошол жерге кошуңуз. Андан кийин туташкандан кийин клиенттин чыныгы таблицасын окуңуз, анткени route-nopull бар профиль же маршрут фильтри сервер жөнөткөндү этибарга албашы мүмкүн. Сервер толугу менен туура болушу мүмкүн, ал эми клиент эч нерсе орнотпойт.

Башка сервер режимдери жана топологиялардын чектөөлөрү башка, ал эми ар бир клиент же туташуу саясаты белгилүү бир клиенттин эмнени аларын өзгөртүшү мүмкүн. Биринчи кокустан текшерген клиентте эмес, маанилүү клиентте текшериңиз.

pfSense'ти ички маршрутизаторго багыттаңыз

pfSense'теги статикалык маршрутка аныкталган жана жеткиликтүү шлюз керек, ал эми ошол шлюз үчүн тандалган интерфейс ага чындап жетүүчү интерфейс болушу керек, муну Netgate'тин статикалык маршруттар боюнча колдонмосу сүрөттөйт. Иллюстративдик жайгашууда транзиттик байланыш брандмауэрде 192.168.77.1 жана ички маршрутизатордо 192.168.77.2, ал эми кызмат тармагы анын артында 172.16.30.0/25. Андан кийин маршрут префиксти жана кийинки секирикти атайт, кызмат дарегин эмес. Алыскы тармактан алынган даректи шлюз катары колдонуу — туура көрүнгөн жана эч жакка өткөрбөгөн маршрут куруунун кеңири таралган жолу.

Интерфейске ат берүү анын артындагы тармактарды сүрөттөбөйт. Статикалык маршрут — ошол сүрөттөмө.

Алыскы тарап бассейнди билиши керек

Төмөнкү маршрутизаторго бассейн үчүн кайтаруу маршруту керек, бул мисалда 192.168.77.1 аркылуу 10.55.0.0/24, эгер демейки маршрут же динамикалык протокол мурунтан камсыз кылбаса. Кызмат хостүнүн өз шлюзу ошол маршрутизаторго карай алып барышы керек, бул адатта маршрутизатор анын демейки шлюзу болгондо туура, ал эми хост кол менен конфигурацияланганда туура эмес. Брандмауэрдеги саясий маршруттоо да белгилүү трафик үчүн таблицаны кайра аныкташы мүмкүн, ошондуктан маршрут туура эмес деп жыйынтык чыгаруудан мурун эреженин башка шлюзду тандап жатканын текшериңиз.

Бул дизайн үчүн которуу талап кылынбайт, ал эми клиенттин булак дарегин көрүнүктүү кармоо төмөнкү тармакка өз саясатын колдонууга мүмкүндүк берет.

Кабыл алуу үчүн бир жаңы сурамды туннелдин кире бериши, брандмауэрдин ички чыгышы жана максаттан келген жооп аркылуу байкаңыз. Эгер анын ордуна которуу атайын колдонулса, төмөнкү тармак кайсы булакты көрөрүн жана жооп кантип кайтышы күтүлөрүн жазып алыңыз.

Үч ээнин планын уруксат берилген колдонмо менен бирге сактаңыз, ошентип кийинки администратор жолду кайра ачуунун ордуна аны кайра кура алат.

Тектеш макалалар