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 или кој било друг тек е дозволен.