Сайт-сайт VPN жауабы туннельден өтпейді
Туннельді айналып өтетін жауап — алыс жақтағы маршруттау шешімі. Хост кестесін, селекторларды және rp_filter-ті тексеріп, содан кейін маршрут немесе NAT таңдаңыз.
Бір таңды туннельге арнадым: ол таза көтеріліп, трафикті дәл бір бағытта ғана тасымалдады — филиал бас кеңседегі файл серверіне жететін, ал бас кеңседен филиалға ашылатын әрбір қосылым бірінші SYN-де өлетін. SA-лар көтерілген, туннель санауыштары өсіп жатқан, ал қол алысу ешқашан мәселе болмаған. Жауап туннель қамтымайтын жерге маршрутталып жатқан, ал бұл таңдау алыс жаққа тиесілі. Сайт-сайт VPN тек хост қақпаға тапсыратын пакеттерді тасымалдайды, және әрбір хост бұл таңдауды бөлек, әр бағытта, өз маршруттау кестесінен жасайды.
Екі бағыт бөлек маршрутталады
IP сөйлесу бағыты туралы ешқандай естелік сақтамайды. Пакет жіберетін әрбір хост өзінің ең ұзын префикс іздеуін орындайды, бір келесі секірісті таңдайды және шешімді ұмытады. Сұрау мен жауап — бір қосылысқа кездейсоқ тиесілі екі байланыссыз пакет, ал туннель — екеуінің де пайдалануы немесе пайдаланбауы мүмкін бір секіріс. IKE алмасуында ешнәрсе алыс серверге сіздің ішкі желіңізге қалай жетуді үйретпейді; келіссөз тек қандай префикстерді шифрлауға болатыны туралы ғана келіседі.
Бұл келісім — екінші қақпа. strongSwan-да трафик селекторлары — leftsubnet және rightsubnet, ал бастауы немесе межелі жері келісілген жұптан тыс қалатын пакет шифрланбайды, маршруттау кестесі не десе де. Туннельге маршрутталып, бірақ селекторларда жоқ префикс — тыныш бірбағытты ақау: маршрут дұрыс көрінеді, пакет бәрібір ашық шығады немесе тасталады, және тек charon журналы шағымданады.
Алыс хост сіздің туннеліңіз туралы ештеңе білмейді
Алыс жергілікті желі ішінде жауап — сіздің клиентіңізге арналған қарапайым пакет. Межелі хост ешқандай IPsec тақырыбын көрмейді және VPN қақпасын таңдауға себебі жоқ; ол сіздің префиксіңізді іздейді, әдепкі маршрутынан нақтырақ ештеңе таппайды да, соған жүреді. Егер әдепкі негізгі файрволға сілтесе, файрволдың туннельге қайта оралатын маршруты бар немесе жоқ. Жоқ болса, сіз тыныш тастау, ICMP unreachable немесе интернетке қараған интерфейстен шығып өлетін жауап аласыз.
Маршрут бар болса да, екінші интерфейс мұны бұзуға жеткілікті. Басқа VLAN-да басқару байланысы бар NAS, қосалқы uplink-і бар сервер, бір бастау ауқымын екінші кестеге жіберетін саясат ережесі: осылардың кез келгені жауапты ұстап ала алады. Linux-те ip rule show және ip route show table all әдепкі тізім жасыратын ережелер мен кестелерді көрсетеді.
Шешімді жауап жіберетін машинадан оқыңыз
Бірдеңені өзгерту алдында ядродан сұраңыз және оған бастау мекенжайын беріңіз, өйткені бастауға тәуелді ережелер жауапты өзгертеді.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"Шығыс шығатын интерфейсті және келесі секірісті атайды. Егер интерфейс VPN қақпасына қараған интерфейс болмаса, ақауды таптыңыз, ал қалған жұмыс — маршрут қайда болуы керектігін таңдау. Қақпадан жасалған ping мұнда азды дәлелдейді: ол алыс хост орналастыра алатын мекенжаймен жауап береді, ноутбукіңіздің мекенжайымен емес.
Windows-та баламалар — шешім үшін Find-NetRoute -RemoteIPAddress 10.10.5.10 және кесте үшін Get-NetRoute. Әдепкіден жоғары метрика алып жүретін New-NetRoute арқылы қосылған маршрут тыныш ұтылады, сондықтан метрика бағанын оқыңыз, жазбаны емес. Сосын пакеттермен растаңыз: алыс LAN интерфейсінде tcpdump -ni any "host 10.10.5.10 and tcp port 445" сұрауды көрсетеді, ал туннель жағындағы сол сүзгі жауап қайтты ма, жоқ па соны көрсетеді. Сұрау көрінеді, жауап жоқ — жауап басқа жерге маршрутталған немесе тасталған; дұрыс емес интерфейстегі жауап маршрутқа тимес бұрын кінәліні береді.
Сервер қақпасы VPN шеткі нүктесі болмағанда
Көп сайт серверлер мен шоғырландырғыш арасына файрвол қояды. Ол файрвол жауапты жібереді, сондықтан оған клиентіңіздің префиксі үшін VPN қақпасына бағытталған маршрут және екі бағытта да жіберу саясаты қажет. Күй сақтайтын құрылғылар жағдайды нашарлатады: сұрау файрволдан ол рұқсат еткен LAN хосттан өтті, жауап енді басқа бағыттан келеді, ал қосылымды бақылау жазбасы енді сәйкес келмейді, сол себепті пакет қабылданбай, жарамсыз деп тасталады. Саясат журналы бос көрінгенімен трафик жоғалып кетуінің себебі осы.
Қақпаның өзінің екінші сүзгісі бар. Linux-тегі кері жол сүзгісі бастауы өздері келген интерфейс арқылы қолжетімсіз пакеттерді тастайды, ал бұл заңды асимметриялық қайтару жолының дәл пішіні. strongSwan-ның жіберу нұсқаулығы дәл сол себептен net.ipv4.ip_forward және жеңілдетілген net.ipv4.conf.all.rp_filter талап етеді. Екі қақпаның кез келгеніндегі қатаң 1 мәні дұрыс маршрутты тыныш бұзады, және қайда қарауды білсеңіз nstat -az тастауларды көрсетеді.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Маршруттаңыз немесе аударыңыз, сосын екі бағытта тексеріңіз
Екі жөндеу тең емес. Маршрут қосу клиент мекенжайын бүлінбей сақтайды, сондықтан бастауға негізделген ережелер, аудит журналдары және қоңырау шалушыны жазатын қолданбалар жұмысын жалғастырады; бағасы — шешім қабылдайтын әрбір секіріске маршрут керек, яғни қателесетін орын көбірек. Алыс қақпада маскарадтау қайтару жолын бір секіріске жинайды, өйткені жауап енді қақпаның өзіне арналған, және қай клиенттің не істегенін жасырады.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEОны әдейі таңдаңыз: клиенттер қақпа мекенжайы ретінде көріне бастағанда, бастауға негізделген ACL-дар оларды ажыратуды тоқтатады, ал жауап туннельге қайта жазылуы үшін conntrack салыстыруды ұстауы керек. Егер селекторлар клиент префиксін әлі де шығарып тастаса, NAT ештеңені өзгертпейді, өйткені сұрау туннельге ешқашан кірмеген.
Оны түзетілді деп айтпас бұрын төрт нәрсені ретімен растаңыз: жауап жіберетін хосттағы маршрут, оны жіберетін әрбір секірістегі маршрут, екі префиксті қамтитын селекторлар және жауаптың күткен бастауыңызбен туннельге кіретінін көрсететін жазба. Сосын сынақты екінші сайттан қайталаңыз. Бір бағыттың өтуі — жартылай ашық жоба, ал екінші бағыт әдетте дәл жөндегеніңізден басқа себеппен сәтсіз болады.