Ping кроз VPN: зашто правила за одговор еха промашују повратни пут

Пошаљите ping ка хосту кроз VPN и захтев излази са једним ICMP типом, а враћа се са другим, што је довољно да збуни свако правило написано у терминима портова. У размени еха нема сервисног порта одредишта који би се копирао у правило враћања, а филтер који очекује симетрију одбациће одговор док захтев пролази без препрека. Поправка почиње читањем пакета онаквим какав заиста јесте, а затим одлуком која граница на путу доноси одлуку. Обично раде два слоја, а трећи тихо одбацује одговор. Одељци испод их раздвајају по реду којим пакет наилази на њих.

Пакет мења тип, а не порт

Захтев еха је ICMP тип 8, код 0, и носи идентификатор и редни број. Одговор је тип 0, код 0, са истим идентификатором и редоследом, а IP крајеви су замењени. Ова поља дефинише RFC 792, и управо идентификатор омогућава пошиљаоцу да упари одговоре са својим захтевима.

Оно што недостаје једнако је важно: нема TCP или UDP заглавља, па нема ни порта који треба дозволити. Правило које именује порт за одговор еха описује пакет који никада неће постојати. Ово је најчешћа грешка у VPN ping тикетима. Правило изгледа конкретно, не примењује се ни на шта и оставља квар тачно тамо где је био.

Три контекста одлучују о пакету

Ако ping циља хост на удаљеном LAN-у, захтев мора да проследи гејтвеј. Ако циља адресу која припада самом гејтвеју, завршава у локалној улазној путањи. Ако гејтвеј сам покреће ping, пакет почиње у сопственој излазној путањи и уопште не прелази одлуку о прослеђивању.

Ова три контекста имају различите ланце правила и различите бројаче, и управо њихово третирање као једног је разлог зашто „заштитни зид дозвољава ICMP“ ипак може дати неуспешан ping. Спољни тунел је четврти контекст: дозвола VPN слушаоцу не дозвољава аутоматски декапсулирани унутрашњи захтев, а унутрашња дозвола не каже ништа о томе да ли је спољни тунел подигнут.

Филтери са стањем и без стања обрађују одговор различито

Заштитни зид са стањем који је видео да захтев излази може да повеже одговор са тим током и да га пропусти без другог правила. Филтер без стања нема такву меморију, зато повратни смер захтева сопствену изричиту дозволу, са замењеним извором и одредиштем.

Проверите који модел производ заиста примењује пре него што било шта напишете. Правило за захтев еха не мора нужно да покрива одговор еха, а производ који прати ICMP упите може ипак применити другу политику на одговоре који стижу на други интерфејс.

Ограничите оно што дозвољавате. Дозволити сваки одговор еха са било ког места није исто као довршити везу са стањем, а број типа не аутентификује пошиљаоца.

Превод мења и идентификатор

Ако је превод извора намеран, торка на удаљеном крају не одговара оној коју је послао клијент. NAT може да преведе идентификатор ICMP упита заједно са адресама, па инсистирање да се исти број појави на обе стране ствара лажно неслагање.

Уместо тога повежите се са мапирањем које пријављује преводилац. Преводилац који преписује идентификатор неће сачувати број који је ваш клијент забележио, зато третирајте мапирање као идентитет, а не број. Затим пратите један препознатљив захтев дуж путање: потврдите да стиже на одредиште са очекиваним извором, потврдите да је одредиште послало одговор, пратите путању тог одговора назад, и потврдите да га је клијент примио, уместо да само гледате како бројач гејтвеја расте.

Не спајајте ICMP грешке у политику еха

Порука „потребно је фрагментирање“ коју користи откривање MTU путање није одговор еха, а њен садржај цитира пакет који ју је изазвао. Дозвола само за ехо која тихо одбацује те грешке претвара проблем величине у висћу везу, што је супротно од корисног.

Иста пажња важи и за породице адреса. ICMPv6 користи друге типове порука и носи суштинске функције које IPv4 нема, зато је копирање ових бројева у IPv6 правило једноставно погрешно.

Када размена еха ради, тестирајте праву апликацију одвојено. Успешан ping доказује пут тамо и назад једног протокола, једне величине, до једног одредишта, и то није лиценца да претпоставите да су HTTPS, SMB или било који други ток дозвољени.