Бир OpenVPN кардарындагы эки кызмат дареги: iroute жана lo

Колдонмо өзүнүн туннель дарегинде жооп берет, ал эми ага документтештирилген дарек эч жакка барбайт. OpenVPN журналында эч нерсе нааразы болбойт, теңтуш туташкан болуп көрүнөт жана хаб так бир кардарды тизмелейт. Кемчилик — кардардагы экинчи дарек эки өзүнчө факт: хост ага ээ болушу керек, ал эми хаб кайсы теңтуш ээ экенин билиши керек. Бирөөнү экинчисинсиз чечсеңиз, трафик же хабда өлөт, же үйгө кайтуу жолусуз келет.

Ылакап ат жергиликтүү, ээлик алыс

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

Кардарда дарек хостко таандык, ал эми loopback — физикалык байланышта эч качан көрүнбөшү керек болгон кызмат идентификаторунун табигый үйү. Хабда теңтушту префикске салыштыруу — сервер гана окуган өзүнчө декларация. Эки жазуунун бири да экинчисин билдирбейт.

Эки диапазонду жазууларыңызда да бөлүк кармаңыз. Мисалдагы даректер документтик маанилер, ал эми аларды реалдуу LAN менен кабаттоо — иштеп жаткан конфигурацияны бузулган кылып көрсөтүүнүн эң тез жолу.

Даректи кардарга туруктуу түрдө кошуңуз

Кызмат дарегин хост префикси менен loopbackке коюңуз, хост аны жетүү керек болгон ички тармак катары эмес, жергиликтүү кирүү катары карасын. ip address add 10.66.0.10/32 dev lo муну бир дарек үчүн жасайт, ал эми экинчи дарек үчүн буйрукту кайталоо эки кызматты моделдейт.

Муну бир жолку тест катары иштетиңиз, анан хосттун тармактык конфигурациясына ээ болгон нерсеге көчүрүңүз, анткени иштөө учурундагы кошумча кайра жүктөөдө жоголот жана кайра туташуулардын ортосунда көчүрмөлөр топтолот. Тармактан кийин иреттелген systemd бирдиги — бир вариант, ал эми бөлүштүрүүнүн тармак менеджери — экинчиси. Кайсынысын тандасаңыз да, дарек колдонмо туташканга чейин болушу керек, болбосо кызмат туура эмес сокетте чыгат. Кол менен буйруктан кийин эмес, кайра жүктөөдөн кийин ip address show dev lo аркылуу текшериңиз.

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

Аны хаб чындыгында окуган CCD файлында талап кылыңыз

Серверде ээлик декларациясы аутентификацияланган жалпы ат менен тандалган ар кардар файлына кирет, client-config-dir атаган каталогдун ичинде. Сап — iroute 10.66.0.10 255.255.255.255, ар дарекке бир, жана ал серверге кайсы теңтуш ошол багыт боюнча трафик алышы керектигин айтат.

Эки деталь муну үнсүз бузат. Файлдын аты сервер чындыгында колдонгон атка дал келиши керек, ал username-as-common-name оюнда болгондо башкача болот. Ал эми iroute клиент конфигурациясынын каталогу конфигурацияланган TUN режиминде гана күчүнө кирет, ошондуктан ошол эле сап көпүрөлүү жайгаштырууда эч нерсе кылбайт. Саптарды бар файлга кошуңуз, аны алмаштырбаңыз, анткени анда мурунтан туруктуу дарек же push опциялары болушу мүмкүн. OpenVPN 2.6 маалыматнаамасы каталогду да, ээлик директивасын да документтештирет.

Хабдын өзөгүнө да ошол багыттарга жол керек, жергиликтүү түзүлгөн трафик туннель процессине кирсин. Сервер конфигурациясындагы route 10.66.0.10 255.255.255.255 сервер өзү жараткан трафикти камтыйт, ал эми башка кардарлар багытты өздөрү үйрөнүү үчүн push "route 10.66.0.10 255.255.255.255" керек.

Маршруттоо жана авторизация өзүнчө калат. Жөнөтүлгөн маршрут кардарга пакеттерди кайда жөнөтүүнү айтат жана эч нерсе бербейт; кызмат чакыруучуну өз шарттары менен кабыл алышы керек.

Кирүү саясатын жана жооп жолун текшериңиз

Ылакап атка адресделген пакет ээ хостко жергиликтүү кирүү катары жетет, ошондуктан суроо — жергиликтүү файрвол ошол булак менен портко уруксат береби. Бүт даректи ачуунун ордуна VPN булак диапазонунан конкреттүү кызмат портуна уруксат бериңиз.

Жоопторго чакыруучуга кайтуучу жол керек. Кадимки туннель пулунун ичиндеги чакыруучу үчүн бул жол мурунтан бар, анткени аны туннель түзмөгү алып жүрөт. Башка маршрутталган тармактын артындагы чакыруучуга ошол тармактын кайтуу маршруту да керек, жана дал ушул жерде асимметриялык конфигурациялар пакеттерди жоготот.

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

Даректерди жана ээликти өзүнчө текшериңиз

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

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