Пінг праз VPN: чаму правілы адказу на рэха не бачаць зваротнага шляху

Пінгванне хоста праз VPN: запыт сыходзіць з адным тыпам ICMP і вяртаецца з іншым, і гэтага дастаткова, каб заблытаць любое правіла, напісанае ў тэрмінах партоў. У абмене рэха няма порта службы прызначэння, які можна было б скапіяваць у правіла звароту, а фільтр, які чакае сіметрыі, скідвае адказ, пакуль запыт праходзіць бесперашкодна. Выпраўленне пачынаецца з чытання пакета такім, які ён ёсць, і затым з вызначэння, якая мяжа на шляху прымае рашэнне. Звычайна працуюць два ўзроўні, а трэці моўчкі скідвае адказ. Раздзелы ніжэй размяжоўваюць іх у тым парадку, у якім пакет сустракае іх.

Пакет мяняе тып, а не порт

Запыт рэха — гэта ICMP тыпу 8, коду 0, які нясе ідэнтыфікатар і парадкавы нумар. Адказ — тыпу 0, коду 0, з тымі ж ідэнтыфікатарам і парадкавым нумарам, а канчатковыя пункты IP перастаўлены. Гэтыя палі вызначае RFC 792, і менавіта ідэнтыфікатар дазваляе адпраўніку супастаўляць адказы са сваімі запытамі.

Адсутнасць не менш важная: загалоўка TCP або UDP няма, значыць, няма і порта, які трэба дазволіць. Правіла, якое называе порт для адказу на рэха, апісвае пакет, якога ніколі не будзе. Гэта самая распаўсюджаная памылка ў заяўках на пінг праз VPN. Правіла выглядае канкрэтным, не датычыцца нічога і пакідае збой менавіта там, дзе ён быў.

Тры кантэксты вызначаюць пакет

Калі пінг накіраваны на хост у далёкай LAN, запыт павінен быць перасланы шлюзам. Калі ён накіраваны на адрас, які належыць самому шлюзу, ён завяршаецца ў лакальным шляху ўводу. Калі ж шлюз сам ініцыюе пінг, пакет пачынаецца ў яго ўласным шляху вываду і зусім не перасякае рашэнне аб перасылцы.

Гэтыя тры кантэксты маюць розныя ланцугі правілаў і розныя лічыльнікі, і менавіта зліццё іх у адзін з’яўляецца прычынай таго, што «брандмаўэр дазваляе ICMP» усё яшчэ можа даваць няўдалы пінг. Знешні тунель — чацвёрты кантэкст: дазвол VPN-слухачу не дазваляе аўтаматычна дэкапсуляваны ўнутраны запыт, а ўнутраны дазвол нічога не кажа пра тое, ці ўзняты знешні тунель.

Фільтры са станам і без стану апрацоўваюць адказ па-рознаму

Брандмаўэр са станам, які бачыў, як запыт сыходзіць, можа звязаць адказ з гэтым патокам і прапусціць яго без другога правіла. Фільтр без стану не мае такой памяці, таму зваротны напрамак патрабуе ўласнага яўнага дазволу, з перастаўленымі крыніцай і прызначэннем.

Праверце, якую мадэль прадукт фактычна рэалізуе, перш чым нешта пісаць. Правіла для запыту рэха не абавязкова пакрывае адказ на рэха, а прадукт, які адсочвае ICMP-запыты, можа ўсё яшчэ ўжываць іншую палітыку да адказаў, што прыходзяць на іншы інтэрфейс.

Абмяжуйце тое, што дазваляеце. Дазвол усіх адказаў на рэха з любога месца — не тое ж самае, што завяршэнне сувязі са станам, і нумар тыпу не аўтэнтыфікуе адпраўніка.

Трансляцыя змяняе і ідэнтыфікатар

Калі трансляцыя крыніцы наўмысная, картэж на далёкім канцы не супадае з тым, што адправіў кліент. NAT можа трансляваць ідэнтыфікатар ICMP-запыту разам з адрасамі, таму патрабаванне, каб аднолькавы нумар быў з абодвух бакоў, стварае ілжывую няўзгодненасць.

Замест гэтага абапірайцеся на адлюстраванне, якое паведамляе транслятар. Транслятар, які перапісвае ідэнтыфікатар, не захавае нумар, запісаны вашым кліентам, таму лічыце ідэнтычнасцю менавіта адлюстраванне, а не нумар. Затым прасачыце адзін ідэнтыфікаваны запыт па шляху: пацвердзіце, што ён дасягае прызначэння з чаканай крыніцай, пацвердзіце, што прызначэнне выдала адказ, прасачыце маршрут гэтага адказу назад, і пацвердзіце, што кліент атрымаў яго, а не проста ўбачыў, як расце лічыльнік шлюза.

Не злівайце памылкі ICMP у палітыку рэха

Паведамленне «патрэбна фрагментацыя», якое выкарыстоўвае выяўленне MTU шляху, не з’яўляецца адказам на рэха, і яго карысная нагрузка цытуе пакет, што яго выклікаў. Дазвол толькі для рэха, які моўчкі адкідвае гэтыя памылкі, ператварае праблему памеру ў завіслае злучэнне, што з’яўляецца процілеглым карысці.

Тая ж асцярожнасць датычыцца сямействаў адрасоў. ICMPv6 выкарыстоўвае іншыя тыпы паведамленняў і нясе істотныя функцыі, якіх няма ў IPv4, таму капіраванне гэтых нумароў у правіла IPv6 — проста памылка.

Калі абмен рэха працуе, праверце рэальнае прыкладанне асобна. Паспяховы пінг даказвае кругавы шлях аднаго пратакола аднаго памеру да аднаго прызначэння, і гэта не ліцэнзія меркаваць, што HTTPS, SMB або любы іншы паток дазволены.