Sapat ang isang pisikal na adapter para sa maraming VPN server, at hindi rin ito universal na disenyo. Dumarating sa adapter na iyon ang naka-encrypt na koneksyon, dine-decrypt ito ng prosesong VPN, at pagkatapos lumalabas ang panloob na trapiko sa isang virtual na interface bago maabot ang lokal na serbisyo o routed na LAN. Kung gagana ito ay depende sa tatlong kondisyon: kung saan naroon ang destinasyon, kung may ruta pabalik ang LAN patungo sa pool ng mga kliyente, at kung binibigay ng isang pinagsasaluhang pisikal na link ang paghihiwalay na sinasabi mo. Sagutin ang tatlong iyon at susunod ang bilang ng adapter.

Ang tatlong kundisyong nagpapasya nito

Ang unang kondisyon ay ang destinasyon. Ang serbisyo sa mismong VPN host ay naaabot lamang sa pamamagitan ng tunnel interface, samantalang ang host sa LAN ay nangangailangan ng forwarding at ruta pabalik. Ang ikalawang kondisyon ay ang rutang pabalik, dahil kailangang malaman ng aparato sa LAN kung paano maaabot ang pool ng mga kliyente, sa pamamagitan man ng ruta o ng pagsasalin sa server.

Ang ikatlong kondisyon ay ang paghihiwalay. Ang isang adapter ay nangangahulugang bawat packet, naka-encrypt man o hindi, ay nagbabahagi ng isang link at karaniwang isang policy chain, kaya ang pag-aangkin ng paghihiwalay na nakasalalay sa hiwalay na hardware ay hindi natutugunan ng isang interface. Ito ay katotohanan tungkol sa landas, hindi tungkol sa kung paano naka-configure ang operating system. Maaari mo pa ring i-filter ang trapiko ng tunnel, ngunit hindi mo maaaring angkinin ang hangganang wala ka.

Wala sa tatlo ang tungkol sa bilang ng port sa chassis. Tungkol ang mga ito sa routing, pagmamay-ari ng address, at kung gaano nakasalalay ang disenyo sa pisikal na paghihiwalay.

Nananatiling lehitimong pagpipilian ang dalawang adapter kapag pinagbibigyang-katwiran ito ng pisikal na zone, hiwalay na uplink, throughput, o ruta ng pagbawi sa labas ng band. Mga konkretong pangangailangan ang mga iyon, at sulit na sabihin ang mga ito bago may umorder ng hardware.

Kapag tumatakbo ang serbisyo sa VPN host

Ang pinakasimpleng kaso ay walang kailangang forwarding. Tinatanggap ng daemon ang mga packet ng kliyente sa tunnel interface at ibinibigay ang mga ito sa lokal na socket, at bumabalik ang sagot sa parehong interface. Para sa host, ang address sa pool ng mga kliyente ay tunay na lokal na address.

Dalawa pa rin ang dapat tama: kailangang makinig ang serbisyo sa address na maaabot ng tunnel, at kailangang tanggapin ng firewall ng host ang trapikong dumarating sa tunnel interface. Pareho silang makikita sa mga command sa ibaba.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Ang pag-bind ng serbisyo sa pampublikong address lamang, o ang aksidenteng pag-filter sa tunnel interface, ay gumagawa ng koneksyong umaabot sa host at pagkatapos ay namamatay. Mukha itong sira ng VPN at karaniwang desisyon sa socket o firewall.

Kapag ang destinasyon ay nasa LAN

Dito nakakakuha ng reputasyon ng pagiging mahirap ang disenyong may isang adapter. Kailangang i-forward ng server ang mga packet ng kliyente patungo sa LAN, at kailangang ipadala ng aparato sa LAN ang mga sagot pabalik sa pool ng mga kliyente. Maaaring dalhin mo ang pool na iyon bilang ruta sa LAN, o isalin ang source address sa server upang bumalik ang mga sagot sa server mismo.

Parehong lehitimo ang dalawang sagot at nabibigo sila sa magkaibang paraan. Pinapanatili ng rutang pabalik na nakikita ng destinasyon ang orihinal na address ng kliyente, na mabuti para sa mga log at masama para sa mga panuntunan ng firewall na ipinapalagay ang LAN address. Itinatago ng pagsasalin na simple ang LAN at ikinukubli ang pagkakakilanlan ng kliyente sa destinasyon.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Ang asymmetric na landas ang klasikong sintomas: dumarating ang kahilingan ng kliyente, lumalabas ang sagot sa ibang router, at nag-time out ang koneksyon nang walang error sa magkabilang dulo. Kuhanan ng capture sa magkabilang panig bago maghinuha ng anuman tungkol sa tunnel.

Bakit hindi gumagawa ng ikalawang zone ang alias

Ang pagdaragdag ng ikalawang address sa parehong adapter, o paggawa ng dummy interface na ginagaya ang ikalawang port, ay napakaliit ng binabago. Lumalabas pa rin ang mga packet sa parehong pisikal na link, parehong switch port, at karaniwang parehong firewall chain, kaya walang bagong hangganan sa pagitan nila. Kaginhawahan ito ng configuration, hindi segmentation. Ang ituring itong hangganan ng zone ay ang paraan upang ang pag-aangkin ng paghihiwalay ay mabuhay lamang sa papel.

Ang hiwalay na zone ay nangangailangan ng tunay na paghihiwalay sa landas, at iyon ang kundisyong natutugunan ng ikalawang adapter. Kung ang isang panuntunan ay nakasalalay sa trapikong patungo sa VPN na hindi kailanman nagbabahagi ng broadcast domain sa trapikong patungo sa LAN, hindi kayang ibigay ng isang kable ang katangiang iyon, gaano man ina-address ang host.

Kung ang isang produkto ay nagdodokumento ng multi-interface topology para sa isang partikular na mode, sundin ang dokumentasyon ng produktong iyon sa halip na mag-imbento ng solusyon. Nagbabago rin ang mga vendor ng sinusuportahang topology sa pagitan ng mga release, na isa pang dahilan upang basahin ang kasalukuyang gabay sa halip na lumang screenshot ng wizard.

Suriin ang layout laban sa trapikong pinapayagan mo

Ilista ang mga klase ng trapikong dapat dalhin ng server: kliyente patungo sa host, kliyente patungo sa LAN, host patungo sa LAN, at ang naka-encrypt na panlabas na koneksyon. Bawat klase ay may source, destinasyon, at interface, at kailangang matugunan ng layout ang apat nang sabay. Ang disenyong humahawak ng tatlo sa mga ito ang karaniwang gumagawa ng mga ticket.

Pagkatapos ay kumpirmahin ang aktwal na mga interface at ang aktwal na capture, hindi ang diagram sa dokumento ng disenyo. Ipinapakita ng mga command sa ibaba ang dalawang view.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Kung ang panlabas na capture ay nagpapakita ng naka-encrypt na trapiko at ang panloob na capture ay nagpapakita ng na-decrypt na trapiko sa tunnel interface habang dinadala ng pisikal na adapter ang dalawa, isang NIC lang ang gumagawa ng trabaho. Kung walang laman ang panloob na capture, ang problema ay nasa tunnel o sa mga panuntunan ng forwarding, hindi sa bilang ng adapter. Pagpasyahan ang topology mula sa dalawang capture na iyon at sa routing table, at ang susunod na pagbabago ay may paghahambingan.

Kaugnay na mga artikulo