Әрбір OpenVPN пиріне remote жолы қажет пе? Онша емес
remote бірінші пакеттің қайда кететінін көрсетеді; ол клиент, сервер немесе TLS рөлін таңдамайды. Оны екі жаққа көшірмес бұрын орналасуын оқыңыз.
Екі пир конфигурациясы қатар салыстырылады, бірінде remote жолы бар, екіншісінде жоқ, ал қорытынды — олардың бірі бұзылған. Бұл тұжырым талдауға тұрарлықтай жиі қате. Директива бірінші пакеттің қайда жіберілуі керегін сипаттайды. Ол процестің бастаушы клиент немесе күтуші шлюз ретінде әрекет ететінін таңдамайды және қай тарап өз идентификаторын екіншісіне дәлелдейтінін шешпейді.
remote шын мәнінде нені айқындайды
remote жазбасы хостты, қаласа порт пен транспортты, және қаласа кезекпен сыналатын бірнеше осындай жазбаны атайды.
Оның болмауы белгісіз емес, белгілі мағынаға ие: процесс күтеді және сол пир аутентификацияланбаса, қандай да бір мекенжайдан келген пакеттерге әрекет етпейді. Сондықтан кезбе пайдаланушыларға қызмет көрсететін шлюздің олардың ешқайсысын алдын ала атауға себебі жоқ.
Жазбаны мекенжай қатынасы ретінде оқыңыз. Алыс жақтың сенімділігіне сертификаттар мен тексеру параметрлері жауап береді, мекенжайдың жазылғаны емес.
Жауапты үш орналасу шешеді
Кезбе клиентке меже қажет, өйткені ол бастауы керек және онсыз шлюздің қайда екенін білмейді. Көпклиентті шлюзге пайдаланушы сайын меже қажет емес, өйткені клиенттер келіп, аутентификацияланады. Белгілі ұштары бар әдейі екі пирлі байланыстың бір жағында, екі жағында немесе ешбірінде межесі болуы мүмкін, қай тарап бастайтынына байланысты.
Тұрақты клиент мекенжайын жалпы шлюзге жапсыру — сол санаттарды елемеуден туындайтын қате. Ол мекенжайы жазылған жалғыз пир үшін жұмыс істейді және қалғандардың бәрін адастырады.
Директивада конфигурацияны көпклиентті серверге айналдыратын ештеңе жоқ, ал оның болуы сервер рөліне де кедергі жасамайды. OpenVPN 2.6 анықтамасы қалауынша аргументтерді және remote жоқ кездегі мінез-құлықты бөлек құжаттайды, бұл олардың қаншалықты тәуелсіз екеніне ишара.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
Транспорт рөлдері — басқа өс
TCP-де бір жақ күтеді, екіншісі қоңырау шалады. Бұлар межеден бөлек директивалар, ал оларды араластыру екеуі де күтетін немесе екеуі де қоңырау шалатын жұп туғызады.
TCP көз сүзгісінің рөлі де бар, сондықтан серверде ешқашан remote болмайды деген тегіс тұжырым қате.
UDP-де орнатылатын байланыс жоқ, сондықтан екі ұш та сәйкес UDP транспортын пайдаланады және директива тек қайда бағыттау керегін айтады. Аутентификацияланған пирдің мекенжай өзгерістерін қосымша жазбалар қосу емес, арнайы мінез-құлық өңдейді. Транспортты дұрыс орнату меженің мәнге ие болуының алғышарты, ал екеуін шатастыру сенімді көрінетін және қол алысуды ешқашан аяқтамайтын конфигурациялар туғызады.
Неге remote-дың болмауы ашық есік емес
Межесіз процесс те аутентификацияланбайтын пирлердің трафигін қабылдамайды, ал адамдар жоқ жолды бәріне ашық тыңдаушы деп оқығанда дәл осы бөлікті өткізіп жібереді.
Аутентификация мен меже тәуелсіз, ал сенім үшін біріншісі маңызды.
Кері қате қауіптірек. Тұрақты көз мекенжайы нақты әрі тексеруге оңай болғандықтан қатынас бақылауы сияқты сезілуі мүмкін, бірақ ол арғы жақта кім бар екені туралы ештеңе дәлелдемейді. Сертификат тексеруін және сертификатты оның рөліне байланыстыратын идентификатор тексерулерін сақтаңыз. Оларды мекенжай сәйкестігімен алмастыру нақты бақылауды оның көрінісіне айырбастайды.
Конфигурация нені болжайтынын жазыңыз
Әр тарап үшін үш нәрсені жазып алыңыз: бірінші пакет пирге қалай жетеді, қай тарап транспортты қабылдай алады және әр тарап екіншісі туралы нені тексереді.
Сол болжамдар — дизайн. Директивалар тек олардың жазылымы.
Егер екі файл өзгеше болса, біреуі қате деп болжаудың орнына олардың түрлі болжамдарды білдіріп жатқанын тексеріңіз. Симметриялы файл жұбы жұмыс істейтін туннель үшін қажет те емес, жеткілікті де емес, ал асимметрия көбіне топологияны жұмыс істететін бөлік.