VPN ferbûn mar firewall blokkelet noch: hoe't jo witte hokker

De tunnel is omheech en ien poarte mislearret noch. Lês it paad, dan it belied op elke laach, en feroarje de smelste regel ynstee fan ien fan beide kontrôles út te skeakeljen.

De klant seit ferbûn, de boarne wegeret noch, en de gewoane folgjende stap is wat útskeakelje. Beide kontrôles yn dy sin dogge ferskillend wurk: de VPN bout in paad foar it bedutsen ferkear, en in firewall beslút per ferbining oft it ferkear troch mei. In wurkjende tunnel mei in wegerjend belied liket fan 'e stoel fan 'e brûker krekt as in stikken tunnel, dus it wurk is te finen hokker laach antwurdet. Hjir is de oarder dy't ik folgje, mei it lêzen dat jo seit om te stopjen.

Skied it paad fan it belied

Begjin mei de foarm fan 'e flater, want dat is fergees ynformaasje. In falle pakket jout in tiidferrin: de klant besiket opnij, der komt neat werom, en it kommando hinget oant it opjout. In wegering jout in wegering of in weromset: wat hat antwurde en nee sein. In tsjinst dy't net harket wegeret op 'e host sels, sûnder hokker firewall dan ek.

Dy trije útkomsten wize nei ferskillende lagen. Tiidferrin betsjuttet dat earne in belied stil falle lit, of dat it paad de masine nea ferlit. Wegere betsjuttet dat jo de host berikten en syn stapel of syn host-firewall wegere. Alhiel stilte, mei de tunnel-ynterface omheech en gjin paad nei de bestimming, betsjuttet dat it paad ferkeard is en gjin firewall-regel dat reparearret.

Lês it paad yn ien pass

Befêstigje dat de tunnel de bestimming dekt foardat jo nei ien regel sjogge. In dielde tunnel dy't allinnich it kantoar-subnet draacht, sil in fersyk net nei in oar berik stjoere, en dan liket de flater op in firewall-blokkade dy't it net is:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

De útfier fan it paad neamt de ynterface dêr't it pakket troch fuortgiet en it boarne-adres dat it draacht. As dy ynterface jo fysike netkaart is en net de tunnel, dan is it probleem yn 'e rûteleas of yn 'e tastiene berikken fan 'e tunnel, en it heart by de VPN-konfiguraasje en net by de firewall.

Ien falstrik spesifyk foar VPN fertsjinnet in eigen kontrôle. Yn WireGuard is AllowedIPs fan in peer tagelyk in rûte en in kryptografysk filter: in pakket waans boarne-adres net by de tastiene set fan 'e peer past, wurdt fuortgien foardat hokker firewall-regel dan ek rieplachte wurdt. Sa kin in folslein korrekte host-firewall efter in stil falle sitte dat op in belied liket, en de oplossing is in konfiguraasjeline foar de kaai, net in regel.

Lês it belied op 'e laach dy't antwurdet

As it paad goed is, rin dan it belied fan 'e host nei bûten ta en sjoch nei de iene laach waans tellers bewege:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

De harkjende socket antwurdet in oare fraach as de regels. As der neat op 'e poarte harket, wegeret de kearn de ferbining en is gjin ynkommende regel relevant. As de socket bestiet en de ferbining fan in fiere klant ferrint, bart der earne op it paad in falle, en de tellers fan 'e regels fertelle jo oft it hjir bart.

Skeakelje logging yn foar it profyl of de keatling dy't jo fermoedzje, ynstee fan fan bûten te rieden. Ien logde falle dy't de boarne, bestimming en poarte neamt, identifisearret de laach en de regel, en it bewiist ek dat it pakket oankaam, wat gjin test oan 'e klantkant fêststelle kin.

Lês it beslút fan 'e gateway as de tunnel dêr einiget

Op in site-nei-site- of op-ôfstân-gateway autentisearret de VPN in brûker en it belied autorisearret in boarne, en dat binne aparte tastimmingen. In brûker dy't yn 'e tunnel mei, mei net automatysk op elke ynterne host, en de wegering komt faak fan in trochstjoerregel wylst de tunnel sels sûn is. Deselde skieding is der yn IPsec, dêr't it feiligensbelied dat ferkear kiest ferskilt fan it filter dat it talit, en dêrom binne se beide dokumintearre as ferskillende meganismen yn RFC 4301.

Kontrolearje it werompaad like soarchfâldich as it útgeande paad. Steatfiltrage moat it antwurd sjen, dus asymmetrysk rûteleas troch de tunnel yn 'e iene rjochting en om him hinne yn 'e oare jout fallen dy't tafallich lykje en allinnich fan guon klanten werombrocht wurde. As ferkear de gateway berikt en stopet, lês dan de trochstjoerregel en it werompaad tegearre foardat jo eat ferbreedzje.

De gateway is ek it plak dêr't in NAT- of maskerade-regel de wiere boarne ferbergje kin. As ynterne hosts it gateway-adres sjogge ynstee fan de klant, sille harren host-firewall-regels dy't by de klantpool passe moatte nea passe, en de oplossing heart by de gateway en net by elke tsjinner.

Feroarje de smelste laach, en kontrolearje dan

Wjerstean de brede reparaasje. De host-firewall útskeakelje, in regel tafoegje dy't alles tastiet, of elke ynterface yn in fertroud profyl twinge, hellet elk de kontrôle wei dy't syn wurk die, en de feroaring oerlibbet it ynsidint. In regel beheind ta it boarneberik en de poarte yn kwestje is makliker te besjen, makliker te ferwiderjen, en lit de rest fan 'e masine syn belied yntakt.

Kontrolearje mei deselde test dy't mislearre, fan deselde klant, en dan noch ien kear nei opnij ferbinen, want in regel dy't past foardat de tunnel opnij ûnderhannelt, kin dernei ophâlde te passen:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Foardat jo it slute:

  • It paad nei de bestimming giet fuort troch de tunnel-ynterface, en it boarne-adres past by wat it belied ferwachtet.
  • Der harket wat op 'e poarte, en de wegering of it tiidferrin wurdt taskreaun oan in neamde regel ynstee fan oannommen.
  • De gateway stjoert troch yn beide rjochtingen, en de bestimming sjocht de boarne dêr't jo regels foar skreaun binne.
  • Gjin kontrôle waard útskeakele om 'e test te slagjen, en de feroaring dy't jo makken neamt ien boarneberik en ien poarte.

Relatearre artikelen