Бир NIC же экиби? VPN серверинин интерфейстер жайгашуусун чечүү

Көптөгөн VPN серверлери үчүн бир физикалык адаптер жетиштүү, жана бул универсалдуу чечим да эмес. Шифрленген байланыш ошол адаптерге келет, VPN процесси аны шифрден чечет, андан кийин ички трафик виртуалдык интерфейс аркылуу чыгат, жергиликтүү кызматка же маршрутталган LANга жетээрден мурун. Бул иштейби, үч шартка көз каранды: багыттоо кайда жайгашкан, LANдын кардарлар пулуна кайтуу жолу барбы, жана бир жалпы физикалык байланыш сиз билдирген обочолонууну береби. Ушул үчөөнө жооп бериңиз, адаптерлердин саны өзү чыгат.

Муну чечкен үч шарт

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

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

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

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

Кызмат VPN хостунда иштегенде

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

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

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

Багыттоо LANда болгондо

Ушул жерде бир адаптерлүү долбоор татаал деген атакка ээ болот. Сервер кардардын пакеттерин LANга карай кайра багыттоосу керек, ал эми LAN түзмөгү жоопторду кардарлар пулуна кайра жиберүүсү керек. Же ошол пулду LANда маршрут катары алып жүрөсүз, же серверде баштапкы даректи которуп, жооптор сервердин өзүнө кайтат.

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

Эмне үчүн alias экинчи зонаны түзбөйт

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

Өзүнчө зона жолдо чыныгы бөлүүнү талап кылат, ал эми бул талапты экинчи адаптер канааттандырат. Эгер эреже VPNге караган трафиктин LANга караган трафик менен эч качан broadcast доменин бөлүшпөшүнө көз каранды болсо, хост кантип даректелсе да бир кабель бул касиетти бере албайт.

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

Жайгашууну уруксат берген трафигиңиз менен текшериңиз

Сервер ташыышы керек болгон трафик класстарын тизмектеңиз: кардардан хостко, кардардан LANга, хосттон LANга жана шифрленген тышкы байланыш. Ар бир класстын булагы, багыттоосу жана интерфейси бар, ал эми жайгашуу төртөөнү тең бир убакта канааттандырышы керек. Үчөөнү иштеп чыккан долбоор адатта билет жараткан долбоор.

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

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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