Beint VPN-biðlari nær þjóninum en ekki LAN-hýslum

Göngin koma upp, biðlarinn pinnar VPN-þjóninn, og deild á vél einu hoppi lengra svarar aldrei. Ekkert í stillingum biðlarans útskýrir þetta, því beiðnin fór sannarlega frá biðlaranum og kom sannarlega. Það sem mistókst var heimferðin, og tækið sem mistókst er venjulega LAN-gáttin en ekki VPN-hýsillinn. Eftirfylgni svarpakans útskýrir allan þennan flokk einkenna.

Fylgdu svarinu, ekki beiðninni

VPN-þjóninn afkóðar paka biðlarans og sendir hann áfram inn á LAN með vistfangi biðlarans enn í upprunareitnum. Áfangahýsillinn svarar því vistfangi, og nú ræður eigin beiningartafla hans öllu. Sjálfgefin gátt hans veit ekkert um göngusafnið, svo svarið fer í átt að netþjónustuaðilanum og er hent einhvers staðar á þeirri leið.

Hjá biðlaranum er einkennið hljóðlaust tímamark: engin synjun, engin endurstilling, bara ekkert. Vafra um deild stendur kyrr, ping tilkynnir ekkert svar, og þjónskrár líta heilbrigðar út því þjóninn gerði sitt.

Setja endurkvörðunina þar sem hýslarnir líta

Sérhver LAN-hýsill ráðfærir sig við sjálfgefna gátt sína, svo gáttin er eina tækið sem þarf að vita hvar göngusafnið er. Bættu þar við kyrrstæðri kvörðun og hver hýsill erfur réttu leiðina án þess að vera snertur.

Ef gáttin úthlutar eigin vistfangi sem DHCP-valkosti, dreifðu kvörðuninni þannig að nýjar vélar taki hana sjálfkrafa. Annars býr kvörðunin í einni stillingarskrá og hverfur við næstu endurbyggingu.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Hvers vegna upprunanat virðist laga þetta

Að fela biðlarasafnið á bak við vistfang VPN-þjónsins fjarlægir vandamálið með því að fjarlægja vistfang biðlarans úr pakanum. Svörin koma þá aftur til þjónsins, sem veit þegar hvernig á að ná göngunum, og allt virkar. Kostnaðurinn er að innri hýslar sjá ekki lengur hver biðlarinn er, og sérhver tenging virðist koma frá einni vél.

Þessi skipti eru stundum rétt, til dæmis þegar ekki er hægt að gefa tæki frá birgi kyrrstæða kvörðun. Gerðu regluna ekki víðari en núverandi safn, því regla skrifuð fyrir /24 hættir að passa daginn sem safnið er endurnúmerað í /16, og fyrsta merkið er hópur nýrra biðlara sem tengjast og ná engu.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Skýjaleiðin þarf þrjár stillingar

Í VPC kemur sama eyðan aftur í annarri mynd, því undirnetið hefur alls enga kvörðun fyrir biðlarasviðið. Beiningartaflan þarf færslu fyrir göngusafnið sem beinist að netviðmóti tilviksins, og viðmótið þarf að hafa slökkt á uppruna- og áfangaskoðun svo pallurinn samþykki pakka þar sem uppruninn er ekki eigið vistfang. Öryggishópar og net-ACL verða líka að hleypa safninu í báðar áttir.

Sérhver slepping veldur sérstöku hluta mistaki. Slepptu færslunni í beiningartöflunni og einkatilvik svara inn í undirnet sem getur ekki borið svarið aftur í safnið. Með skoðunina enn virka hendir pallurinn svarinu eftir að tilvikið hefur þegar sent það. Án reglu öryggishópsins kemst beiðnin sjálf aldrei, og biðlarinn sér tímamarkið einu lagi fyrr.

Keyrðu skoðanirnar í þessari röð

Staðfestu framsendingu og síunarstefnu áður en þú kennir beiningum um, því hýsill sem framsendir ekki mistekst á sama hljóðlausa hátt. Lestu svo virka stillingu bakleiðar á viðmótinu sem ber göngin, því strangt sía getur hent svörum sem koma úr óvæntri átt.

Ljúktu með upptöku á LAN-hýslinum meðan biðlarinn pinnar hann. Beiðni sem kemur án samsvarandi svars sannar heimleiðina, og beiðni sem kemur aldrei færir sökina aftur á þjóninn eða göngin.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Uppruna- og áfangaskoðunin er skjalfest í leiðarvísinum um sveigjanleg netviðmót. Stilltu henni á viðmótið sem ber raunverulega gönguumferð, ekki á ótengt millistykki á sama tilviki.