Kailangan ba ng dalawang site ng parehong VLAN ID para sa site VPN?
Hindi kayang ayusin ng parehong VLAN ID ang isang routadong site VPN: nagdadala ang tunnel ng mga IP prefix, kaya ang plano ng address at mga selector ang nagtatakda ng maaabot, hindi ang mga tag ng switch.
Ang parehong mga numero ng VLAN sa dalawang opisina ay tila dapat tumulong sa isang tunnel sa pagitan ng mga site, at wala silang binabago sa dinadala ng tunnel. Ang isang VLAN ID ay naglalagay ng tatak sa isang Ethernet broadcast domain sa loob ng isang gusali; ipinapasa ng tunnel ang mga IP packet sa pagitan ng mga gateway. Maaaring gumamit ang dalawang site ng ganap na magkaibang numbering ng VLAN at gayon pa man ay mag-ruta sa isa't isa, at maaaring gumamit ang dalawang site ng parehong numbering ng VLAN at gayon pa man ay hindi maabot ang isa't isa. Ang variable na nagtatakda ng maaabot ay ang plano ng address.
Ang mito: parehong VLAN ID sa dalawang dulo
Ang paniniwala ay nagmumula sa isang makatwirang lugar. Sa loob ng isang gusali, ang dalawang port sa parehong VLAN ay makakapag-usap at ang dalawang port sa magkaibang VLAN ay hindi, kaya ang numero ng VLAN ay tila ang bagay na nagbibigay ng koneksyon. Sa kabuuan ng isang routadong tunnel walang pinagsasaluhang segment ng Ethernet na mailalarawan ng tag, at hindi kailanman nagpapalitan ng mga label ng VLAN ang mga gateway.
Ang kailangan ng tunnel ay isang pares ng saklaw ng address na hindi nag-o-overlap at isang patakarang nagpapahintulot sa trapiko sa pagitan nila. Baguhin ang VLAN sa alinmang opisina at patuloy na gumagana ang tunnel, dahil wala sa configuration ng tunnel ang tumutukoy dito. Ito ang pagsubok na nagtatapos sa debate: muling bilangin ang VLAN, iwanan ang mga address at tingnan kung nananatili ang tunnel.
Ang kabaligtarang pagsubok ay kasing-kapaki-pakinabang. Bigyan ang dalawang opisina ng parehong subnet at walang dami ng parehong numero ng VLAN ang gagawa sa isang address na hindi malabo.
Ano ang aktwal na dinadala ng tunnel
Pinoprotektahan ng IPsec ang mga IP packet ayon sa patakarang ipinahayag sa mga address, protocol at port. Ang arkitektura ng IPsec ay naglalarawan ng mga selectorang iyon sa layer ng IP, na ilang layer sa itaas ng anumang inilalarawan ng tag ng switch. Kapag pumasok ang isang packet sa tunnel, naiwan na nito ang VLAN; ang tag ay naubos na ng lokal na switch.
Ang mga disenyong batay sa patakaran at batay sa ruta ay nagkakaiba sa kung paano nila pinipili ang tunnel, hindi sa kung ano ang kaya nilang dalhin. Ang isang peer na batay sa patakaran ay nagtutugma ng mga selector ng trapiko at nagpapadala ng mga tugmang packet sa tunnel. Ang isang peer na batay sa ruta ay nag-ruruta ng trapiko sa isang interface ng tunnel at hinahayaan ang routing table na magpasya. Pareho pa rin silang nakikipag-usap sa saklaw ng proteksyon, kaya ang isang rutang tumuturo sa tunnel ay hindi nagpapalawak sa napagkasunduan ng mga peer na protektahan.
Ang pagkakaibang iyon ay nagpapaliwanag ng karaniwang kalahating pagkabigo: umiiral ang ruta, pumapasok ang mga packet sa tunnel, at itinatapon ng malayong panig ang mga ito dahil hindi kailanman isinama ng napagkasunduang selector ang prefix na iyon. Ang pagbasa sa mga naka-install na patakaran ay nagpapakita kung aling saklaw ang aktwal na nagkabisa.
ip xfrm policy
ip route show
swanctl --list-sas
Ang overlap na talagang nakakasira
Ang dalawang opisina na may magkaibang subnet ay malinis na nag-ruruta sa isang tunnel, at ang kanilang mga numero ng VLAN ay walang kaugnayan. Ang dalawang opisina na may parehong subnet ay hindi, dahil ang isang kahilingan para sa isang partikular na address ay may dalawang posibleng kahulugan at ang routing table ay makakapili lamang ng isa. Ang muling pagbilang ng isang site ay ang malinis na solusyon, at karaniwang mas mura ito kaysa sa mga alternatibo kapag binilang ang mga pagbabago sa DNS at firewall.
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
Kapag imposible ang muling pagbilang, ang isang sinadyang disenyo ng pagsasalin ay maaaring magpakita ng magkaibang pananaw ng address sa bawat panig. Nangangahulugan iyon ng isa-sa-isang pagmamapa, mga tugmang selector, mga entry sa DNS na sumasalamin sa isinaling pananaw at routing pabalik na nakakaligtas sa muling pagsulat. Ito ay isang sinusuportahang disenyo na may tunay na gastos sa operasyon, at hindi ito ang ginagawa ng pagbabago ng VLAN ID.
Ang parehong mga numero ng VLAN sa dalawang dulo ay kung minsan ay isang pagkakataon ng isang pinagsasaluhang template, at ang pagtrato sa pagkakataong iyon bilang sanhi ng isang gumaganang tunnel ay humahantong sa maling pagbabago kapag may nasira sa ibang pagkakataon.
Isang trabaho bawat layer, nakasulat
Ang lokal na switch ay nagtatakda kung aling mga port ang nagbabahagi ng isang broadcast domain, at ang numbering ng VLAN nito ay lokal na accounting na hindi kailangang malaman ng ibang site. Ang gateway ay nagpapatotoo sa peer at nagpapatupad ng napagkasunduang saklaw ng proteksyon. Ang routing table ay nagtatakda kung saan pupunta ang isang decrypted na packet, at ang patakaran sa access ay nagtatakda kung dapat bang pinayagan ang packet na iyon.
Ang paghihiwalay ng mga trabahong iyon ang gumagawa sa mga pagbabago na ligtas. Ang muling pagbilang ng VLAN sa isang opisina ay humahantong sa lokal na switch, saklaw ng DHCP at marahil isang zone ng firewall, at hindi ito humahantong sa tunnel. Ang pagbabago ng prefix ay humahantong sa mga selector ng tunnel, mga ruta sa magkabilang panig at patakaran sa access, at hindi ito humahantong sa mga tag ng switch.
Ang mga ruta pabalik, pribadong DNS at mga pangangailangan sa pagkakakilanlan ng application ay muling hiwalay na mga trabaho, at wala sa mga ito ang dumarating sa pamamagitan ng pagkopya ng numero ng VLAN mula sa kabilang site. Ang isang dokumento ng disenyo na naglilista ng mga maaabot na prefix at pinapayagang serbisyo ay nakakaligtas sa isang pagpapalit ng switch; ang isa na naglilista ng mga numero ng VLAN ay hindi.
Kumpirmahin ang lokal na larawan gamit ang mga tool ng bridge bago ipagpalagay na ang isang tag ay umabot sa tunnel.
bridge vlan show
ip -br addr
ip route get 10.62.0.20
Kapag ang pagpapalawak ng layer-2 ang tunay na pangangailangan
Ang ilang disenyo ay tunay na nangangailangan ng pag-uugali ng Ethernet sa pagitan ng mga site: isang legacy na application na umaasa sa broadcast discovery, isang migrasyon na dapat mapanatili ang isang address habang gumagalaw ang isang makina, o isang protocol na naglalaman ng mga palagay ng layer-2. Ang mga ganitong kaso ay nangangailangan ng overlay o isang bridged na serbisyo na nagdadala ng mga frame, at pagkatapos ang pagiging kasapi sa VLAN, pag-iwas sa loop at paghawak ng pagkabigo ay nagiging mga usapin mula sa dulo hanggang sa dulo.
Iyon ay isang mas malaking domain ng pagkabigo, at dapat itong maging sinadyang pagpili sa halip na ang aksidenteng resulta ng pagtatangkang mapagana ang pagbabahagi ng file. Ang isang ordinaryong file server, database o web application ay nangangailangan ng awtorisadong IP path, at magiging mas masaya ito nang walang nakaunat na broadcast domain sa ilalim nito.
Isulat ang kontrata ng VPN bilang mga maaabot na prefix at pinapayagang serbisyo, at itala ang tag ng VLAN lamang kung saan ito kailangan ng mga lokal na operasyon. Pagkatapos ang bawat opisina ay maaaring muling bilangin ang sarili nitong switching nang hindi ginagawang muling disenyo ng tunnel ang bawat pagbabago.