Эмне үчүн LAN хост OpenVPN кардарынын дарегине ARP жөнөтөт

LAN хост менен VPN кардарынын ортосундагы жеткиликтүүлүк көйгөйлөрү көбүнчө дарек планына алып барат. Ал хостко 10.0.100.0/22 дарегинде интерфейс бериңиз, ал 10.0.100.0-дон 10.0.103.255-ке чейинки ар бир даректи түз туташкан деп эсептейт, анын ичинде 10.0.101.0/24 дарегинде тынч жайгашкан кардарлар пулун. Жооп эч качан маршрутизаторго барбайт, анткени хосттун көз карашы боюнча эч кандай маршрутизатор катышпайт. Пакет кошунага адрестелип, зым аркылуу суралат.

Бул механизм бүтүндөй билдирүүлөр үй-бүлөсүнүн артында турат: туннель иштеп турат, серверде маршрут бар, бирок LAN хост кардарга жете албайт.

/24тү жутуп алган /22

Префиксти диапазон катары окуңуз, сап катары эмес. /22 префиксинде 1024 дарек бар, ал эми 10.0.100.0/22 10.0.100.0-дон 10.0.103.255-ке чейин созулат, ошондуктан 10.0.101.0/24-төгү пул толугу менен ичинде жатат. Ката текшерүүдөн өтөт, анткени пулдун биринчи октеттери LANдын биринчи октеттеринен башкача көрүнөт жана үчүнчү октет гана ичкиликти ачып берет. Эки диапазонду тең сан менен жазып, анан аларды өзүнчө деп жарыялаңыз.

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

Түз байланыш ARP дегенди билдирет, маршруттоо эмес

/22 интерфейси бар хост 10.0.101.25-ке жөнөткөндө, өзөк барар жерди интерфейстин префикси менен салыштырып, дал келүүнү табат. Пакет маршрутталган пакеттин ордуна кошуна издөөгө айланат, ал эми Ethernetте кошуна издөө ошол дарекке ARP суроо болуп саналат. Эгер дарек маршрутталган дарбазанын артындагы VPN кардарына таандык болсо, LANдагы эч бир хост ага ээлик кылбайт, ошондуктан суроо жоопсуз калат жана пакеттер ташталат. Туннель күнөөлүү эмес, жана кардар трафикти эч качан көрбөйт.

Ошондуктан бузулуу асимметриялуу жана кээде үзгүлтүктүү көрүнөт. VPN хосту көбүнчө LANга жетет, анткени анын өз маршруттары туура тарапты көрсөтөт, ал эми LAN хост жооп бере албайт, эски ARP жазуусун кэштегендин баары симптомду жаркылдатат.

TUN, TAP жана ар бири эмнени ташыйт

TUN түзмөгү IP пакеттерин, TAP түзмөгү Ethernet алкактарын ташыйт. Маршрутталган TUN байланышы IP жеткиликтүүлүгүн камсыз кылуу үчүн ARP ташууга милдеттүү эмес, ошондуктан жогорудагы жоопсуз суроо күтүлгөн нерсе, бузулуу эмес. TAP атайын көпүрө менен broadcast доменин кеңейтип, ARPды иштете алат, бирок кардар эмнени көрө аларын өзгөртөт, ошол эле алкактоону колдогон четки чекиттерди талап кылат жана капталган префикс үчүн оңдоо эмес, тармак моделин кайра долбоорлоо болуп саналат. Дарек план боюнча катаны айыктыруу үчүн маршрутталган жайылтууну TAPка которуу кичине көйгөйдү чоңуна алмаштырат.

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

Кайчылашпай турган пул долбоорлоңуз

Ар бир туташкан префикстен жана ар бир жарыяланган сайт префиксинен тышкары пул тандап, анан аны эки тарапка тең жеткиликтүү кылган маршруттарды кошуңуз. Пландын колдонулбаган бөлүгүндөгү 10.8.0.0/24 сыяктуу диапазонду ойлонуу жеңил, ал эми ага жетиши керек LAN VPN серверине багытталган статикалык маршрут алат. Бөлүштүрүүнү, жарыяланган маршруттарды, уруксат берилген булак даректерин жана брандмауэр эрежелерин чогуу өзгөртүңүз, анткени алар төрт жөндөө эмес, бир долбоорду сүрөттөйт.

Сервердеги Source NAT пулду LANдан маршрутталуучу даректин артына жашыра алат жана бул мыйзамдуу миграция куралы. Ал булакты да кайра жазат, ошондуктан LAN байланыштарды жеке кардарларга таандык кылуу жана кардар боюнча эрежелерди колдонуу мүмкүнчүлүгүн жоготот.

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