Aling address ang nakikita ng cloud firewall kapag naka-on ang VPN mo
Binabago ng full tunnel ang source address na nakikita ng database mo. Ilipat ang allowlist, ang pribadong landas o ang split tunnel, hindi ang kredensyal.
Ang database na gumagana bago kumonekta ang VPN at nabigo pagkatapos ay bihirang problema sa kredensyal. Itinatapat ng mga cloud firewall ang source address, at pinapalitan ng full tunnel ang eksaktong itinatapat nila. Ang agwat sa pagitan ng inaakala mong ipinapadala ng laptop mo at ng natatanggap ng server ang buong bug, at masusukat ito sa isang hakbang.
Ano ang nagiging source address
Sa full tunnel, lumalabas ang bawat packet sa VPN gateway, kaya nakikita ng server ang egress address ng gateway sa halip na ang koneksyon mo sa bahay. Kung may forward proxy sa landas, ang address nito ang dumarating. Pareho silang lehitimong pinagmulan, at wala sa kanila ang address sa orihinal mong tuntunin.
Itinatapat ng mga firewall rule ng Azure SQL sa antas ng server at antas ng database ang client address na umaabot sa logical server, na pagkatapos ng full tunnel ay ang egress address. Ganoon din ang kilos ng AWS security group na nagpapahintulot ng isang address. Itinatapon ang packet bago ang authentication, kaya ang error na natatanggap mo ay mukhang pagkabigo ng network sa halip na problema sa pahintulot. Iyon mismo ang dahilan kung bakit nagsisimulang mag-reset ng password ang mga tao.
Saan nagpapasya ang allowlist
Basahin ang tuntuning tumutugma sa bumabagsak na landas, hindi ang tuntuning natatandaan mong ginawa mo. Tandaan ang saklaw nito, ang port nito, ang protocol nito at kung sinusuri ito bago ang anumang identity check.
Pagkatapos ay magpasya kung aling layer ang lehitimong may-ari ng desisyong iyon. Sinasagot ng address rule kung saan galing ang trapiko. Sinasagot ng pribadong endpoint kung maaabot ba ang serbisyo sa pribadong landas. Sinasagot ng split-tunnel exception kung aling destinasyon ang lumalampas sa tunnel. Hindi sila mapagpapalit, at bawat isa ay nabigo nang iba kapag nagbago ang tunnel.
Tatlong pagkukumpuni, tatlong layer
Inaayos ng bawat opsyon sa ibaba ang daloy sa ibang dahilan, at ang maling pagpili ay gumagawa ng koneksyong gumagana hanggang sa susunod na pagbabago ng gateway.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
Ang pagdaragdag ng egress address ang pinakamaliit na pagbabago at pinakamadaling masira, dahil ang bagong gateway o ibang rehiyon ay tahimik na nagpapawalang-bisa nito. Idokumento ang address sa tabi ng depinisyon ng tunnel para sabay silang gumalaw. Ang pansamantalang malawak na saklaw ay diagnosis, hindi pagkukumpuni; ang iwanan ito sa puwesto ay ang paraan kung paano nauuwi sa pagiging bukas ang mga panloob na serbisyo.
Bakit hindi makasama ang isang managed platform sa tunnel
Ang mga application platform tulad ng Heroku, AppHarbor o CloudBees ay nagpapatakbo ng code mo sa kapaligirang walang tun o tap device at walang pribilehiyong gumawa ng isa. Ang inbound model nila ay HTTP at hindi arbitraryong nakikinig na socket. Ang buildpack na nagdadala ng VPN binary ay wala pa ring mapaglalagyan ng interface. Ang gumaganang pattern ay isang static na egress address na maaaring pahintulutan ng database, isang pribadong koneksyon na produkto na inaalok ng platform, o isang proxy sa DMZ na naaabot sa HTTPS.
Ang proxy na iyon ay landas ng access na may sariling authentication at logging. Hindi nito ginagawang miyembro ng VPN mo ang platform, at ang ilarawan ito nang ganoon ay lumilikha ng mga tuntuning walang makapag-audit.
I-verify mula sa client na nabigo
Kumonekta muli at ulitin ang eksaktong landas ng client. Suriin ang source address na nila-log ng serbisyo, ang route na pinipili ng client para sa pangalan ng database, at ang resulta ng aktwal na query, sa ganoong pagkakasunod-sunod. Ang pagsubok mula sa gateway ay nagpapatunay na gumagana ang gateway, na hindi kailanman naging duda. Kung ang koneksyon ay nag-a-authenticate na ngayon at nabibigo pa rin ang query, ang natitirang problema ay ang pahintulot sa database.
Suriin ang mga tuntuning ito tuwing magbago ang tunnel. Ang pinalitang gateway o bagong egress range ay humahati sa landas nang walang anumang pagbabago sa configuration ng application.