VPN се свързва, но LAN устройствата са недостъпни: какво да проверите

Трафикът влиза в тунела, шлюзът отговаря на собствения си адрес, а нищо зад него не отговаря. Този модел е често срещан и не е противоречие: отговорът от шлюза доказва, че тунелът е приключил, и не доказва нищо за това какво се случва с пакет, адресиран отвъд него. Двата теста използват различни кодови пътища на една и съща машина.

Отсега нататък тествайте нещо от другата страна на шлюза. Собственият адрес на шлюза ще продължава да отговаря, колкото и счупено да е препращането.

Шлюзът отговаря от собствения си стек

Пакет, адресиран до шлюза, се доставя до локалния му входен път, където ядрото решава дали слушащ сокет ще го приеме. Пакет, адресиран до хост зад шлюза, вместо това се доставя до пътя за препращане, където важи различен набор от проверки. Препращането може да бъде напълно изключено или включено от ядрото и след това отхвърлено от правило за филтриране, което изобщо не споменава тунела. Нищо от това не засяга собствения отговор на шлюза, затова симптомът заблуждава толкова надеждно.

Административните страници, достигнати през тунела, също принадлежат към първата категория. Те са доказателство за тунела, а не за мрежата зад него.

Проследете потока до първата граница, която го отхвърля

Започнете от клиента и потвърдете маршрута и адреса на източника, които потокът ще използва. След това наблюдавайте шлюза за пристигането на точно този поток и отново за същия поток, който излиза към LAN. Ако той никога не пристига, проблемът е от страна на клиента или в разрешените префикси на тунела. Ако пристига и никога не излиза, проблемът е в препращането или в филтър на пътя напред, а записът вече е показал кой от двата е.

Изпълнението на същия тест от шлюза скрива интересната половина, защото пакетът, произхождащ от шлюза, има различен източник и различно изискване за връщане. Използвайте потока на клиента с неговия собствен адрес на източника за всяка стъпка. Запис, направен на грешния интерфейс, дава уверени глупости.

Обратните маршрути и хост-фаерволите се провалят поотделно

След като пакетът достигне хоста, трябва да са налице още три неща. Услугата трябва да слуша на адреса, на който е изпратен пакетът, хост-фаерволът трябва да го приеме и отговорът трябва да има маршрут обратно към пула от клиенти. Последното често се проваля, защото маршрутът по подразбиране на хоста сочи към рутер, който никога не е чувал за диапазона на тунела. Резултатът е връзка, която се установява от гледна точка на хоста и умира тихо в другата посока.

Тествайте пътя за връщане умишлено, като изпращате от клиента и наблюдавате връщането. Еднопосочен запис решава за секунди това, което час спекулации няма да реши.

Потвърдете всяка стъпка с адреса на източника на клиента

Изпълнете проверките по ред и запазете всеки изход, защото стойността е в сравнението, а не в който и да е отделен ред. Командите по-долу фиксират адреса на източника, показват избрания маршрут и записват двете страни на препращането. Заменете своя LAN хост и интерфейс на тунела.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Заявката за маршрут показва дали клиентът изобщо би изпратил този пакет в тунела, а ping показва дали нещо се е върнало от хоста. Сравняването на двата записа отделя пристигането от излизането, тъй като кадър на интерфейса на тунела без аналог на LAN интерфейса е решение за препращане, а не отказ на услуга. Когато и двата записа показват заявката, а само един показва отговора, оставащият заподозрян е обратният маршрут.

Запишете кой адрес е отговорил и коя препратена дестинация се е провалила. Това изречение прави доклада приложим, вместо твърдение, че сървърът е недостъпен.