Hairpin NAT: VPN акыркы чекити эмне үчүн ичтен иштебейт

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

Пакет сыртка чыгып, кайра кирет

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

Эми кардар эч качан эч нерсе жибербеген даректен пакет алат жана аны таштайт. Ушул асимметрия — бүткүл бузулуу.

RFC 4787 ушул учурда NAT-тан күтүлгөн жүрүм-турумду сүрөттөйт, жана кыска версиясы — бул теорияда белгиленген жерде дагы практикада милдеттүү эмес. Кээ бир маршрутизатор бул параметрди NAT loopback деп атайт, башкалары hairpin NAT же NAT reflection дейт, ал эми кээ бирөөлөр эч нерсе көрсөтпөйт. Бул функциясы жок маршрутизатор туура эмес конфигурацияланган эмес; ал кадимки ишти аткарып жатат, ал эми оңдоо башка жерге таандык. Жергиликтүү тест ишке ашпаганына карап коомдук багыттоо эрежеси туура эмес деп чечпеңиз.

Текшерүү 1: эки жолду өз-өзүнчө текшериңиз

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

Так жергиликтүү тест хост атын сактап, дарегин гана алмаштырат: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ сурамды коомдук дарекке жиберет, ошол эле учурда туура сервер атын көрсөтөт. Бул атты чечүү маселесин которуу маселесинен ажыратат, ал эми алар бир ат кафеде иштегенде оңой алмашат. Кардар TCP туташуусундабы же кийинчерээк TLS-теби ишке ашпай калабы, белгилеңиз, анткени биринчиси которууга, экинчиси инсандыкка көрсөтөт.

Текшерүү 2: сервер эмнени көрөрүн окуңуз

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

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

Текшерүү 3: сырткы жолго тийбей оңдоңуз

Үч колдоого алынган форма бар, таасир радиусунун өсүү тартибинде. Эң тар — бөлүнгөн DNS: ички жазууну жарыялаңыз, ошол эле сервер аты LAN-дагы кардарлар үчүн ички дарекке чечилсин, бул коомдук жолду толук айланып өтөт. Кийинкиси — маршрутизатордун документтелген loopback же reflection опциясын күйгүзүү, эгер ал бар болсо, жана аны ушул кызматка гана колдонуу. Эң кенен — маршрутизатордогу source-NAT эрежеси, ал LAN-дан келген трафикти серверге кайра жазат, ошондо жооп маршрутизатор аркылуу кайтат; Linux маршрутизаторунда бул сервердин дарегине жана портуна туура келүүчү MASQUERADE эрежеси POSTROUTING ичинде болот. Үчөө тең сырткы жолду тийбеген бойдон калтырат, жана сакталышы керек касиет — ушул.

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

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

Текшерүү 4: кийин эки жолду тең текшериңиз

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

Жазууну кыска кармаңыз: кайсы кардар кайсы даректи колдонду, сервер эмнени көрдү жана үч оңдоонун кайсынысы колдонулду. RFC 4787деги hairpinning талаптары бул жерде NAT-тан күтүлгөн нерсенин шилтемеси, жана бул функциясыз маршрутизатор эмне үчүн кадимкидей жүрүм-турум кылганын түшүндүрөт. Сырткы дүйнө кайталай албаган жергиликтүү ийгиликсиздик — тескериси далилденмейинче которуу маселеси, ошондуктан аны ошондой текшериңиз.