Nagpapakita ang VPN adapter ng /32: hindi ito nangangahulugang isang destinasyon

Nagpapakita ang mga adapter ng 255.255.255.255, at madalas ang konklusyon ay eksaktong isang address lang ang naaabot ng VPN. Ang pagbasang iyon ay pinaghahalo ang address ng kliyente mismo sa set ng mga destinasyong niruruta sa tunnel. Sa point-to-point o rutadong interface, dalawang magkaibang bagay ang mga ito, at isa lang sa kanila ang naglilimita sa maabot. Nanatili ang mito dahil mukhang subnet mask ang mask na natutunan ng mga tao sa Ethernet.

Ang mito: ang host mask ay isang host lang na maaabot

Sinasabi ng /32 allocation sa interface kung aling address ang kabilang sa dulong ito ng link, at sa point-to-point na link iyon lang ang ibig sabihin nito. Ang address ng kapareha ay hiwalay na field, at ang mga rutang nagsasabi kung ano ang nasa lampas ng kapareha ay hiwalay rin. Walang anuman sa mask ang naglalarawan sa malayong network, dahil ang mask ay hindi ang lugar kung saan inilalarawan ang malalayong network. Ang basahin ito bilang hangganan ng maabot ay tulad ng pagbasa ng sariling numero ng bahay bilang listahan ng lahat ng address na puwede mong bisitahin.

May tunay na ugat ang kalituhan: sa Ethernet, ang host mask ay talagang nangangahulugang isang address lang sa segment na iyon. Ang tunnel ay hindi Ethernet segment, at kung ano ang dumadaan dito ay pinagpapasyahan ng routing table ng kliyente, hindi ng mask. Kaya ang parehong /32 ay maaaring tumayo sa harap ng isang buong data center.

Basahin ang address at mga ruta bilang magkahiwalay na bagay

I-print ang interface at ang table nang magkasama, pagkatapos basahin ang mga ito bilang dalawang sagot sa dalawang tanong. Sinasagot ng address kung sino ang dulong ito; sinasagot ng mga ruta kung saan puwedeng pumunta ang trapiko. Ang ikatlong tanong, kung aling mga destinasyon ang pinapayagan ng gateway, ay hindi talaga nakikita sa kliyente. Ang reference ng address ng iproute2 ay hiwalay na inilalarawan ang mga field ng lokal na address, kapareha at rutang prefix dahil dito mismo.

ip addr show tun0
ip route show
ip route get 10.60.5.10

Sa Windows may parehong paghihiwalay sa pagitan ng listahan ng address at ng routing table, at ang lookup command ang pinakamabilis na paraan upang makita kung alin ang nananalo para sa isang partikular na destinasyon. Kung ibinabalik ng lookup ang tunnel interface, doon ipapadala ng kliyente ang packet. Kung ibinabalik nito ang pisikal na adapter, hindi kailanman nagtatanong ang kliyente sa VPN, at walang pahintulot sa panig ng server ang makakabago niyon. Suriin ang destinasyong talagang kailangan mo, hindi isang generic na pampublikong address.

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

Huminto kung ang lookup ay tumuturo sa maling interface. Ito ay problema sa routing ng kliyente, at inaayos ito sa kliyente.

Bakit karaniwang pinapalala ng pagpapalawak ng mask

Ang pagpapalit ng allocation sa /24 upang magmukhang LAN ng opisina ay maaaring gumawa ng prefix sa link: naniniwala na ngayon ang kernel na ang buong /24 ay direktang nakakabit sa tunnel interface. Ang trapiko patungo sa mga address na dapat rutahin sa gateway ay ipinapadala kung gayon na parang may kapitbahay sa link. Ang resulta ay isang itim na butas na mukhang pagpalya ng server.

Itinatago rin nito ang tunay na problema, na isang nawawalang ruta o nawawalang pahintulot sa gateway. Wala sa dalawang iyon ang nililikha ng mas malawak na mask, at parehong nabubuhay pagkatapos ng pagbabago. Kung kailangan ng disenyo ng mas malaking prefix sa interface, desisyon iyon para sa modelong interface na ginagamit, na ginawa habang hawak ang dokumentasyon. Ang pagkopya ng mask mula sa mga screenshot ng ibang produkto ay hindi ang desisyong iyon.

Kung nawawala ang ruta ng malayong prefix, ayusin ang provisioning nito. Kung naroon ito at tinatanggihan pa rin ang koneksyon, hindi kailanman ang mask ang diagnosis.

Kapag tama ang ruta at nabibigo pa rin ang daloy

Ang tamang ruta ay nagpapatunay lamang na ipapadala ng kliyente ang packet. Kailangan pa ring tanggapin ng gateway ang destinasyon, dapat may daang pabalik para sa itinalagang address, at dapat payagan ng serbisyo ang daloy. Subukan ang tatlong ito nang hiwalay: ang lookup sa kliyente, ang pinapayagang saklaw ng gateway at isang kahilingan sa isang kailangang server. Normal na nagtatagumpay ang authentication bago pa man naroon ang lahat ng tatlo, at kaya naman may konektadong kliyente na wala pa ring naaabot.

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

Panatilihin ang mga bagay sa network at pahintulot ng grupo kasama ng may-ari nito sa serbisyong pinamamahalaan ng isang kagamitan. Ang sinasabing dapat maabot ng kliyente at ang pinapayagan nitong gamitin ay magkaibang setting, madalas sa magkaibang screen. Ang baguhin ang isa at subukan ang isa ay kung paano tumatalbog ang ticket sa pagitan ng dalawang team.

Ang mitong dapat iretiro ay ang pagiging hangganan ng maabot ang mask. Basahin ang address, mga ruta at patakaran ng gateway bilang tatlong magkahiwalay na katotohanan, at ang /32 ay hindi na mukhang paghihigpit at nagsisimulang magmukhang normal na tunnel allocation.