Trapiko ng kliyenteng VPN at estado ng firewall: panlabas at panloob na daloy

Natapos ang handshake ng VPN, nakakuha ng address ang kliyente, at tumatanggi pa rin ang serbisyo sa likod ng gateway sa koneksyon. Madalas gawin ng firewall ang eksaktong sinabi sa kanya. Pinayagan nito ang panlabas na daloy ng tunel, na ibang packet kaysa sa dekapsuladong koneksyon ng aplikasyon. May sumusunod na dalawang desisyon: aling daloy ang pinapayagan mo, at kung sinusubaybayan man ng hangganan ang estado.

Hangga't hindi mo pinaghihiwalay ang dalawang iyon, haka-haka lang ang bawat pagbabago ng patakaran.

Dalawang magkaibang packet ang nakikita ng firewall

Bago ang dekapsulasyon, nakikita ng firewall ang trapikong nakadirihis sa endpoint ng VPN: panlabas na daloy ng UDP patungo sa tagapakinig. Pagkatapos ng dekapsulasyon, may dalang panloob na address ng kliyente at destinasyon ng serbisyo ang ipinasa na packet.

Hindi pinahihintulutan ng permiso para sa panlabas na daloy ang ipinasang koneksyong TCP. Maaaring suriin ang mga ito sa magkaibang chain, laban sa magkaibang interface, at may magkaibang address pagkatapos ng pagsasalin.

Ihambing ang mga capture mula sa katumbas na posisyon sa magkabilang panig. Ang capture sa gilid ng tunel at ang capture sa server ay nagpapakita ng magkaibang tuple para sa parehong session.

Unang desisyon: payagan ang tunel o ang serbisyo

Kung ang endpoint ng VPN lang mismo ang kailangan ng kliyente, maaaring sapat na ang panlabas na permiso. Kung kailangan niya ng serbisyo sa kabila ng gateway, kailangan ng permiso sa pagpapasa para sa destinasyon at port na iyon. Ang patakaran ng tunel na nagpapahintulot din sa serbisyo ay isang desisyon sa disenyo na dapat mong pangalanan, hindi aksidente.

Panatilihing makitid ang saklaw ng kliyente at saklaw ng serbisyo. Ang permiso mula sa subnet ng tunel patungo sa buong LAN ay desisyong magtiwala sa bawat host, hindi shortcut para sa isang aplikasyon.

Isulat nang hiwalay ang dalawang patakaran. Nabibigo ang patakaran ng tunel at patakaran ng serbisyo sa magkaibang paraan at nade-debug sa magkaibang ebidensya. Kapag nabigo ang isa, alam mo kung aling layer ang unang susuriin.

Ikalawang desisyon: may estado o walang estado sa bawat hangganan

Ang patakaran para sa establisadong daloy ay maaaring magpadaan ng mga tugon para sa pinahintulutang palitan, ngunit nakadepende sa produkto ang pag-uugali nito. Karaniwang sinusubaybayan ng cloud security group ang estado; madalas hindi sinusubaybayan ng subnet ACL ang estado at nangangailangan ng tahasang paghawak sa dalawang direksyon. Huwag ipagpalagay na ang bawat hangganan sa ruta ay parehong tinatrato ang estado. Ilista ang bawat hangganan at markahan kung may o walang pagsubaybay sa estado bago mo idisenyo ang mga patakaran.

Kung magbabago ang isang patakaran, maaaring magpatuloy ang mga umiiral na sinusubaybayang daloy habang nabibigo ang mga bago, o kabaliktaran. Ang pagkakaibang iyon ay kapaki-pakinabang na palatandaan, hindi dahilan para buhusan ng lahat ng estado ng koneksyon sa isang live na gateway.

Subukan gamit ang bagong kontroladong kahilingan at suriin ang mga kaugnay na counter. Mas mabuti ang malinis na pagsubok kaysa sa nakakaabalang pag-reset. Itala ang pangalan ng counter sa talaan ng pagbabago upang magamit ng susunod na pagsubok ang parehong ebidensya.

I-verify ang daan pabalik sa ilalim ng parehong patakaran

Magpadala ng bagong kahilingan mula sa kliyente patungo sa serbisyo, pagkatapos suriin ang mga counter ng papunta at pabalik sa bawat hangganan. Kumpirmahin na ginagamit ng tugon ang inaasahan mong daan, lalo na kung may pagsasalin na kasangkot.

Panatilihing makitid ang nilalayong saklaw ng kliyente at saklaw ng serbisyo, at i-verify ang daan pabalik sa ilalim ng parehong set ng patakarang nagpahintulot sa kahilingan. Ang patakarang gumagana lang dahil bukas pa ang lumang daloy ay hindi gumaganang patakaran.