Checklist para sa isang paunang naka-configure na VPN router: ano ang dapat i-verify sa paghahatid

Ang paunang na-load na router ay dumarating na may mga desisyon ng ibang tao na naka-bake na sa loob: aling serbisyo ng VPN ang tinatawagan nito, kaninong account ang nagbabayad para dito, anong trapiko ang hinuhuli nito at sino ang may hawak ng password na nagbabago ng alinman sa mga iyon. Tratuhin ang paghahatid bilang audit, hindi bilang pagbubukas ng kahon. Ang limang hakbang sa ibaba ay nakaayos, at bawat isa ay may kondisyon ng paghinto; kung mabigo ang isang hakbang, hindi masasabi ng mga susunod na hakbang ang anumang mapagkakatiwalaan tungkol sa device. Daanan ang mga ito nang ang router ay nasa harap mo at ang laptop ay nasa likod nito.

Hakbang 1: kunin ang administratibong kontrol sa device

Hanapin ang management address, mag-log in at palitan ang administrator password bago mo ikonekta ang anumang mahalaga. Sa isang GL.iNet travel router, ang address na iyon ay 192.168.8.1 at hinihiling ng first-run wizard na itakda mo ang password; ang ibang nagbebenta ay nagdodokumento ng kanilang sariling address at maaaring magpadala ng fixed credentials na nakalimbag sa label. Kung dumating ang device na naka-enable ang remote support o cloud management, magpasya na ngayon kung mananatili iyon.

ssh [email protected]
cat /etc/openwrt_release
ubus call system board

Ang tatlong command na iyon ay sumasagot kung sino ang gumawa ng firmware, anong release ito at anong hardware revision ang aktwal na natanggap mo. Isulat ang output sa handoff record, dahil ang susunod na support call ay magsisimula sa eksaktong mga tanong na iyon. Ang router na sumasagot sa SSH ngunit tumatanggi sa pagbabago ng password, o walang dokumentadong recovery path, ay hindi device na maaari mong pagmamay-ari.

Huminto dito kung hindi ka makakakuha ng eksklusibong admin access. Lahat pagkatapos ng puntong ito ay ipinapalagay na mababasa at mapapalitan mo ang configuration nang hindi tinatanong ang nagbebenta.

Hakbang 2: alamin kung kaninong VPN account ang ginagamit ng tunnel

Ang tunnel ay isang subscription sa pangalan ng isang tao, at ang paghahatid ay hindi kumpleto hanggang malaman mo kung kaninong pangalan. Humingi ng provider, may-ari ng account, petsa ng renewal at ang eksaktong credentials na naka-install sa device. Ang paunang na-load na configuration na nagbabahagi ng isang credential sa maraming mamimili ay hindi maaaring bawiin para sa iyo lamang, at mahalaga iyon sa araw na mawalan ng kontrol ang nagbebenta dito.

wg show
uci show network | grep -i -E 'vpn|wireguard|openvpn'
ip route show table all | head -40

Sa WireGuard, pinapangalanan ng output ang peer at ang oras ng huling handshake; sa OpenVPN, ang profile ay nasa ilalim ng /etc/openvpn at ipinapakita ng tumatakbong serbisyo kung aling profile ang aktibo. Itala ang makikita mo, dahil ang muling pagkonekta na tahimik na gumagamit ng ibang endpoint ay pagbabagong gusto mong matuklasan, hindi ipaliwanag.

Huminto dito kung hindi maaaring ilipat, i-renew o bawiin ang account sa iyong pangalan. Ang device na maaari mong pamahalaan ngunit hindi mo maaaring i-provision muli ay nagiging ladrilyo sa araw na mag-expire ang subscription.

Hakbang 3: subukan ang lokasyon ng labasan mula sa client, hindi sa router

Ang bansa na nakalimbag sa kahon, ang bansa sa listing ng nagbebenta at ang bansa ng pampublikong address ay tatlong magkakaibang katotohanan. Tanging ang huli ang nakakaapekto sa nakikita ng isang website, at ito ay ginagawa ng endpoint ng provider, hindi ng shipping address. Patakbuhin ang pagsusuri mula sa laptop sa likod ng router habang naka-on ang tunnel, hindi mula sa sariling shell ng router.

