Af hverju LAN-hýsill sendir ARP fyrir vistfang OpenVPN-biðlara

Aðgengisvandamál milli LAN-hýsils og VPN-biðlara rekja sig oft til vistfangaáætlunarinnar sjálfrar. Gefðu þeim hýsli tengi á 10.0.100.0/22 og hann meðhöndlar hvert vistfang frá 10.0.100.0 til 10.0.103.255 sem beintengt, þar á meðal biðlaraþyrpingu sem er hljóðlega staðsett á 10.0.101.0/24. Svarið fer aldrei til beinis, því frá sjónarhóli hýsilsins kemur ekkert beini við sögu. Pakkanum er beint til nágranna og hann er sóttur á vírinn.

Sú aðferð liggur að baki heilli fjölskyldu tilkynninga: göngin eru uppi, netþjónninn er með leið og LAN-hýsillinn nær samt ekki biðlaranum.

Forskeyrtið /22 sem gleypir /24

Lestu forskyrtið sem bil, ekki sem streng. Forskeyrti /22 hefur að geyma 1024 vistföng og 10.0.100.0/22 spannar frá 10.0.100.0 til 10.0.103.255, þannig að þyrping á 10.0.101.0/24 liggur að fullu innan þess. Villan lifir yfir yfirferðina vegna þess að fyrstu áttundir þyrpingarinnar líta öðruvísi út en fyrstu áttundir LANsins og aðeins þriðja áttundin palar innilokuninni. Skrifaðu bæði bilin út tölulega áður en þú lýsir þeim aðskildum.

Sama innilokun getur birst aftur á móti. Þyrping sem lítur út fyrir að vera laus vegna þess að ekkert notar hana núna getur samt fallið innan forskyrtis sem einhver staðarbeini auglýsir, og vistfangaáætlunin er eina skjalið sem sýnir það.

Beint samband þýðir ARP, ekki leiðslu

Þegar hýsill með /22-tengi sendir til 10.0.101.25 ber kjarninn saman áfangastaðinn við forskyrti tengisins og finnur samsvörun. Pakkanum breytist í nágrannauppflettingu í stað beindrar pakka, og á Ethernet er nágrannauppflettingin ARP-beiðni fyrir það vistfang. Ef vistfangið tilheyrir VPN-biðlara bak við beint hlið, á enginn hýsill á LANinu það, svo beiðnin er ósvarað og pakkarnir eru felldir. Göngin eru ekki sek um neitt og biðlarinn sér aldrei umferðina.

Þess vegna lítur bilunin út fyrir að vera ósamhverf og stundum endurtekin. VPN-hýsillinn nær oft LANinu vegna þess að eigin leiðir hans vísa rétta leið, meðan LAN-hýsillinn getur ekki svarað, og allt sem setur gamla ARP-færslu í skyndiminni lætur einkennin flökta.

TUN, TAP og hvað hvort ber

TUN-tæki ber IP-pakka og TAP-tæki ber Ethernet-ramma. Beind TUN-tenging þarf ekki að bera ARP til að veita IP-aðgengi, og það er einmitt hvers vegna hina ósvöruðu beiðni hér að ofan er að vænta og ekki biluð. TAP með viljandi brú getur víkkað útvarpssviðið og látið ARP virka, en það breytir því sem biðlarinn sér, krefst endapunkta sem styðja sömu ramma og er endurhönnun netlíkansins frekar en viðgerð fyrir skarast forskyrti. Að skipta beindri uppsetningu yfir í TAP til að lækna vistfangaáætlunarvillu skiptir litlu vandamáli fyrir stærra.

Skráðu hvar ARP-beiðnin birtist og hvaða kerfi sendi hana áður en þú dregur ályktanir. Sendandinn segir þér hvað hann telur um áfangastaðinn, ekki hvað göngin gera.

Hannaðu þyrpingu sem getur ekki skarast

Veldu þyrpingu utan hvers tengda forskyrtis og hvers auglýsts staðarforskyrtis og bættu síðan við leiðunum sem gera hana aðgengilega í báðar áttir. Bil eins og 10.8.0.0/24 í ónotuðum hluta áætlunarinnar er auðvelt að rökstyðja, og LAN sem þarf að ná til þess fær kyrra leið sem vísar á VPN-netþjóninn. Breidu úthlutuninni, auglýstu leiðunum, leyfðum upprunavistföngum og eldveggjarreglunum saman, því þau lýsa einni hönnun en ekki fjórum stillingum.

Source NAT á netþjóninum getur falið þyrpinguna bak við LAN-beina vistfang, og það er lögmætt flutningstól. Það endurskrifar líka upprunann, svo LANið missir getuna til að rekja tengingar til einstakra biðlara og beita reglum fyrir hvern biðlara.

Notaðu úthlutað vistfang raunverulega biðlarans og raunverulega forritabeiðni frá LAN-hýsli við samþykktina og staðfestu síðan að svarið fylgi fyrirhuguðu hliði frekar en vírnum.