Cloud firewall kumpara sa host firewall para sa isang VPN server

Payagan ang VPN port sa patakaran ng cloud at maaari pa ring mamatay ang handshake sa instance: may sariling filter at sariling binding ng listener ang bisita, at alinman sa dalawa ay maaaring itapon ang inaprubahan ng cloud. Nangyayari rin ang kabaligtaran, kapag pinapayagan ng tuntunin sa host ang port at itinatapon muna ito ng patakarang nasa itaas. Dalawang may-ari, dalawang set ng tuntunin, isang landas ng packet. Sundan ito nang sunod-sunod sa halip na manghula sa pinakakahina-hinalang layer.

Magsimula sa gilid at pumasok sa loob

Ang pagkakasunod-sunod ay fixed: pampublikong endpoint, interface ng resource, nakakabit na patakaran ng cloud, address ng bisita, listener ng proseso, mga lokal na tuntunin sa input. Bawat yugto ay nagpapadaan sa packet o nagtatapos sa pagsisiyasat, kaya ang pagsisimula sa bisita ang pinakamaraming nasasayang na oras.

Ang naipasa na trapiko ng kliyente ay hiwalay na yugto, sinusuri pagkatapos ma-decapsulate ang tunnel. Ang layer ng cloud ay nakakakita lamang ng panlabas na tunnel, kaya maaari nitong aprubahan ang koneksyon at wala pa ring kinalaman sa isang kahilingan ng panloob na serbisyo. Ang tunnel na kumokonekta ngunit hindi umabot sa panloob na host ay karaniwang tumutukoy sa pagpapasa, hindi sa saradong port.

Basahin ang patakaran ng cloud bago hawakan ang bisita

Kumpirmahin ang inbound na tuntunin para sa VPN port, ang protocol nito at ang saklaw ng pinagmulan na tugma sa iyong test client. Tingnan din ang listahan ng access control ng subnet: pangalawang filter na may sariling tuntunin at default. Dapat parehong payagan ng dalawa ang daloy bago umabot ang packet sa instance. Ang pagpayag sa isa at pagtanggi sa isa pa ang karaniwang anyo ng bug na ito.

Paliitin ang saklaw hanggang may kahulugan ito. Ang pagbukas ng VPN port sa buong internet ay madaling patunayan at mahirap ipagtanggol, samantalang ang tuntuning nakapin sa isang address ay nasisira kapag nagpalit ng network ang test client mo. Itala ang identifier ng tuntunin at ang may-ari ng patakaran, upang masubaybayan ang susunod na pagbabago hanggang sa isang tao.

Kumpirmahin ang listener, pagkatapos ang input chain

Sa instance, tingnan kung ang proseso ng VPN ay nakatali sa address at port na inaasahan mo, halimbawa gamit ang ss -lntp 'sport = :1194'. Ang daemon na nakatali lamang sa 127.0.0.1 ay tumatanggap ng lokal na kliyente at wala sa pamamagitan ng tunnel, na mula sa labas ay mukhang eksaktong isang na-filter na port.

Pagkatapos basahin ang mga lokal na tuntunin sa syntax na gagamitin mo para baguhin ang mga ito, tulad ng iptables -S INPUT o nft list chain inet filter input. Ang tuntuning nakasulat sa file ngunit hindi kailanman na-load, o default na pagtatapon na walang tugmang pagpayag, ay tahimik na nagtatapon ng packet. Para sa gateway na nagpapasa, tingnan din ang mga setting ng pagpapasa at ng pabalik na landas. Sila ang nagtatakda kung ano ang nangyayari sa mga packet na ruta sa pamamagitan ng instance at hindi naka-address dito.

May state sa isang layer, walang state sa susunod

Ang mga security group ay naaalala ang mga daloy na pinayagan nila at pinapapasok muli ang mga tugon. Ang mga access control list ng subnet at maraming host firewall ay hindi nag-iingat ng ganoong state, kaya ang tuntuning sumasaklaw lamang sa papalabas na direksyon ay nagpapadaan sa kahilingan at nagtatapon ng tugon. Huwag kailanman magdala ng palagay tungkol sa pabalik na trapiko sa pagitan ng mga layer nang hindi binabasa ang tuntunin ng pangalawang layer (second layer's rule).

Mas mabilis lutasin ng mga counter kaysa basahin ang bawat tuntunin sa account. Ang tumataas na counter ay nangangahulugang nakarating ang packet at itinapon doon, samantalang ang nakapirming sa zero ay nangangahulugang hindi ito umabot doon; ipinapakita ng iptables -vnL INPUT at nft list ruleset ang mga bilang na iyon kapag na-load ang mga tuntunin kasama ng mga counter.

Subukan sa bagong sesyon, hindi sa buhay na sesyon

Iwanang hindi ginalaw ang source network at ang test profile habang inihahambing ang mga view, at magbukas ng bagong koneksyon pagkatapos ng bawat pagbabago. Ang maabot ang web console sa 443 ay walang sinasabi tungkol sa kung ang daemon ng VPN ay nakatali sa 1194, kaya subukan ang port na kailangan mo. Ang kasalukuyang sesyon ang pinakamasamang saksi dito. Patuloy itong gumagana habang tinatanggihan ang bawat bagong login.

Bago i-edit ang malayong patakaran, tiyakin ang daan pabalik na hindi nakadepende sa landas na binabago mo. Pagkatapos buksan ang pangalawang sesyon ng administrasyon sa tabi ng pagsubok sa VPN: ang naitatag nang mas maaga ay maaaring mabuhay nang mas matagal kaysa sa tuntuning humaharang sa mga bago. Itala ang may-ari ng parehong patakaran upang walang muling pagtatayo ang magbalik sa kalahati ng landas; kung parehong layer ang magkasundo at nabigo pa rin ang tunnel, kunan ng capture sa interface ng bisita at tingnan ang address at port na talagang ginagamit ng kliyente.