curl -s https://ifconfig.me
curl -s https://ipinfo.io/json
dig +short myip.opendns.com @resolver1.opendns.com

Ihambing ang tatlong sagot. Kung hindi sila magkatugma, may isang bagay sa pagitan ng client at endpoint na nagsusulat muli o nag-proxy ng trapiko, at dapat mong alamin kung ano iyon bago umasa sa lokasyon. Ang mga geolocation database ay mga pagtatantya na pinapakain ng mga operator, kaya ang tumutugmang country code ay sumusuportang ebidensya at hindi patunay ng pisikal na ruta.

Huminto dito kung ang labasan ay naiiba sa kontratado mo, o kung nagbabago ang sagot sa pagitan ng mga query. Ang umiikot o hindi pare-parehong labasan ay sumisira sa mga serbisyong nakadepende sa rehiyon at ginagawang malabo ang bawat susunod na pagsukat.

Hakbang 4: i-pin ang firmware at ang update channel

Ang mga paunang naka-configure na device ay madalas dumating na may mas lumang build at configuration ng nagbebenta na naka-layer sa OpenWrt. Bago tumanggap ng anumang update, alamin kung pinapanatili ng upgrade ang VPN profile, kung nagbibigay ang nagbebenta ng kapalit na profile at sino ang inaasahang gagawa ng upgrade. Basahin ang release notes para sa model na aktwal na mayroon ka, hindi para sa model sa larawan ng listing. Kung hindi sinasagot ng nagbebenta ang alinman sa mga tanong na iyon, ituring na hindi suportado ang mga update at i-freeze ang build na mayroon ka.

cat /etc/openwrt_release
cat /etc/glversion 2>/dev/null
opkg list-installed | wc -l

Magtabi ng kopya ng gumaganang configuration sa labas ng device bago ka magbago ng anuman: ang mga WireGuard key, ang OpenVPN profile at ang firewall rules na nagpapatupad ng routing policy. Ang factory reset na walang kopyang iyon ay nag-aalis ng eksaktong configuration na binayaran mo, at maaaring hindi na ito muling ilabas ng nagbebenta.

Hakbang 5: magpasya kung ano ang saklaw ng tunnel at ano ang nangyayari kapag nabigo ito

Ang routing ng buong network, routing ng mga piling device, paghawak ng DNS, IPv6 at pag-uugali ng kill switch ay magkakahiwalay na setting na madalas pagsama-samahin ng isang interface sa iisang toggle. Suriin ang mga ito nang isa-isa, dahil ang konektadong router ay nagpapatunay lamang na ang router mismo ay makararating sa endpoint. Subukan mula sa downstream client habang naka-on ang tunnel, pagkatapos ay muli habang naka-off.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111
nft list ruleset

Kung naka-enable ang IPv6 sa LAN ngunit hindi naka-route sa tunnel, maaaring mas gusto ito ng mga client at tuluyang lisanin ang VPN path habang mukhang protektado pa rin ang IPv4. Kung nakapatay ang kill switch, ang bumagsak na tunnel ay bumabalik sa ISP path, na mabuting pagpipilian lamang kapag ginawa mo ito nang sadyang. Ang parehong kondisyon ay hindi nakikita mula sa dashboard ng provider.

Isulat ang paghahati ng support bago mo ito kailanganin. Ang nagbebenta ng hardware, ang nagpapanatili ng firmware at ang operator ng VPN ay tatlong partido na may tatlong magkakaibang recovery procedure, at ang isang contact ay maaaring sumaklaw ng ilang tungkulin nang hindi lahat. Tapos na ang paghahatid kapag napapamahalaan mo ang device, nare-renew o nababawi ang account, napaparami ang nilalayong labasan, naa-update ang firmware nang hindi nawawala ang profile at masasabi mo nang eksakto kung ano ang nangyayari kapag bumagsak ang tunnel.