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 интерфејсу је одлука о прослеђивању, а не квар сервиса. Када оба снимка показују захтев, а само један одговор, повратна рута је преостали осумњичени.

Запишите која адреса је одговорила и која прослеђена дестинација није успела. Та реченица чини извештај применљивим уместо тврдње да је сервер недоступан.