VPN і хатняя LAN у адной падсетцы: спачатку прайдзіце па маршруце
Абодва адаптары прэтэндуюць на 192.168.1.0/24, і перамагае адзін маршрут. Прайдзіце спіс адаптараў, маршрут-пераможца і зваротны шлях, перш чым перанумераваць або вінаваціць DNS.
Вы падключаецеся да офіснай VPN, значок у лотку становіцца зялёным, інтранэт загружаецца, і прынтар за два метры перастае адказваць. Агульны рэсурс, які працаваў раніцай, сканчаецца па тайм-ауту на той жа машыне, і ні ў адным журнале не згадваецца прынтар. Першая рэакцыя — DNS, бо імя, якое не развязалася, выглядае як імя, якога не існуе, але праблема ў адрасе: два адаптары цяпер прэтэндуюць на 192.168.1.0/24, і толькі адзін маршрут можа перамагчы гэты прэфікс. Прайдзіце гэта ў такім парадку, і вы ўбачыце, які адаптар забраў яго, перш чым нешта змяняць.
Пачніце з сімптому, а не з тунеля
Падказка — у аб'ёме. Калі інтранэт працуе, а ўсе лакальныя прылады не, тунель здаровы, а лакальны шлях не. Калі лакальныя прылады працуюць, а інтранэт не, наадварот. Калі ўсё працуе, акрамя аднаго хоста, вы бачыце адзін адрас, які існуе з абодвух бакоў.
Запішыце адзін лакальны адрас і адзін аддалены, перш чым кранаць наладку. «Прынтар» нельга праверыць; 192.168.1.40 можна. Гэты адзіны крок прадухіляе самую частую страчаную гадзіну ў гэтай праблеме — перапісванне наладаў DNS дзеля рашэння аб маршруце.
Крок 1: паглядзіце на абодва адаптары, якія прэтэндуюць на прэфікс
Адкрыйце «Сеткавыя злучэнні» (ncpa.cpl) і паглядзіце на абодва адаптары побач. Адаптар Ethernet паказвае 192.168.1.50/24 з шлюзам 192.168.1.1. Адаптар VPN паказвае 192.168.1.201/24, прасунуты серверам. Абодва легітымныя, абодва лічаць прэфікс on-link, і стэк будзе трымаць для яго адзін маршрут.
Get-NetIPAddress -AddressFamily IPv4 пералічвае адрасы, а Get-NetIPInterface | Sort-Object InterfaceMetric паказвае парадак, у якім стэк будзе іх выкарыстоўваць. Гэты слупок метрыкі — і ёсць рашэнне, якое вы зараз прачытаеце, таму запішыце лікі, а не спрабуйце іх запомніць.
Дакажыце, што тэорыя DNS памылковая, танна: Resolve-DnsName printer.office.lan вяртае той жа адрас, што і ўчора. Імя развязалася; пакет затым пайшоў праз няправільны адаптар. Дзве хвіліны тут эканомяць паўдня ў наладах рэзалвера.
Крок 2: прачытайце маршрут, які сапраўды перамог
Find-NetRoute -RemoteIPAddress 192.168.1.40 друкуе інтэрфейс, наступны крок і крыніцу, якія стэк выкарыстаў бы для гэтага адраса. Успрымайце гэты вывад як адказ, а не як падказку. route print -4 дае ўсю табліцу, калі вы хочаце ўбачыць, які запіс прайграў і на колькі.
Канкрэтнасць перамагае намер. Прасунуты 192.168.0.0/25 перамагае лакальны 192.168.0.0/24, бо прэфікс даўжэйшы, таму 192.168.0.0 да 192.168.0.127 выходзяць праз тунель, а верхняя палова застаецца лакальнай. Знікненне паловы LAN без паведамлення пра памылку — слушныя паводзіны для такой табліцы.
tracert -d 192.168.1.40 пацвярджае гэта з-за межаў табліцы: калі першы крок — адрас тунеля, а не ваш уласны роўтар, то маршрут і ёсць уся гісторыя. У Linux тое ж пытанне — ip route get 192.168.1.40, які друкуе адрас крыніцы і прыладу ў адным радку. Калі ў адказе згадваецца tun0, перастаньце глядзець на браўзер.
Крок 3: праверце зваротны шлях, перш чым вінаваціць кліента
Правільны прамы маршрут усё роўна не спрацуе, калі далёкі бок не можа адказаць. Калі LAN кліента дасягаецца праз тунель, шлюз гэтай LAN павінен ведаць, дзе жыве пул тунеля: ip route add 10.8.0.0/24 via 192.168.1.12 на гэтым роўтары, і push «route 192.168.1.0 255.255.255.0» з сервера, каб кліенты ведалі зваротны шлях.
Без першага запісу адказ пакідае цэль да свайго шлюза па змаўчанні, які перадае прыватны адрас правайдэру і скідае яго. Сімптом аднабаковы і лёгка чытаецца няправільна: запыты з'яўляюцца на tun0, адказы — ніколі.
Правіла masquerade на хосце VPN прыбірае патрэбу ў гэтым статычным маршруце: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Яно таксама хавае сапраўдныя адрасы крыніц, што робіць кожнае наступнае пытанне па журналах цяжэйшым. Хост-цэль з няправільным шлюзам па змаўчанні дае такую ж цішыню: у лепшым выпадку — ICMP-перанакіраванне, у звычайным — чорная дзірка, таму здымак належыць рабіць з абодвух бакоў.
Крок 4: абярыце рамант, з якім можна жыць
Для гэтага выкарыстоўваюць пяць рамонтаў, і яны не ўзаемазаменныя. Выбірайце па тым, што павінна заставацца дасягальным адначасова, а не па тым, якая каманда карацейшая.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Метрыкі — танны варыянт, да якога людзі цягнуцца першым. Змена датычыцца інтэрфейса, таму працуе, пакуль тунель узняты, і ёй месца ў скрыпце побач з кліентам, а не ў абалонцы, якую вы забудзеце. Яна не можа даць адначасовы доступ да аднаго адраса ў дзвюх сетках, і менавіта гэтае абмежаванне адпраўляе ўсіх астатніх уніз па табліцы.
Перанумераванне хатняй LAN у 10.10.0.0/24 — чыстае рашэнне: адно прадаўжэнне арэнды DHCP плюс рэзерваванні, чэргі прынтара і жорстка зашытыя адрасы, якія згадваюць стары дыяпазон. Перанумераваць бок офіса звычайна не ваша рашэнне. IPv6 цалкам прыбірае калізію, калі яе нясуць абедзве сеткі, выкарыстоўваючы ўнікальны лакальны прэфікс з fd00::/8 замест чаго-небудзь запамінальнага, але правярайце праграму праз TCP, а не ping, бо ICMP можа працаваць, пакуль служба — не.
Уласная опцыя перакладу OpenVPN — апошні сродак, яна прасоўваецца з сервера ў запіс каталога, спецыфічны для кліента. Пасля назвы опцыі ідуць чатыры параметры — напрамак, сетка, маска і псеўданім — і псеўданім не абавязковы: push "route 192.168.2.0 255.255.255.0" і push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Сетка і маска — гэта дыяпазон, які бачыць кліент (192.168.2.0/24), псеўданім — сапраўдны офісны дыяпазон на баку сервера (192.168.1.0/24), а прасунуты маршрут робіць гэты бачны дыяпазон дасягальным. Тады офіс паказваецца гэтаму кліенту пад 192.168.2.x. Задакументуйце адпаведнасць у профілі, інакш наступны чалавек будзе адладжваць яе як памылку маршрутызацыі.
Публікацыя адной службы — вузкая версія перакладу, і яна зусім не патрабуе опцыі OpenVPN. Правіла DNAT на хосце VPN перавыдае адзін порт, таму LAN захоўвае свае адрасы і дасягае службы па адрасе хоста, які ўжо ведае. Кошт звычайны: служба бачыць хост VPN як крыніцу, таму журналы па кожным кліенце і зваротныя запыты страчваюць сэнс. Гэта пакрывае адну чаргу прынтара ці адну адмін-старонку, а не хасты з абодвух бакоў, што дасягаюць адзін аднаго.
Што ўсё яшчэ не будзе працаваць, і што запісаць
Шыранне (broadcast) не перасякае маршрутызаваны тунель. DLNA, UPnP, агляд NetBIOS і Wake-on-LAN залежаць ад шырання ці multicast, якія прылада tun не нясе, таму ніякі маршрут не выправіць выяўленне. Маставанне праз dev tap пашырае сегмент, а з ім — шыранне DHCP, ARP і кожны іншы пакет выяўлення; аддайце перавагу unicast-маршруту да хоста, напрыклад route 192.168.2.1 255.255.255.255, для адраса з боку LAN аддаленага роўтара.
Два роўтары, якія абодва выкарыстоўваюць 192.168.1.1 на адным шляху, належаць да адной сям'і праблем: лакальны адрас заўсёды перамагае, таму старонка далёкага роўтара застаецца недасягальнай, пакуль адна LAN не пераедзе. Даданне другога адаптара нічога не мяняе ні ў адным выпадку.
Запішыце доказы, перш чым нешта рэдагаваць: ip route get або Find-NetRoute, ping -c 3 да патрэбнага адраса, traceroute, і tcpdump -ni tun0 icmp на кліенце, затым табліцу маршрутызацыі і лічыльнікі NAT на серверы. Ping, які працуе ў адзін бок і памірае ў іншы, паказвае на зваротны шлях, а не на тунель, і менавіта гэтае адрозненне вырашае, які з рамонтаў вышэй вам сапраўды патрэбны.