Jinsi ya kuangalia kama satelaiti ya Mesh Wi-Fi inatumia kipanga-njia cha VPN

Satelaiti inayojibu jina lile la Wi-Fi la kipanga-njia kikuu haisemi karibu chochote kuhusu pakiti za wateja wake zinaenda wapi. Nodi ni redio na daraja hadi ithibitishwe kinyume. Kinachoamua njia ya kutoka ni lango chaguo-msingi ambalo kila mteja hupokea na hali ya uenezaji ya nodi iliyo mbele yake. Fanya ukaguzi huu tano kutoka kwa mteja kuelekea nje, na utapata jibu la kutetea, sio hisia kutoka kwa jaribio la mwendo.

Soma lango ambalo mteja alilipokea kwa kweli

Kwenye mteja, chapisha jedwali la njia na jedwali la majirani. Njia chaguo-msingi inataja anwani inayopeleka trafiki; ingizo la jirani linataja MAC inayomiliki anwani hiyo. Tumia mteja, sio orodha ya vifaa ya kipanga-njia, kwa sababu orodha ya vifaa inaonyesha uhusiano, sio njia.

ip route show default
ip -6 route show default
ip neigh show

Windows huchapisha ukweli huo huo kwa namna nyingine: ipconfig /all hutoa lango chaguo-msingi na arp -a hutoa MAC. Kwenye macOS, route -n get default na arp -an hushughulikia jambo lilo hilo.

Linganisha lango hilo na anwani mbili unazozijua tayari: anwani ya LAN ya kipanga-njia kikuu na anwani ya usimamizi ya satelaiti. Ikiwa lango ni anwani ya LAN ya kipanga-njia, mteja ameunganishwa kwa daraja na kipanga-njia na sera ya kipanga-njia kwa mtandao huo inatumika bila mabadiliko. Ikiwa lango ni anwani ya satelaiti, satelaiti inaelekeza na kipanga-njia hakioni pakiti za mteja kama trafiki ya LAN; uamuzi lazima ufanywe kwenye nodi, vinginevyo haufanyiki kabisa.

Thibitisha nodi iko katika hali gani kwa kweli

Bidhaa za Mesh hutumia maneno matatu kwa tabia tofauti, kwa hiyo amini njia ya pakiti zaidi ya lebo kwenye programu. Hali ya daraja au kituo cha ufikiaji hupeleka fremu. Hali ya kipanga-njia humaliza subnet na kuendesha DHCP. Hali ya mgeni kwa kawaida huweka wateja kwenye VLAN tofauti na sheria zake. Nodi iliyo katika hali ya kipanga-njia nyuma ya kipanga-njia kingine ni NAT mbili, na wateja wake hufika kwenye kipanga-njia cha VPN wakiwa wametafsiriwa tayari, jambo linalodhoofisha sera inayotegemea anwani ya chanzo.

Ili kubaini MAC, soma lebo kwenye nodi na linganisha na ip neigh. Watengenezaji huchapisha MAC msingi na kupata MAC za kila redio kwa kuongeza baiti moja, kwa hiyo tarakimu ya mwisho ya heksadesimali hutofautiana; linganisha kiambishi awali badala ya anwani nzima. Ikiwa MAC ya lango ni ya kiolesura cha LAN cha kipanga-njia, nodi haielekezi kwa mteja huyo.

Thibitisha njia ya kutoka kwenye kipanga-njia, sio kwa jaribio la mwendo

Hali ya upande wa kipanga-njia ndio mahali pekee panapoonyesha utafsiri. Kwenye OpenWrt, orodhesha kanuni za sera na majedwali ya njia, kisha thibitisha kuwa handaki ina handshake mpya:

ip rule show
ip route show table all | grep default
wg show

Kwenye pfSense au OPNsense ushahidi huo huo upo katika pfctl -sr kwa kanuni, pfctl -ss kwa hali zinazotumika na ukurasa wa hali wa WireGuard kwa vihesabu vya wenzake, kwa kufuata nyaraka za mteja wa WireGuard. Chuja jedwali la hali kwa anwani ya mteja. Ikiwa hali inaonyesha mteja ametafsiriwa kwenye anwani ya handaki, trafiki iko ndani ya handaki; ikiwa inaonyesha anwani ya WAN, haiko, chochote beji ya dashibodi inachosema.

Traceroute kutoka kwa mteja huongeza ukweli mmoja ambao jedwali la hali hauwezi kutoa: hop ya kwanza. Ikiwa hop ya kwanza ni anwani ya LAN ya kipanga-njia, mteja alifikia kipanga-njia moja kwa moja. Ikiwa ni anwani ya nodi ikifuatiwa na hop nyingine ya faragha, uko kwenye sehemu inayoelekezwa, na hop hiyo ya pili ndio kifaa kinachopaswa kushikilia sera.

Angalia nodi inasambaza nini kingine zaidi ya anwani

Chaguo za DHCP husafiri pamoja na kukodisha, kwa hiyo nodi inayotoa DHCP yake mwenyewe inaweza pia kutoa DNS yake na matangazo yake ya kipanga-njia ya IPv6. Hivyo mteja anaweza kutoka kupitia handaki na bado kutuma hoja kwa resolver iliyo kwenye nodi, au kupata anwani ya kimataifa ya IPv6 ambayo sera ya handaki haijawahi kuifunika. Chapisha vyote viwili kwenye mteja:

cat /etc/resolv.conf
ip -6 addr show scope global

Ikiwa resolver ni nodi na nodi inapeleka kwa kipanga-njia, DNS hufuata handaki. Ikiwa nodi inatatua ndani au inaelekeza kwenye resolver ya mtoa huduma, hoja zinatoka nje ya handaki hata HTTP haifanyi hivyo. IPv6 inastahili jaribio hilo hilo: anwani ya kimataifa pamoja na njia chaguo-msingi inayopita kando ya handaki ni uvujaji, na programu-jalizi za Mesh mara nyingi huacha IPv6 ikiwa hai wakati sera ya VPN inafunika IPv4 pekee.

Vunja handaki kwa makusudi, kisha andika matokeo

Shusha handaki na uangalie mteja aliyeunganishwa na nodi hiyo, sio mteja aliyeketi karibu na kipanga-njia. ping na curl yenye muda mfupi wa kusubiri inatosha; swali ni kama trafiki inasimama au inarudi kwenye WAN. Simamisha handaki kwa amri ya huduma ya kipanga-njia yenyewe, kwa mfano wg-quick down wg0 au kusimamisha huduma ya OpenVPN, na ufanye jaribio liwe fupi.

Ikiwa mteja anaendelea kufanya kazi, nodi au kipanga-njia inashindwa kwa njia ya wazi kwa sehemu hiyo, na mesh imebatilisha kill switch kwa utulivu. Rejesha handaki, thibitisha kuwa kihesabu cha handshake kimesogea, na urudie ukaguzi wa jedwali la hali kutoka hatua ya tatu.

Andika safu moja kwa kila nodi: lebo, SSID, anwani ya lango, kiambishi awali cha MAC, kutoka kwa uthibitisho ndio au hapana, IPv6 imefunikwa, na tabia wakati handaki imeshushwa. Uraibu ndio mahali jibu linabadilika, kwa hiyo jaribu vyumba unavyotumia kwa kweli. Safu moja isipopatana na nyingine, nodi hiyo ndiyo ya kuchunguza, na marekebisho yako kwenye kifaa kinachomiliki lango la safu hiyo.